Re: Intent to implement and ship: "passive" option for AddEventListenerOptions

[Anne van Kesteren]

On Fri, May 6, 2016 at 4:43 AM, Eric Shepherd  wrote:
> What happens if the developer specifies passive yet calls
> preventDefault() anyway?

That's a no-op per https://dom.spec.whatwg.org/#dom-event-preventdefault.


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Reverting to VS2013 on central and aurora

[Gregory Szorc]

There is a compiler bug in VS2015 that results in SSE instructions being
emitted when they shouldn't be. Since Firefox still needs to remain
compatible with ancient hardware that doesn't support SSE, this is causing
crashes on Firefox built with VS2015 (see bug 1265615).

The good news is glandium found a pretty minimal reproduce case and
reported the bug to Microsoft.

The bad news is the issue still reproduces in the latest pre-release
version of the Visual C++ toolchain.

The worse news is we'll have to revert to building Firefox 48 (current
Aurora) and 49 (current central) with VS2013. Bugs 1270664 and 1270714
track. Aurora will likely land soon. Central might take a few days, as I
believe VS2013 is a bit broken on central at the moment.

This is really a bummer because a lot of you have taken the time to upgrade
to VS2015 and we got some really nice PGO build time wins out of the
transition (Windows PGO builds were just as fast as Linux PGO builds in
automation). But, stability is stability.

I'll try to stand up automation to ensure central remains buildable with
VS2015. This will add extra work and strain on automation and likely make
writing C++ that remains compatible with multiple Visual Studio versions
slightly harder. This is unfortunate, but I think necessary since people
will want to use VS2015 for development.

FWIW, the crashes we've seen so far are from incorrectly emitted movss
instructions. This instruction is part of the original SSE instruction set,
which was initially unveiled by Intel on the Pentium 3 in 1999 and later by
AMD on the Duron and Athlon XP in 2000-2001. I'm not sure why we still need
Firefox to run on processors manufactured in the 90s. By comparison, Chrome
has required SSE2 (Intel support since Pentium 4 in 2001 and AMD support
since Opteron and Athlon 64 in 2003) since Chrome 35, which was released in
mid 2014 (https://bugs.chromium.org/p/chromium/issues/detail?id=348761).
Since we've dropped support for OS X <10.9 and are talking about dropping
Windows XP support, I'd urge us to consider dropping support for processors
without SSE instructions as well. I believe our continued insistence to
support these ancient platforms hinders our developer productivity and
sacrifices product quality by not allowing us to take advantage of modern
technologies. I believe this puts us at a competitive disadvantage compared
to other browser vendors. 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: MacOS 10.6-10.8 support

[sfbay . mapfixer]

On Tuesday, May 3, 2016 at 8:32:26 PM UTC-7, Lawrence Mandel wrote:
> On Tue, May 3, 2016 at 11:11 PM, Xidorn Quan  wrote:
> 
> > On Wed, May 4, 2016 at 9:46 AM, Lawrence Mandel  wrote:
> >
> >> On Tue, May 3, 2016 at 6:56 PM, Mike Hommey  wrote:
> >>
> >> > On Tue, May 03, 2016 at 05:18:17PM -0500, Adam Roach  wrote:
> >> > > On 5/3/16 4:59 PM, Justin Dolske wrote:
> >> > > > On 5/3/16 12:21 PM, Gregory Szorc wrote:
> >> > > >
> >> > > > > * The update server has been reconfigured to not serve Nightly
> >> > > > > updates to
> >> > > > > 10.6-10.8 (bug 1269811)
> >> > > >
> >> > > > Are we going to be showing some kind of notice to affected users
> >> upon
> >> > > > Release? That is, if I'm a 10.6 user and I update to Firefox 48, at
> >> > some
> >> > > > point should I see a message saying I'll no longer receive future
> >> > > > updates?
> >> > >
> >> > > Even better, is there any way to get the update system to
> >> automatically
> >> > move
> >> > > such users over to 45ESR?
> >> >
> >> > Did we introduce changes to profile data between 45 and 48? Because
> >> > that usually breaks downgrade paths.
> >> >
> >>
> >> We discussed this earlier and decided that we were not going to
> >> automatically move users from Firefox to ESR. For one thing, the user has
> >> not opted to be on this channel. A channel change also involves both
> >> engineering and test work. It does seem prudent to test the scenario to
> >> know whether users can move from 47 to ESR 45.2.0 without issue.
> >
> >
> > Is it feasible to make 48 an ESR as well so that we don't need to ask
> > users to downgrade it to ESR 45?
> >
> 
> I don't think so. I also don't know that we're going to recommend that
> users migrate to ESR (need to verify that there are no incompatible profile
> changes) although that is certainly an option.
> 
> Lawrence

(Note: Please see "OSX Support Cycle" below.) 

These are important decisions. However, expecting all end-users to be able to 
handle a manual migration to ESR, or understand what is happening or why seems 
like a bad idea. I believe downgrading should NOT be considered as an option, 
except for tech savvy users. 

There are three options that OSX 10.6-10.8 users have with Firefox:
1. Upgrade their OS (not possible for some)
2. Install ESR (temporary fix that could create problems if they can do #1 
later)
3. Continue using the unsupported Firefox (and hope they are not hit by a 
security vulnerability)
4. Stop using Firefox

>From my perspective, the best option for those who cannot upgrade their OS, is 
>to make the final 10.6-10.8 version be (or become) the next ESR. I have found, 
>repeatedly, that if there is a chance for users to 
>mis-read/mis-understand/confuse instructions, they will. Don't complicate 
>their lives any more than they already are. Give them a simple choice. "Click 
>here to upgrade to ESR".

Make sure that adequate startup pages are created to communicate these changes 
in as concise a manner as possible. Provide links for further detail. 
Subsequent startups should load follow-up pages with reminders, perhaps reduced 
to a notice bar (like what Google Chrome did recently).


SIDEBAR: "OSX Support Cycle"  ...

While we are on this subject, what is the plan for Firefox support of 10.9 
later this year when Apple pushes out its latest OSX? How about a year from now 
when 10.10 support ends? Where does the annual Firefox/OSX support depreciation 
end? 

Apple has shifted to warp speed with their rapid release cycle. Every version 
of Windows has a minimum 10 year support lifecycle (security patches, etc.) OSX 
now has 3. 

If Mozilla and other developers simply follow Apple's "not supported" timeline, 
there will be a growing number of end users who will be left out. Where do you 
think they will go? If they migrate to Windows there is a much greater chance 
they will stick with Edge or whatever is there and leave Firefox behind.

I have been a long-time Firefox advocate. I hope to continue this but am 
uncertain where the Firefox support path is going...
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: MacOS 10.6-10.8 support

[Kyle Huey]

On Thu, May 5, 2016 at 8:23 PM,  wrote:

> On Tuesday, May 3, 2016 at 8:32:26 PM UTC-7, Lawrence Mandel wrote:
> > On Tue, May 3, 2016 at 11:11 PM, Xidorn Quan 
> wrote:
> >
> > > On Wed, May 4, 2016 at 9:46 AM, Lawrence Mandel 
> > > wrote:
> > >
> > >> On Tue, May 3, 2016 at 6:56 PM, Mike Hommey  wrote:
> > >>
> > >> > On Tue, May 03, 2016 at 05:18:17PM -0500, Adam Roach wrote:
> > >> > > On 5/3/16 4:59 PM, Justin Dolske wrote:
> > >> > > > On 5/3/16 12:21 PM, Gregory Szorc wrote:
> > >> > > >
> > >> > > > > * The update server has been reconfigured to not serve Nightly
> > >> > > > > updates to
> > >> > > > > 10.6-10.8 (bug 1269811)
> > >> > > >
> > >> > > > Are we going to be showing some kind of notice to affected users
> > >> upon
> > >> > > > Release? That is, if I'm a 10.6 user and I update to Firefox
> 48, at
> > >> > some
> > >> > > > point should I see a message saying I'll no longer receive
> future
> > >> > > > updates?
> > >> > >
> > >> > > Even better, is there any way to get the update system to
> > >> automatically
> > >> > move
> > >> > > such users over to 45ESR?
> > >> >
> > >> > Did we introduce changes to profile data between 45 and 48? Because
> > >> > that usually breaks downgrade paths.
> > >> >
> > >>
> > >> We discussed this earlier and decided that we were not going to
> > >> automatically move users from Firefox to ESR. For one thing, the user
> has
> > >> not opted to be on this channel. A channel change also involves both
> > >> engineering and test work. It does seem prudent to test the scenario
> to
> > >> know whether users can move from 47 to ESR 45.2.0 without issue.
> > >
> > >
> > > Is it feasible to make 48 an ESR as well so that we don't need to ask
> > > users to downgrade it to ESR 45?
> > >
> >
> > I don't think so. I also don't know that we're going to recommend that
> > users migrate to ESR (need to verify that there are no incompatible
> profile
> > changes) although that is certainly an option.
> >
> > Lawrence
>
> (Note: Please see "OSX Support Cycle" below.)
>
> These are important decisions. However, expecting all end-users to be able
> to handle a manual migration to ESR, or understand what is happening or why
> is somewhat flawed. I believe downgrading should NOT be considered as an
> option, except for tech savvy users.
>
> The best option, from my perspective (supporting a wide array of users, OS
> versions, hardware), is to make the final 10.6-10.8 version be (or become)
> the next ESR with a startup page providing them with the choice and action
> buttons/links. Subsequent startups would load follow-up startup pages with
> the appropriate reminders.
>
> The pages should explain very simply and succinctly that no new features
> will be coming and only security updates/patches will be made until "X"
> date when support ends (but the browser will still be usable). The first
> page should be VERY overt and obnoxious. The 2nd, 3rd, etc. can be more
> like what Google Chrome did recently (ie. notice bar at top of the content
> area).
>
> SIDEBAR: "OSX Support Cycle"
>
> While we are on this subject, what is the plan for Firefox support of 10.9
> later this year when Apple pushes out its latest OSX? How about a year from
> now when 10.10 support ends? Where does the annual Firefox/OSX support
> depreciation end?
>
> Apple has shifted to warp speed with their rapid release cycle. Every
> version of Windows has a minimum 10 year support lifecycle (security
> patches, etc.) OSX now has 3.
>
> If Mozilla and other developers simply follow Apple's "not supported"
> timeline, there will be a growing number of end users who will be left out.
> Where do you think they will go? If they migrate to Windows there is a much
> greater chance they will stick with Edge or whatever is there and leave
> Firefox behind.
>

We *don't* follow Apple's timeline though.  Snow Leopard was dropped by
Apple back in 2013.  Mozilla's decisions are driven by considering, among
other factors, how many users remain on that platform and the engineering
difficulty of continuing to support it.

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: MacOS 10.6-10.8 support

[sfbay . mapfixer]

On Tuesday, May 3, 2016 at 8:32:26 PM UTC-7, Lawrence Mandel wrote:
> On Tue, May 3, 2016 at 11:11 PM, Xidorn Quan  wrote:
> 
> > On Wed, May 4, 2016 at 9:46 AM, Lawrence Mandel 
> > wrote:
> >
> >> On Tue, May 3, 2016 at 6:56 PM, Mike Hommey  wrote:
> >>
> >> > On Tue, May 03, 2016 at 05:18:17PM -0500, Adam Roach wrote:
> >> > > On 5/3/16 4:59 PM, Justin Dolske wrote:
> >> > > > On 5/3/16 12:21 PM, Gregory Szorc wrote:
> >> > > >
> >> > > > > * The update server has been reconfigured to not serve Nightly
> >> > > > > updates to
> >> > > > > 10.6-10.8 (bug 1269811)
> >> > > >
> >> > > > Are we going to be showing some kind of notice to affected users
> >> upon
> >> > > > Release? That is, if I'm a 10.6 user and I update to Firefox 48, at
> >> > some
> >> > > > point should I see a message saying I'll no longer receive future
> >> > > > updates?
> >> > >
> >> > > Even better, is there any way to get the update system to
> >> automatically
> >> > move
> >> > > such users over to 45ESR?
> >> >
> >> > Did we introduce changes to profile data between 45 and 48? Because
> >> > that usually breaks downgrade paths.
> >> >
> >>
> >> We discussed this earlier and decided that we were not going to
> >> automatically move users from Firefox to ESR. For one thing, the user has
> >> not opted to be on this channel. A channel change also involves both
> >> engineering and test work. It does seem prudent to test the scenario to
> >> know whether users can move from 47 to ESR 45.2.0 without issue.
> >
> >
> > Is it feasible to make 48 an ESR as well so that we don't need to ask
> > users to downgrade it to ESR 45?
> >
> 
> I don't think so. I also don't know that we're going to recommend that
> users migrate to ESR (need to verify that there are no incompatible profile
> changes) although that is certainly an option.
> 
> Lawrence

(Note: Please see "OSX Support Cycle" below.)

These are important decisions. However, expecting all end-users to be able to 
handle a manual migration to ESR, or understand what is happening or why is 
somewhat flawed. I believe downgrading should NOT be considered as an option, 
except for tech savvy users.

The best option, from my perspective (supporting a wide array of users, OS 
versions, hardware), is to make the final 10.6-10.8 version be (or become) the 
next ESR with a startup page providing them with the choice and action 
buttons/links. Subsequent startups would load follow-up startup pages with the 
appropriate reminders.

The pages should explain very simply and succinctly that no new features will 
be coming and only security updates/patches will be made until "X" date when 
support ends (but the browser will still be usable). The first page should be 
VERY overt and obnoxious. The 2nd, 3rd, etc. can be more like what Google 
Chrome did recently (ie. notice bar at top of the content area).

SIDEBAR: "OSX Support Cycle"

While we are on this subject, what is the plan for Firefox support of 10.9 
later this year when Apple pushes out its latest OSX? How about a year from now 
when 10.10 support ends? Where does the annual Firefox/OSX support depreciation 
end?

Apple has shifted to warp speed with their rapid release cycle. Every version 
of Windows has a minimum 10 year support lifecycle (security patches, etc.) OSX 
now has 3.

If Mozilla and other developers simply follow Apple's "not supported" timeline, 
there will be a growing number of end users who will be left out. Where do you 
think they will go? If they migrate to Windows there is a much greater chance 
they will stick with Edge or whatever is there and leave Firefox behind.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement and ship: allow-modals sandbox flag

[Boris Zbarsky]

Summary: The idea is to prevent calls to 
window.alert/confirm/prompt/print from sandboxed iframes, and prevent 
them putting up beforeunload dialogs, unless explicitly allowed to. 
Note that this is a NEW sandbox restriction, so might break some 
existing sandboxed content.  A new token in the iframe sandbox attribute 
allows loosening the restriction.


Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1190641

Spec: 
https://html.spec.whatwg.org/multipage/browsers.html#sandboxed-modals-flag 
and 
https://html.spec.whatwg.org/multipage/browsers.html#sandboxing:sandboxed-modals-flag 
and the definitions of alert/confirm/etc.  There is one open spec issue 
I raised while implementing: 
.  It would only affect very 
contrived edge cases, and whatever is decided on in that issue we can 
update to reasonably easily.


Target release: 49

Platforms: all

Preference behind which this is implemented: none

DevTools bug: Not sure this needs devtools support.

Support in other browsers: I believe Chrome supports this.  Not sure 
about others.


Tests: Automatic testing for this is rather hard.  I did test manually.

Security/Privacy concerns: none.

The main worry here is the backwards-compat issue, but given that Chrome 
is shipping it and sandboxed iframes are pretty rare so far, this seems 
like it should be safe.


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement and ship: allow-popups-to-escape-sandbox sandbox flag

[Boris Zbarsky]

Summary: The idea is to add a way for a sandboxed iframe to open a popup 
window that is not sandboxed, via a new token in the sandbox attribute 
that loosens the "everything you open will be sandboxed like you" 
restriction.  This obviously allows the iframe to open itself and thus 
escape the sandbox, hence the naming.  This is a useful thing to allow 
because this way ads or search results can be sandboxed but still open 
the site they are linking to without sandboxing, and the fact that the 
opening requires an explicit user action means they can't just 
automatically unsandbox themselves


This feature has been requested by numerous people who would really like 
to sandbox more stuff but can't because then said stuff can't open the 
things it needs to open.


Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1190641

Spec: 
https://html.spec.whatwg.org/multipage/browsers.html#sandbox-propagates-to-auxiliary-browsing-contexts-flag 
and 
https://html.spec.whatwg.org/multipage/browsers.html#sandboxing:sandbox-propagates-to-auxiliary-browsing-contexts-flag 
and the tail end of 
https://html.spec.whatwg.org/multipage/browsers.html#the-rules-for-choosing-a-browsing-context-given-a-browsing-context-name


Target release: 49

Platforms: all

Preference behind which this is implemented: none

DevTools bug: Not sure this needs devtools support.

Support in other browsers: I believe Chrome supports this.  I'm not sure 
what the state is in other browsers.


Tests: Web platform tests are in the patch.

Security/Privacy concerns: See above in terms of this allowing sandboxed 
things to unsandbox themselves.


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: "passive" option for AddEventListenerOptions

[Eric Shepherd]

What happens if the developer specifies passive yet calls
preventDefault() anyway?


*From:* Kartikaya Gupta
*Sent:* Wednesday, May 4, 2016 6:19:20 PM EDT
*To:* dev-platform
*Cc:* Rick Byers
*Subject:* Intent to implement and ship: "passive" option for
AddEventListenerOptions

> Summary: Authors can declare in their addEventListener call that the
> listener will not be calling preventDefault() on the event. This
> unlocks certain performance optimizations.

-- 

Eric Shepherd
Senior Technical Writer
Mozilla Developer Network 
Blog: https://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Doodle: http://doodle.com/the.sheppy

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: libc++ enabled for Android / C++11 standard library update

[Mike Hommey]

On Thu, May 05, 2016 at 05:45:35PM -0400, Nathan Froyd wrote:
> On Thu, May 5, 2016 at 5:36 PM,   wrote:
> > Out of interest, what is the situation on Linux? Which C++11 standard 
> > library will you be using? Will you be shipping your own copy as a shared 
> > library, or will you be using the system one?  If I understand correctly, I 
> > assume you cannot link against the libstdc++ that ships with GCC 4.8.5 as 
> > the libstdc++ C++11 ABI did not stabilise until GCC 5.X (meaning your 
> > binaries will not work properly unless the distro where you are running 
> > ships exactly the same libstdc++)?
> 
> We use libstdc++ on Linux, with special hacks so that our binaries
> will actually run against older shared libstdc++ than the headers we
> compile with.  (It's possible that libstdc++ prior to GCC 5 isn't
> completely C++11 compliant, but it's probably close enough for our
> current purposes.)  See e.g.
> 
> http://dxr.mozilla.org/mozilla-central/source/build/unix/stdc++compat/stdc++compat.cpp#27
> http://dxr.mozilla.org/mozilla-central/source/config/gcc-stl-wrapper.template.h#55
> 
> for an idea of what we do.  We haven't tried crossing the GCC 5 ABI
> breakage yet.

Specifically, we build with -D_GLIBCXX_USE_CXX11_ABI=0.

Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: "passive" option for AddEventListenerOptions

[Markus Stange]

On 2016-05-05 3:21 PM, Justin Dolske wrote:

How will a developer know when it would be worthwhile to mark their event
listener as passive? Do we perhaps log something to the console?


The Chrome devtools have two features to help with this: They have a 
checkbox for "Show scrolling perf issues" which draws annotated 
rectangles over those areas of the page that have non-passive wheel 
event listeners, and their event listener list explicitly marks 
non-passive event listeners with "passive: false". We could do something 
similar.


Both of these features are demonstrated in a screen cast Rick Byers 
uploaded at https://www.youtube.com/watch?v=6-D_3yx_KVI .


-Markus
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: libc++ enabled for Android / C++11 standard library update

[Nathan Froyd]

On Thu, May 5, 2016 at 5:36 PM,   wrote:
> Out of interest, what is the situation on Linux? Which C++11 standard library 
> will you be using? Will you be shipping your own copy as a shared library, or 
> will you be using the system one?  If I understand correctly, I assume you 
> cannot link against the libstdc++ that ships with GCC 4.8.5 as the libstdc++ 
> C++11 ABI did not stabilise until GCC 5.X (meaning your binaries will not 
> work properly unless the distro where you are running ships exactly the same 
> libstdc++)?

We use libstdc++ on Linux, with special hacks so that our binaries
will actually run against older shared libstdc++ than the headers we
compile with.  (It's possible that libstdc++ prior to GCC 5 isn't
completely C++11 compliant, but it's probably close enough for our
current purposes.)  See e.g.

http://dxr.mozilla.org/mozilla-central/source/build/unix/stdc++compat/stdc++compat.cpp#27
http://dxr.mozilla.org/mozilla-central/source/config/gcc-stl-wrapper.template.h#55

for an idea of what we do.  We haven't tried crossing the GCC 5 ABI
breakage yet.

-Nathan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: libc++ enabled for Android / C++11 standard library update

[cosinusoidally]

On Tuesday, 3 May 2016 16:32:55 UTC+1, Nicholas Alexander  wrote:
> On Tue, May 3, 2016 at 7:57 AM, Nathan Froyd  wrote:
> > This change leaves Mac as our only tier-1 platform without a C++11
> > standard library.

Out of interest, what is the situation on Linux? Which C++11 standard library 
will you be using? Will you be shipping your own copy as a shared library, or 
will you be using the system one?  If I understand correctly, I assume you 
cannot link against the libstdc++ that ships with GCC 4.8.5 as the libstdc++ 
C++11 ABI did not stabilise until GCC 5.X (meaning your binaries will not work 
properly unless the distro where you are running ships exactly the same 
libstdc++)?

Thanks
Liam Wilson
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to remove:

[Ehsan Akhgari]

On Wed, Apr 27, 2016 at 8:54 AM, Henri Sivonen  wrote:

> > As much as I'd like us to get rid of  as soon as we can, I
> > oppose doing so without first measuring its actual usage for Firefox
> > through telemetry.
>
> Suppose we measured hitting the isindex special case in form
> submission. Would you measure the times we hit it or the session in
> which we hit it at least once?


Both are probably worth measuring, so that we can have a good idea whether
a small number of users/pages use this periodically versus a number of
users hitting this frequently.


> What would the baseline be? How would
> you decide that whatever the count is is low enough (assuming
> non-zero)?
>

The point of measuring the usage is mostly to get a sense of whether the
usage of this feature is "infrequent enough".  The exact definition of that
depends on our expectation of how infrequently this is used.  I understand
that we don't currently have a baseline that we use for removing features,
but that's because we've been very sloppy with regards to unshipping
features.  At the very least we need to make sure that a surprisingly large
number of sessions don't run into isindex, right?

-- 
Ehsan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: "passive" option for AddEventListenerOptions

[Kartikaya Gupta]

In general developers should probably default to marking their
listeners as passive, unless their listeners are actually going to
call preventDefault(). We don't have a console log for saying "use a
passive listener", no. We can easily detect listeners that are not
marked passive and that are impacting scrolling latency (for example),
but it's impossible to tell with 100% accuracy if those listeners
*should* be marked passive or not. Some of those listeners are
probably legitimately not passive, because they do call
preventDefault() under some conditions - but we can't know that until
those conditions occur and preventDefault() is called.

Cheers,
kats

On Thu, May 5, 2016 at 3:21 PM, Justin Dolske  wrote:
> How will a developer know when it would be worthwhile to mark their event
> listener as passive? Do we perhaps log something to the console?
>
> Justin
>
> On Wed, May 4, 2016 at 3:19 PM, Kartikaya Gupta  wrote:
>>
>> Summary: Authors can declare in their addEventListener call that the
>> listener will not be calling preventDefault() on the event. This
>> unlocks certain performance optimizations.
>>
>> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1266066
>>
>> Link to standard:
>> https://dom.spec.whatwg.org/#dom-addeventlisteneroptions-passive -
>> note that this intent email is specifically about the "passive" flag;
>> the AddEventListenerOptions dictionary and addEventListener
>> modifications were already implemented in bug 1266194. I don't recall
>> seeing an intent email for that but maybe I missed it.
>> There is also an explainer doc at
>> https://github.com/WICG/EventListenerOptions which might be easier to
>> read for those already familiar with DOM events.
>>
>> Platform coverage: all platforms
>>
>> Estimated or target release: Hoping to get it in Firefox 49. I wrote
>> the patches today (they were pretty small) hence combining the intent
>> to implement and ship into this email rather than sending two separate
>> emails.
>>
>> Preference behind which this will be implemented: none at the moment
>>
>> Other browsers: See
>> https://github.com/WICG/EventListenerOptions#status-of-implementations
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: "passive" option for AddEventListenerOptions

[Justin Dolske]

How will a developer know when it would be worthwhile to mark their event
listener as passive? Do we perhaps log something to the console?

Justin

On Wed, May 4, 2016 at 3:19 PM, Kartikaya Gupta  wrote:

> Summary: Authors can declare in their addEventListener call that the
> listener will not be calling preventDefault() on the event. This
> unlocks certain performance optimizations.
>
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1266066
>
> Link to standard:
> https://dom.spec.whatwg.org/#dom-addeventlisteneroptions-passive -
> note that this intent email is specifically about the "passive" flag;
> the AddEventListenerOptions dictionary and addEventListener
> modifications were already implemented in bug 1266194. I don't recall
> seeing an intent email for that but maybe I missed it.
> There is also an explainer doc at
> https://github.com/WICG/EventListenerOptions which might be easier to
> read for those already familiar with DOM events.
>
> Platform coverage: all platforms
>
> Estimated or target release: Hoping to get it in Firefox 49. I wrote
> the patches today (they were pretty small) hence combining the intent
> to implement and ship into this email rather than sending two separate
> emails.
>
> Preference behind which this will be implemented: none at the moment
>
> Other browsers: See
> https://github.com/WICG/EventListenerOptions#status-of-implementations
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

New signatures for e10s IPC error crashes

[Benjamin Smedberg]

Starting today, there is a change to crash signatures for a subset of e10s
crashes. If the parent Firefox process detects that the child process has
sent broken or unprocessable IPDL data, or is not shutting down in a timely
manner, it kills the child process with a crash report. These crashes will
now have a signature that indicates why the process was killed, rather than
the child stack at the moment.

The new signatures will look like "IPCError-browser |
(msgtype=0x7,name=???) Route error: message sent to unknown actor ID"

We intend to reprocess this back to 27-April for better e10s analysis.

--BDS
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement and ship: "passive" option for AddEventListenerOptions

[Kartikaya Gupta]

Summary: Authors can declare in their addEventListener call that the
listener will not be calling preventDefault() on the event. This
unlocks certain performance optimizations.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1266066

Link to standard:
https://dom.spec.whatwg.org/#dom-addeventlisteneroptions-passive -
note that this intent email is specifically about the "passive" flag;
the AddEventListenerOptions dictionary and addEventListener
modifications were already implemented in bug 1266194. I don't recall
seeing an intent email for that but maybe I missed it.
There is also an explainer doc at
https://github.com/WICG/EventListenerOptions which might be easier to
read for those already familiar with DOM events.

Platform coverage: all platforms

Estimated or target release: Hoping to get it in Firefox 49. I wrote
the patches today (they were pretty small) hence combining the intent
to implement and ship into this email rather than sending two separate
emails.

Preference behind which this will be implemented: none at the moment

Other browsers: See
https://github.com/WICG/EventListenerOptions#status-of-implementations
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: invalid values behave like "metadata", not "subtitles"

[Aryeh Gregor]

On Thu, May 5, 2016 at 4:32 PM, Florin Mezei
 wrote:
> Do you still intend to do some analysis to see whether this will be a
> problem in real life? We have somewhat of a history in shipping changes that
> break compatibility, and then end up doing dot releases (in some cases).

I wasn't planning on putting in the work unless others thought it was
really necessary.  In the linked bug, Boris wasn't sure.  I don't know
anything about the feature's deployment, but I'd venture to guess that
it's not so widespread that the number of misuses would be too
significant in absolute terms.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

RE: Intent to ship: invalid values behave like "metadata", not "subtitles"

[Florin Mezei]

Do you still intend to do some analysis to see whether this will be a
problem in real life? We have somewhat of a history in shipping changes that
break compatibility, and then end up doing dot releases (in some cases).

-Original Message-
From: dev-platform
[mailto:dev-platform-bounces+florin.mezei=softvisioninc...@lists.mozilla.org
] On Behalf Of Aryeh Gregor
Sent: Wednesday, May 04, 2016 4:47 PM
To: dev-platform@lists.mozilla.org
Cc: Philip Jägenstedt ; Simon Pieters 
Subject: Intent to ship: invalid  values behave like "metadata",
not "subtitles"

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1269712

Relevant change in standards:
https://github.com/whatwg/html/issues/293, also maybe
https://www.w3.org/2015/10/28-htmlcue-minutes.html

Bugs filed against other UAs:
https://bugs.chromium.org/p/chromium/issues/detail?id=608772
https://bugs.webkit.org/show_bug.cgi?id=157311
https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/7426340
/

Invalid values for  are currently treated as "subtitles"
by all UAs, pursuant to old specs.  This means that if we want to add any
new values in the future, old UAs will treat them as subtitles, which might
result in undesired behavior.  As such, several months ago, the spec was
changed to treat invalid values as "metadata", so UAs will ignore
unrecognized values.  No UA has yet implemented the new spec.

The risk in implementing this is that sites might be inadvertently using
invalid values right now and relying on the fact that they get treated as
"subtitles".  I haven't done any telemetry or other analysis at this point
to gauge if this will be a problem in real life.

If there are no objections, I intend to land this change on Sunday.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Release Management project of the month: Static Code Analysis - A brief description of what tools we use for Mozilla products

[Andi Bogdan Postelnicu]

Hello from Release Management! 

Once a month we highlight one of our projects to help the Mozilla community 
discover a useful tool or an interesting contribution opportunity. 

This month's project is Static Code Analysis -  A brief description of what 
tools we use for Mozilla products.

The topics that we want to approach are: 

1. What is Static Code Analysis
2. What tools do we use
3. Some interesting examples
4. What we've achieved using it
5. What we've achieved using it
6. How to get involved 

The presentation will be on Monday, 9th of May at our Weekly Updates.

For a more in depth presentation you can read my blog post: 
http://blog.influx.ro/2016/05/03/static-code-analysis/ 

Feedback and ideas are always welcome! 

Thank you,
ANdi
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform