1671837 - Too many option tags break Firefox

Status: NEW

(Core :: Layout: Form Controls, defect, P3)

Description

[Ricardo Gonçalves]

Attachment: select_tag_bug.zip

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:76.0) Gecko/20100101 Firefox/76.0

Steps to reproduce:

Went to http://www.boardgaming-online.com/, logged in, and tried to create a game. Tried to add players by clicking on the dropdown.

Actual results:

Firefox hung and after half a minute, a nameless, contentless window showed up. Tried to resize it or do anything, to no avail. Closed the window and Firefox was still unresponsive for a while.
After some time, the dropdown appeared, but I was unable to scroll to the very bottom.

After some digging up, I managed to track down the problem to the number of option tags in the select tag that controls the dropdown menu.
On my system, I can reproduce the issue consistently with around 14000 - 15000 entries and above.
With a little less entries, a warning shows up regarding chrome://global/content/elements/menu.js:165 or 161. Resuming the script shows up the dropdown.

Regardless of that happened, the entries in the dropdown can still be accessed by using the keyboard (tab-ing to the element and using the up and down arrows or writing to match).

However, everything in the chrome above the actual page (i.e. address bar, tab bar, menus) doesn't seem to work (even closing the tab or moving to another tab) and right-clicking on one of those elements opens up a small square context menu.
Right-clicking on the actual document still works, though. And closing the window still works.

Also, viewing the source-code of the page, without line breaks splitting the option tags, can manage to hang Firefox and leave it in an seemingly unrecoverable state.

Expected results:

The dropdown should have showed up, with all entries available to scroll through.
The window (functionally) shouldn't be disabled.

I've supplied a zip file with the Python code (3.7 up, because of f-strings) I used to create the pages that reproduce the behavior, some of the pages and also screenshots detailing what happened.

Comment 1

[Emilio Cobos Álvarez (:emilio)]

Can you check whether it works on nightly? I did a couple perf improvements to select not that long ago.

Comment 2

[Emilio Cobos Álvarez (:emilio)]

(On my machine the examples, though a bit sluggish the bigger ones, seem to work)

Comment 3

[Mats Palmgren (inactive)]

The select_bug_test_13650.htm example has horrible performance for me. Latest Nightly 2020-10-18 on Linux.
The same example in a non-e10s build is snappy.

Comment 4

[Ricardo Gonçalves]

So, I used the PortableApps version of nightly, and tested the dropdown.

At 15000, it still feels a bit sluggish for me, but it no longer shows any error alert or the "mystery" window. It also allows to scroll to the very bottom of the list.
Upping to 100000 doesn't seem to make a difference, in that it still takes a while (and Firefox becomes a bit unresponsive). It takes more time as more entries exist. However memory consumption starts to increase as well.
My limit was around 150000, with one of the Firefox processes consuming around 1.5 GB (of a system total of around 3.3 GB) and reaching a point where the system was starting to get unwieldy. This memory consumption gets down to around 700MB some seconds after closing the dropdown (which I assume is some sort of garbage collection at work, and would explain why closing and opening the dropdown in rapid succession doesn't lower the memory consumption).

It seems so that the issue has been sort of fixed in nightly (the hangs/unresponsiveness isn't nice to have though), other than the memory consumption, which I guess isn't easy to fix without redefining the internal structures that define how the option tags behave.

I'll attach the new files I generated to check on nightly, though.

Comment 5

[Ricardo Gonçalves]

Attachment: select_tag_bug_examples_1.zip

Comment 6

[Ricardo Gonçalves]

Attachment: select_tag_bug_examples_2.zip