User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031215 Firebird/0.7 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031215 Firebird/0.7 Hi, I tried to understand why and when the bug show up, but I was not successfull. I experienced the problem with Firebird 0.7 under GNU/Linux (Debian sid) and window 2000, the problem show up also on Mozilla 1.5 (Debian package 1.5-3) always with the same html code I made. (my html code is bad and ugly, sorry about that) In order to experience the bug, just go to this address : http://www.amigrave.com/select_box_bug/ Use the very first selectbox and select a value greater than 9 ... eg 14, once selected, only the first digit will be diplayed (eg 1 if you selected 14) The second select box will have the same behaviour, but the other ones (the one that are used for a birthdate) are ok. I wished i could help more than just reporting the bug. Reproducible: Always Steps to Reproduce: 1. go to http://www.amigrave.com/select_box_bug/ 2. use the first select box and select 14 Actual Results: The select box doesn't display correctly the selected option name. Expected Results: Should be displayed correctly

- This occurs only in quirk mode. - Neither TABLE nor DD can be removed from the minimal testcase

Confirming on a 20031220 Linux CVS build. -> Layout: Form Controls

Is this a reflow or painting problem?

Not sure. Probably reflow. Definitely not an invalidation problem.

Hmm, a frame dump seems to show that the text frame is actually holding the string "1". Okay...

This bug is quite a bad regression in basic forms functionality...

It appears to be related to the DD quirk in quirks.css

Also, I get this interesting warning: WARNING: blowing an incremental reflow targeted at a nested inline, file nsBlockFrame.cpp, line 1575

OK, so what appears to be happening is that the block frame is dropping (or mistargeting) the incremental reflow that is supposed to reflow the text frame in the combobox's display area. Thus the text frame never updates its content offset and length. This could be tough :-)

The bug seems to be that the line containing the dd:before's newline should be marked as break-after, but isn't.

Here's a standards-mode reduced testcase. Apparently white-space:pre line breaks never cause a line break type to be recorded, probably because of this code around nsBlockFrame:3697: if (breakType == NS_STYLE_CLEAR_LINE) { if (!aLineLayout.GetLineEndsInBR()) { breakType = NS_STYLE_CLEAR_NONE; } } I'm not quite sure why this is being done...

Removing that code does fix the bug. The question is, what does it break :-).

blocking 1.6

Changing to blocking1.6- because: * the bug is rather rare since it requires a complicated set of conditions to see the bug * this regressed between 0.9.7 and 0.9.9, so we've lived with it for a few years without anyone noticing * the patch seems like it could be risky. It would be good to fix this on the trunk, though.

roc accidentally checked in the change described in comment 12 and it caused bug 230852.

Here's a simple, logical patch that doesn't cause the regression in bug 230852.

fix checked in