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.
Thanks Mozilla for the quick reaction. We were not really blocked on this as a for-in/Object.getOwnPropertyNames loop is an easy workaround, it's more that finding the cause of an unexplained slow down took a bit of time (the usage comes from another engineer's rpc-serialization library)
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.
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.
That makes a lot of sense, yes. We can profile cases like that and get info/help from people working on the relevant components. It happens fairly frequently that we move perf bugs from the JS component into GFX or DOM bindings or something else entirely. So really, just file a bug in one of these components, maybe CC a person you already interacted with or send an email, and we'll do the triage.
If you just file a bug on Bugzilla (https://bugzilla.mozilla.org/) in the Core: Graphics component with a reproducible testcase that will probably get people looking at it pretty quickly. For more one-on-one contact I'd suggest the #gfx channel on the Mozilla IRC, although that tends to work best if you know who to reach out to specifically. The gfx newsgroup (https://groups.google.com/forum/#!forum/mozilla.dev.tech.gfx) might also work to call attention to a particular issue. You can probably setup an e-mail contact through one of those channels if that's what you prefer.
This is a real Firefox bug, but consider the reverse situation: if Firefox's slice() was fast and Chrome's was slow, would Google ship Inbox with a message that says "Inbox only works in Mozilla Firefox. More browsers coming soon. Download Mozilla Firefox."? Probably not. The Inbox team would probably pull in the V8 team. Apparently, the Inbox team didn't contact Mozilla's SpiderMonkey team because they fixed their bug within a couple hours:
Even more odd is they still have their message about FF not being supported for Inbox up for Nightly. I just switched my User Agent to Chrome and Inbox works fine in FF.
I can sympathize with you because cross-browser development can be frustrating at times. However, when you ship a product and only support one browser (which happens to be the browser your company makes) you're making a statement (even if it's only implicit) that you don't really care about the open web. You personally may care about the open web, and I'm glad the issue is fixed internally, but releasing a major web application with support for only one web browser is a big "fuck you" to the web.
>What specific problems does this create that prevents you from shipping with a degraded experience?
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.
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.