Hi,
Today I was digging through the test expectations in
web-platform-tests/meta and came across some failure annotations for
tests added to w-p-t by Blink engineers that were since synced to m-c.
Looking into them, one of them turned out to be a real bug in our
code.[1]
Apart from being stoked t
Hi,
It seems like the MANIFEST.json for web platform tests now includes a
checksum of test file contents. As a result, if you run './mach
web-platform-tests --manifest-update yer' on a clean checkout of m-c
you're likely to get a bunch of changes to MANIFEST.json showing up.
Should we be requirin
在 2017/2/10 1:28, Benjamin Smedberg 写道:
On Wed, Feb 8, 2017 at 2:26 AM, 段垚 wrote:
Is this just preventing auto-loading (like "click to play") or completely
disable Flash for non-http(s) contents?
This is completely disabling this content.
Can users get back old behavior by flipping a pre
On Fri, Feb 10, 2017, at 12:33 AM, Patrick Brosset wrote:
> >
> > DevTools bug: It's not yet clear to me whether specific DevTools work will
> > be needed.
> >
>
> I don't think we need anything now, the property should work in the
> inspector's Rules panel just like other properties.
> Although w
On Fri, Feb 10, 2017, at 04:29 AM, Benjamin Smedberg wrote:
> Will this also prevent loading downloaded .swf files into Firefox? This
> is
> > useful for running Flash games, which tend to work best in the browser
> > (some media players also support loading Flash files, but their hotkeys
> > tend
Sorry for the noisy... It was meant to test whether the mailing list
works again... But I picked the wrong email address so it got published.
Please ignore this one.
- Xidorn
On Fri, Feb 10, 2017, at 01:44 PM, Xidorn Quan wrote:
> This is for testing purpose, and should not be published to the li
This is for testing purpose, and should not be published to the list.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
My concern is that this will get partially done but never completed, and
we'll end up in a situation where we have two styles in place. We have a
bad track record with that sort of thing.
Nick
On Thu, Feb 9, 2017 at 1:45 PM, Jeff Muizelaar wrote:
> It's not very easy to reason about overflow i
On Thu, Feb 09, 2017 at 12:41:07PM -0800, Jim Blandy wrote:
> Under the circumstances, I'll volunteer to review, if that's feasible.
I can too.
> On Thu, Feb 9, 2017 at 12:37 PM, Ted Mielczarek wrote:
>
> > On Thu, Feb 9, 2017, at 02:47 PM, Aaron Klotz wrote:
> > > This is great news, Ted!
> >
I was recently asked to look at regression bugs found late in the beta
cycle or post-release to see what discernible trends there might be and how
it might inform our testing strategy going forward.
I looked at all bugs that met those criteria that were filed against
Firefox 46-50 up through early
Under the circumstances, I'll volunteer to review, if that's feasible.
On Thu, Feb 9, 2017 at 12:37 PM, Ted Mielczarek wrote:
> On Thu, Feb 9, 2017, at 02:47 PM, Aaron Klotz wrote:
> > This is great news, Ted!
> >
> > Are you going to be creating a module for this? Who are the peers?
>
> I don't
On Thu, Feb 9, 2017, at 02:47 PM, Aaron Klotz wrote:
> This is great news, Ted!
>
> Are you going to be creating a module for this? Who are the peers?
I don't think a new module is necessary, we've covered the existing
integration code (nsExceptionHandler.cpp etc) under the Toolkit module
for a l
This is great news, Ted!
Are you going to be creating a module for this? Who are the peers?
-Aaron
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
FYI, I landed a patch[1] yesterday that forked the Breakpad client code.
Everything that was in toolkit/crashreporter/google-breakpad/src/client
is now in toolkit/crashreporter/breakpad-client. Google has switched
Chromium to using Crashpad (their new crash reporting library) on
Windows, OS X and A
On 2/9/17 5:45 AM, Mike West wrote:
I look forward to stealing your tests. :)
Yep, sounds good. I put up patches in
https://bugzilla.mozilla.org/show_bug.cgi?id=1306170 with the test bits;
in fact most of the patches are changes to the tests. Note that you'll
want https://github.com/w3c/te
On 2/9/17 5:44 AM, Mike West wrote:
Perhaps we could deprecate `document.origin` and ship `self.origin` in
Blink instead of y'all shipping `document.origin`? It seems like we want to
encourage folks to use `self.origin` going forward...
So specifically, should I be asking Anne to remove documen
On Tue, Feb 7, 2017 at 5:19 PM, Chris Peterson
wrote:
> On 2/7/2017 1:15 PM, Benjamin Smedberg wrote:
>
>> I intend to ship a change which will prevent Flash from loading from
>> file:,
>> ftp:, or any other URL scheme other than http: or https:. The purpose of
>> this change is to increase secu
Will this also prevent loading downloaded .swf files into Firefox? This is
> useful for running Flash games, which tend to work best in the browser
> (some media players also support loading Flash files, but their hotkeys
> tend to conflict).
It will prevent them from loading via File > Open, yes
On Wed, Feb 8, 2017 at 2:26 AM, 段垚 wrote:
> Is this just preventing auto-loading (like "click to play") or completely
> disable Flash for non-http(s) contents?
>
This is completely disabling this content.
>
> Can users get back old behavior by flipping a preference?
>
That is not the plan, no
On 2/9/17 5:44 AM, Mike West wrote:
Perhaps we could deprecate `document.origin` and ship `self.origin` in
Blink instead of y'all shipping `document.origin`?
Given the lack of support in Edge and the incompatible support in
WebKit, I can probably live with that. Especially if y'all remove it
It's not very easy to reason about overflow issues with our current
representation. This means that we currently just pretend that they
don't happen. The idea for changing the representation came up in
response to a security bug where we didn't really have a better
solution.
Changing to x1, x2, y1
I just filed:
https://bugzilla.mozilla.org/show_bug.cgi?id=1338144
On Thu, Feb 9, 2017 at 4:26 AM, Kohei Yoshino
wrote:
> Do we already have a bug for this? Firefox 52 will be shipped just in 4
> weeks.
>
>
> On 2017-01-18 10:49 AM, Ben Kelly wrote:
>
>> I'd like to disable service workers in 5
>
> DevTools bug: It's not yet clear to me whether specific DevTools work will
> be needed.
>
I don't think we need anything now, the property should work in the
inspector's Rules panel just like other properties.
Although we might want to keep that in mind for a future version of our
Fonts panel.
Do we already have a bug for this? Firefox 52 will be shipped just in 4 weeks.
On 2017-01-18 10:49 AM, Ben Kelly wrote:
I'd like to disable service workers in 52 ESR. This would also require
disabling push notifications.
A year ago we decided to disable service workers in 45 ESR because it was
24 matches
Mail list logo
