Chrome only, it seems. Disappointing. https://twitter.com/brianleroux/status/524987137892954112
We also ran into a recent difference in the way sparse JS arrays as handled. We use sparse JS arrays for some data structures, but array.splice(0) on Chrome runs much faster than FF when using this to clone a sparse array.
There's no intent to exclude Firefox, engineers are staying late in the office working on it.
Instead, you could just notify the user that performance may not be as good on other browsers for now.
"There's no intent to exclude Firefox", it just turns out you've done that for like 2 major product releases in a row along with a giant flashing button suggesting that the user downloads Chrome. I'm not stupid, you don't have to lie to my face.
Try typing this into a JS Console: var xx = []; xx[30000000]=42; var yy = xx.slice(0);
It took almost a week to track down this problem where FF was taking 13 seconds to startup. We've spent a lot of time working on this and it is always in the cards to support this on all the other browsers. We've fixed tons of bugs and have gotten closer to it working the way it should, and people have spent countless hours staying very late at the office to try and finish a polished FF release before the deadline, and we just didn't make it in time. I spent the past 5 years of my time working on open web stuff.
Any insinuation that this is an attempt to sell Chrome over Firefox is just flat out wrong. This was a "mobile first" designed app, it's not designed to promote browsers of any stripe, it's designed to promote an experience for gmail users. If we really wanted to shit over a platform, why bother with iOS? Firefox has such a large user base, it can't be ignored, just like iOS can't.
What specific problems does this create that prevents you from shipping with a degraded experience?
Or feature detect this problem and serve some type of notice.
If bleeding-edge Chrome is the only browser good enough for this site then it's a problem with the site's architecture.
> Any insinuation that this is an attempt to sell Chrome over Firefox is just flat out wrong.
Maybe not you in the engineering team, but the designers / PMs who decided to stick a "install Chrome instead" banner definitely had it in mind.
> Firefox has such a large user base, it can't be ignored, just like iOS can't.
That's either a lie or incredibly naive. You wouldn't have shipped without iOS. Full-stop.
It's not just a degraded experience as in 'turn off this feature', the bug in question affects the entire infrastructure of how the app works, since it is part of the message passing and serialization mechanism used. It's legal, standard, JS, that just happens to run slow.
In this case, a workaround is available, and it is already fixed, but not shipped, because we froze commits some time ago for launch.
> That's either a lie or incredibly naive. You wouldn't have shipped without iOS. Full-stop.
You mean like we didn't ship support for Android tablets? You would have thought with the big Android Lollipop and Nexus 9 launch, we would have made sure this worked there, right?
Maybe you should think about Hanlon's Razor as an explanation.
https://bugzilla.mozilla.org/show_bug.cgi?id=1087963
There's also this earlier bug that seems related:
Try it yourself: http://canhaz.azurewebsites.net/ http://www.browserstack.com/start#os=Windows&os_version=XP&b...
That said, it's clearly possible to do this fast _and_ correctly (e.g. IE manages this).
But as a note, some V8 folks would like to remove the buggy-but-fast thing completely. See https://code.google.com/p/v8/issues/detail?id=3612#c2
Is there a point of contact for rendering/paint performance issues? We've had problems in Chrome where we had to work around excessive invalidation/paints, but those were diagnosed by using Chrome's layer/paint debugging tools and talking to Blink engineers, things may go quicker if when we encounter problems, there's someone we can email for help or a fix.
What VerGreeneyes says is true for our JS engine, too: you can always file bugs in our bugzilla (in the "Core/ JavaScript Engine" component). We react to such bugs very promptly (as you can see in bug 1087963[0] which was fixed six hours after being filed) and, in many cases, can uplift patches from Nightly to Aurora and maybe Beta, so they'll reach release builds more quickly.
If for some reason you're not comfortable with filing a publicly visible bug, you can also abuse the flag for filing security-sensitive bugs. That way, we may be better able to help with issues affecting unannounced products.
For asking questions or getting our attention even more quickly, you can either join us in the #jsapi channel on irc.mozilla.org, send mail to dev.tech.js-engine[1], or send mail to one of the SpiderMonkey engineers directly. A list of these engineers is available at [2], or you can just email me at [my nick]@mozilla.com.
[0] https://bugzilla.mozilla.org/show_bug.cgi?id=1087963 [1] https://lists.mozilla.org/listinfo/dev-tech-js-engine [2] https://wiki.mozilla.org/index.php?title=Modules/Core#JavaSc...
I'll make sure we file bugs as repro-case-able issues come up, but if we get stuck on a deeper mystery, we may need some more direct help. We've made a lot of progress, and from a logic and speed issue, a lot has been resolved and mostly working, but animations are janky, and from "subjective" speed point of view, it unfairly makes FF look bad. Based on previous experience with Chrome, hitting the sweet spot of 60fps is usually where the JS developers need help from the rendering engine folks.
Does "will work on FF" mean "FF will eventually be supported"? Because today we see: "Inbox only works in Google Chrome. More browsers coming soon. Download Google Chrome."