977139 - Select list options visually truncated in XHTML

Status: NEW

(Core :: XML, defect)

Comment 1

[nemo]

Sorry. Forgot the description:

URL is to a demonstration page.  The last item visible in the select should be 10,000.  I've seen anywhere from 878 to 6000-something.
I reproduced under Nightly and Stable,  OSX, Windows and Linux, on two separate networks, although bz was not able to reproduce.

I was not able to reproduce in Firefox under Android.

document.forms[0].elements[0].options.length returns the right count, so I think the problem is purely visual.

Comment 2

[Mats Palmgren (inactive)]

I can reproduce this in Nightly on Linux64 opening the URL in a new window
and then doing Shift+Reload (it doesn't occur on the initial load for some
reason).

Comment 3

[Mats Palmgren (inactive)]

The bug only occurs for XHTML, not HTML.  It appears to be a XML sink bug.
I'm dumping the content that gets notified in nsContentSink::NotifyAppend
and we simply don't get the last <option>s there.

Fwiw, if I add "return true;" as the first line in nsContentSink::IsTimeToNotify()
the bug does not occur.  It appears we return false due to mInMonolithicContainer
being true until we see the select end-tag.  Maybe we need to do something when
we finally do see it? (i.e. when decrementing mInMonolithicContainer in
nsXMLContentSink::CloseElement).

Comment 4

[nemo]

While it is a lot easier to make it appear this way, I think I also just encountered it on a simple "month" dropdown with 12 options.
At least, the behaviour is fairly identical.

It completely breaks this form for Firefox users...

(sorry, I keep accidentally putting comments in "user story" since it is the first large textbox that appears on the bug form in w3m)

Comment 5

[nemo]

Updated title since the most recent form was a modestly sized list and normally formatted, and prior comments seem to suggest it is just luck of the draw.
The long list just makes it easy to reproduce.