This bug was filed from MDN. Firefox is hanging, and manually crashing produces this crash report: After upgrading our version of Firefox, we aren't able to use dropdown list containing a large amount of items (at least several hundred). Firefox hangs, uses 100% of a CPU core, and we get a script debug window. I went back to use an older version of Firefox 53.X and did not have this problem. Note that this issue only appears to happen on Citrix servers which run Server 2012 R2. Note that the URLs in question are on our intranet (sharepoint and SSRS) Please include any other information such as steps to reproduce. bp-a94b4ec4-faf9-41ac-b429-a33090170912 - https://crash-stats.mozilla.com/report/index/bp-895f7e66-c78c-467b-a2a6-d2da51170912 bp-5f35704e-adb8-4ac9-bff1-ee29e0170912 - https://crash-stats.mozilla.com/report/index/bp-5f35704e-adb8-4ac9-bff1-ee29e0170912
I don't think this bug is the same as 1376200. We also receive a script error every time: script: chrome://global/content/bindings/text.xml 36
I found this if I enable ANY type of add-in, that the issue does not occur. If I then disable the add-in, the issue happens once again
Confirmed this behavior on Windows 10, Server 2008 R2, and Server 2012 R2
Jim, can you please take a look at the crash reports provided by Brad? Also, Brad, can you please attach the "about:support" page in a .txt document for the machine described in comment 4? You can do this by navigating to "about:support" page and click on the "Copy raw data to clipboard" button.
Created attachment 8910298 [details] about:support raw data Hello, here is the about:support information that you requested
(In reply to Brad Walker from comment #0) > bp-a94b4ec4-faf9-41ac-b429-a33090170912 > https://crash-stats.mozilla.com/report/index/bp-895f7e66-c78c-467b-a2a6-d2da51170912 This crash happens in a new background thread, which is attempting to call the system's dll load entry point from within our dll interceptor code. The function pointer we try to invoke though is null. This is after the browser is up and running (uptime of 116 seconds). A bit of a mystery at this point. Took a look at the modules list but I don't see anything 3rd party / anti-virus in our process space. Another mystery since these types of crashes are usually caused by 3rd party software injection. Comment 3 is also throwing me a bit, extension role in this is unknown. Brad, are you running any form of anti-virus or corporate sign-on assistance or corporate snoop software on these machines?
We run McAfee Enterprise 8.8. No snoop software
(In reply to Brad Walker from comment #0) > This bug was filed from MDN. Firefox is hanging, and manually crashing > produces this crash report: > > After upgrading our version of Firefox, we aren't able to use dropdown list > containing a large amount of items (at least several hundred). Firefox > hangs, uses 100% of a CPU core, and we get a script debug window. I went > back to use an older version of Firefox 53.X and did not have this problem. > Note that this issue only appears to happen on Citrix servers which run > Server 2012 R2. Note that the URLs in question are on our intranet > (sharepoint and SSRS) > > > Please include any other information such as steps to reproduce. > > bp-a94b4ec4-faf9-41ac-b429-a33090170912 - > https://crash-stats.mozilla.com/report/index/bp-895f7e66-c78c-467b-a2a6- > d2da51170912 > > bp-5f35704e-adb8-4ac9-bff1-ee29e0170912 - > https://crash-stats.mozilla.com/report/index/bp-5f35704e-adb8-4ac9-bff1- > ee29e0170912 Reading back over this, I think maybe you've just hit bug 1118086. If you let the browser sit for a second, does the menu eventually populate?
I don't think this is the same issue as bug 1118086. The menu never becomes usable even after several minutes. The browser completely freezes up unless I stop the script running on the page but the menu still doesn't work even after stopping the script
(In reply to Brad Walker from comment #10) > I don't think this is the same issue as bug 1118086. The menu never becomes > usable even after several minutes. The browser completely freezes up unless > I stop the script running on the page but the menu still doesn't work even > after stopping the script If this happens when using a drop-down menu with a large number of items, this is certainly a duplicate of bug 1118086. The amount of time it takes for the menu to open up depends on the number of items in the menu (the test case we had on the bug had 10,000 elements in it) and the speed of the machine, etc. If you stop the script as it is running, the menu will never open up and that's expected (even though undesirable, of course.)
I am not stopping the script. The script never finishes running from what I can see. If you let the script continue to run, the browser freezes indefinitely. Why does enabling at least one add-on to Firefox resolve the issue and why doesn't 53.X have this issue?
Do you mind please going to about:support in both a 53.x build and when you enable one add-on and select Copy Text To Clipboard and paste the results here separately? My suspicion is that in both cases what's happening is that Firefox is going into single process mode, where we don't have the performance problem with large drop-down lists, and that's what causes the performance problem to go away for you. Having the about:support output in those two modes would allow me to confirm this theory.
Hello Brad, Can you please provide the requested info from comment 13? Thanks.
Moving from Core::Untriaged to Core::General https://bugzilla.mozilla.org/show_bug.cgi?id=1407598
(In reply to Cristina Badescu from comment #14) > Hello Brad, > > Can you please provide the requested info from comment 13? Thanks. Hello, Sorry I have been out of the office. I will try to have this done this week Thanks, Brad
Thanks Brad for providing the requested info. Based on comment 17, Ehsan's theory seems correct and e10s is the cause of this issue. I'm moving it to Core:: Layout: Form Controls.
Hello, is this something that will be patched in a future version? I am worried that at some point my workaround of adding an add-on to Firefox will not resolve the issue. Thanks, Brad
Brad, do you have steps to reproduce the crash? I don't find URL info in your crash reports.
(In reply to Brad Walker from comment #19) > Hello, is this something that will be patched in a future version? I am > worried that at some point my workaround of adding an add-on to Firefox will > not resolve the issue. Thanks, Brad Yes. The work is in progress now. As comment 20, it would be great if you can provide a test case or steps to reproduce so that we can verify it upon completion.
(In reply to Astley Chen [:astley] (UTC+8) from comment #21) > As comment 20, it would be great if you > can provide a test case or steps to reproduce so that we can verify it upon > completion. A simple Select with 10000 Options is enough to hang the browser for some seconds, when clicking on it. Here a fiddle: https://jsfiddle.net/291e0zLy/
In Bug 1118086 Comment 87, mats proposed that we should render the dropdown menu in the content process. That will resolve the performance issues, the styling issues, and I'm working on it in Bug 1421229. I tried the test case in comment 22, and the performance is really well.
(In reply to Astley Chen [:astley] (UTC+8) from comment #21) > (In reply to Brad Walker from comment #19) > > Hello, is this something that will be patched in a future version? I am > > worried that at some point my workaround of adding an add-on to Firefox will > > not resolve the issue. Thanks, Brad > > Yes. The work is in progress now. As comment 20, it would be great if you > can provide a test case or steps to reproduce so that we can verify it upon > completion. . Hello, I don't seem to be having drop-down issues anymore since the upgrade to Firefox 57. I will let you know if the issue reoccurs. Thank you for your assistance
Firefox 57.0.1 and even the 59.0a1 (2017-12-03) need at least 3 seconds to load the 10000 options (comment #22). Tested Mac and Windows. Pre e10s FX and other browsers don't have a problem with that.
(In reply to Chris from comment #25) > Firefox 57.0.1 and even the 59.0a1 (2017-12-03) need at least 3 seconds to > load the 10000 options (comment #22). > Tested Mac and Windows. > Pre e10s FX and other browsers don't have a problem with that. I am seeing that issue as well