Re: Reverting to VS2013 on central and aurora

On Fri, May 06, 2016 at 07:38:31PM -0700, Emanuel Hoogeveen wrote: > SSE2 is also required for IonMonkey, our optimizing JIT. The baseline > compiler does work without SSE2, but isn't nearly as fast. So users > running Firefox on hardware without SSE2 support are already getting > severely degraded

Re: Reverting to VS2013 on central and aurora

SSE2 is also required for IonMonkey, our optimizing JIT. The baseline compiler does work without SSE2, but isn't nearly as fast. So users running Firefox on hardware without SSE2 support are already getting severely degraded performance. On Friday, May 6, 2016 at 10:59:01 PM UTC+2, Milan Sreckov

Re: Reverting to VS2013 on central and aurora

For graphics, it’s performance if we start requiring SSE2. Lately, canvasmark benchmark, and increasingly more trouble when updating Skia library. — - Milan > On May 6, 2016, at 14:39 , Henri Sivonen wrote: > > On Fri, May 6, 2016 at 8:17 PM, Gregory Szorc wrote: >> On Fri, May 6, 2016 at 9

Re: Reverting to VS2013 on central and aurora

On Fri, May 6, 2016 at 8:17 PM, Gregory Szorc wrote: > On Fri, May 6, 2016 at 9:39 AM, Benjamin Smedberg > wrote: > >> I agree that we should drop support for non-SSE2. It mattered 7 years ago >> (see https://bugzilla.mozilla.org/show_bug.cgi?id=500277) but it really >> doesn't matter now. >> > >

Re: Reverting to VS2013 on central and aurora

While I agree we should drop non-SSE (and have started a conversation to drop non-SSE2 as well :), the comparison to dropping 10.6-10.8 users is somewhat unfair. Those users can upgrade 10.9 easier than the non-SSE users can buy a new computer. — - Milan > On May 6, 2016, at 12:22 , Gregory

Re: Reverting to VS2013 on central and aurora

If it matters for this discussion, I’m pretty sure central doesn’t build with VS2013 today. At least it doesn’t for me. — - Milan > On May 6, 2016, at 13:17 , Gregory Szorc wrote: > > On Fri, May 6, 2016 at 9:39 AM, Benjamin Smedberg > wrote: > >> I agree that we should drop support for no

Re: Intent to implement and ship: DOMTokenList.prototype.supports

On 5/4/16 9:36 AM, Boris Zbarsky wrote: Actually, that would technically be a spec violation for the moment, since HTML does define this link type and doesn't list it in the possible supported types list. I landed this without "search" in the list for the moment, pending the outcome of the spe

Re: Reverting to VS2013 on central and aurora

On Fri, May 6, 2016 at 9:39 AM, Benjamin Smedberg wrote: > I agree that we should drop support for non-SSE2. It mattered 7 years ago > (see https://bugzilla.mozilla.org/show_bug.cgi?id=500277) but it really > doesn't matter now. > Wait - are we talking about requiring SSE or SSE2? The thread up

Re: Reverting to VS2013 on central and aurora

I agree that we should drop support for non-SSE2. It mattered 7 years ago (see https://bugzilla.mozilla.org/show_bug.cgi?id=500277) but it really doesn't matter now. We do need to avoid updating these users to a build that will crash, and do the same "unsupported" messaging we're doing for old ver

Re: Reverting to VS2013 on central and aurora

On Fri, May 6, 2016 at 7:10 AM, Mike Hoye wrote: > On 2016-05-06 12:26 AM, Gregory Szorc wrote: > >> 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

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

On Thu, May 5, 2016 at 10:48 PM, Boris Zbarsky wrote: > Support in other browsers: I believe Chrome supports this. I'm not sure > what the state is in other browsers. > Looks like chrome 46: https://www.chromestatus.com/feature/5708368589094912 I'm happy to see this implemented since I've had

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

That's what I figured, but the articles about it didn't seem to say, and the late hour caused me not to think to look at the spec itself. Good deal. > That's a no-op per https://dom.spec.whatwg.org/#dom-event-preventdefault. -- Eric Shepherd Senior Technical Writer Mozilla Developer Network

Re: Reverting to VS2013 on central and aurora

I think we should strongly consider just requiring SSE at this point. - Kyle On Fri, May 6, 2016 at 7:10 AM, Mike Hoye wrote: > On 2016-05-06 12:26 AM, Gregory Szorc wrote: > >> FWIW, the crashes we've seen so far are from incorrectly emitted movss >> instructions. This instruction is part of t

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

Correct, the preventDefault() is ignored from a passive listener, and we will probably log a warning to the console (I have a patch up for review that does that, let's see what smaug says). On Fri, May 6, 2016 at 1:01 AM, Anne van Kesteren wrote: > On Fri, May 6, 2016 at 4:43 AM, Eric Shepherd w

Re: Reverting to VS2013 on central and aurora

On 2016-05-06 12:26 AM, Gregory Szorc wrote: 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 X

Re: Intent to deprecate: MacOS 10.6-10.8 support

On Fri, May 6, 2016 at 8:24 PM, Mike Hommey wrote: > On Fri, May 06, 2016 at 06:01:12PM +1000, Xidorn Quan wrote: > > > > It's Firefox 48, three versions after ESR 45, which is roughly halfway > > before the next ESR. > > 48 is the first version that will *not* have 10.6-10.8 support. On Mon, M

Re: Reverting to VS2013 on central and aurora

On Fri, May 06, 2016 at 12:25:54AM -0700, Chris Peterson wrote: > On 5/5/16 9:26 PM, Gregory Szorc wrote: > > 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 compatibl

Re: Intent to deprecate: MacOS 10.6-10.8 support

On Fri, May 06, 2016 at 06:01:12PM +1000, Xidorn Quan wrote: > On Fri, May 6, 2016 at 5:39 PM, Chris Peterson > wrote: > > > On 5/5/16 8:23 PM, sfbay.mapfi...@gmail.com wrote: > > > >> The best option, from my perspective (supporting a wide array of users, > >> OS versions, hardware), is to make

Re: Intent to deprecate: MacOS 10.6-10.8 support

On Fri, May 6, 2016 at 5:39 PM, Chris Peterson wrote: > On 5/5/16 8:23 PM, sfbay.mapfi...@gmail.com wrote: > >> 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 p

Re: Intent to deprecate: MacOS 10.6-10.8 support

On 5/5/16 8:23 PM, sfbay.mapfi...@gmail.com wrote: 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. M

Re: Reverting to VS2013 on central and aurora

On 5/5/16 9:26 PM, Gregory Szorc wrote: 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,