e10s is off. Go to http://pf-jenkins.qa.mtv2.mozilla.com:8080/job/webrtc-aurora-mac10_8-nightly-mac/configure Note that you get a Script Unresponsive error. This is a regression.

I can't reproduce this (the host is not reachable, presumably it's only available in the MV office?), and you didn't provide the name of the script (which should be in the dialog). Is this a regression in that jenkins page, or a regression of Firefox (in that if you use e.g. beta or release or develope edition, you get no such dialog) ? If it works in earlier versions of Firefox, can you use one of them to save the full webpage, stick the result in an archive, and upload it as an attachment so other people can reproduce? (ideally verifying that the archived pages continue to produce the slow script warning on newer versions of Firefox, like the live page)

The webpage is indeed behind the MTV firewall. However, it reproduces on my Jenkins instance at home as well. Any job configuration triggers it. It does NOT reproduce with FF 34.0; the page comes up instantly. The script from the dialog is http://pf-jenkins.qa.mtv2.mozilla.com:8080/47b20ca2/lib/form/section._js:49. The code at that line: 48: function visitor(dom,parent) { 49: for (var e=dom.firstChild; e!=null; e=e.nextSibling) { 50: if (e.nodeType==1) { 51: if (e.className=="section-header") { 52: var child = new SectionNode(e); 53: parent.children.push(child); 54: visitor(e,child); 55: } else { 56: visitor(e,parent); 57: } 58: } 59: } 60: } The attachment contains a local save of the webpage. FF 37 loads the local save instantaneously, so I can not reproduce the problem with the local save.

Some more information: - It only happens when LastPass is turned on. - It happens in Nightly all the way back on 12/9/14 build. - It does NOT happen on Aurora, Beta and Release.

Using mozregression, I was able to isolate the inbound build this started happening on: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=4af6737ce10b&tochange=dd83a9dcc8cc

Ally, I used mozregression to trace this down to this build: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=4af6737ce10b&tochange=dd83a9dcc8cc You have a patch in this build: https://hg.mozilla.org/integration/mozilla-inbound/rev/c6d53703d449 It looks like there are e10s shims conditional on NIGHTLY builds being done. Could this be affecting interactions with LastPass, even with e10s turned off?

It very well could. The shims are installed on nightly regardless of e10s-off/on pref.

So what to do with this bug then? Contact the LastPass maintainers? How do I find out who they are?

(In reply to Syd Polk :sydpolk from comment #7) > So what to do with this bug then? Contact the LastPass maintainers? How do I > find out who they are? Andrew, do you or your team have someone who could look into its compatibility with Nightly/e10s? (it's the future! :-) )

If someone can provide me with a link I can reach that exhibits the problem, I can take a quick look. However, it's worth noting that we're considering moving to a completely different extension (based on our current Chrome extension) that uses the add-on SDK, for the purposes of becoming e10s-compatible. So, this may become moot.

So, it happens to me in both a Jenkins instance behind the corporate firewall and a jenkins instance on my personal machine. You should be able to setup Jenkins on a VM, add a job, and the configuration page will show it. I'll see if I can get you public access to one that shows the problem...

Bill, we've got a poorly performing addon with e10s turned off, but it was caused by turning shims on by default.

Let me know if/how I can help a developer reproduce this bug; for those with a MoCo LDAP, I can give you a test job to play with on https://webqa-ci.mozilla.com/ (publicly viewable) with the right permissions, too, to be able to hit a /configure page and hopefully reproduce/debug the issue.

I can see the same for our Mozmill CI instance when we run release tests with about thousands of jobs in the queue. The Jenkins dashboard is totally unresponsive and Firefox halts for about 10s each 15s! It's totally unusable. In my case it's the prototype.js module which causes this dialog. Syd, which script is it in your case?

Hopefully we'll fix this in bug 1116854.

This is still happening in Nightly with version 42. This is NOT happening in Aurora in version 41, even though e10s appears to be in Aurora and is turned on.

stephend told me that this is a major thorn in our QA folks' sides and asked if we could take another look at this, renomming.

I'd recommend trying our e10s build: https://rodan.lastpass.com/dev/lp_e10s.xpi

Stephen, mind answering comment 17?

(In reply to Andrew Zitnay from comment #17) > I'd recommend trying our e10s build: > > https://rodan.lastpass.com/dev/lp_e10s.xpi Oh, thanks _such much_! That's definitely a night-and-day difference, in terms of performance + [lack of] "system-busy" cursors -- on both Windows and OS X platforms.

Marking WFM in that case, thanks for the fast responses!

(In reply to Blake Kaplan (:mrbkap) (please use needinfo!) from comment #20) > Marking WFM in that case, thanks for the fast responses! NP; I'd still, though, like to hear Syd weigh in as well, since he filed this - hopefully his experience matches :-)

That's much better! Thanks!