If generated content refers to an attribute value, changing the attribute does not cause reflows to occour.

The style change code is now in, the first attachment demonstrates the fix. However, there is still a bug left in the reflow code. If you look at the second test case, the generated content frame doesn't re-maesure the text during reflow properly. The only difference is the lack of whitespace between the static text and the attribute text. This is either a bug in reflow code related to text measurement and whitespace, or a bug in the attribute content node (perhaps attaching itself to the previous text node if no whitespace?). Sending this to Rod first to look at the attribute content node. If that's not it, send on to Troy or Kipp to look at the text measurement code.

Kipp had to clean up my AttributeContent node because I wasn't doing a lot things correctly. I defer to him - reassigning

adding myself to the cc list

umm, so I touched your code -- big deal? why is this suddenly my problem. I have no clue how it's supposed to work (only peter knows). Talk to him, or find somebody else. sorry!

Fixed. The block and line-layout logic were not properly propogating StyleChange reflow reasons nor were they mapping incremental reflows into StyleChange reflows appropriately. Now they do and clicking on the test button in the first testcase works dandy. I never saw anything wrong the last testcase so I can't speak to that.

I tested this with attachment 2266 [details] and it does not update properly. With the combobox showing, click on it to give it focus. Then press the "r" key to select the "Red Fish" item. The item is selected but the select displays the wrong value and therefore it hasn't been reflowed correctly. When the mouse moves out of the select it is reflowed from style and updates correctly.

Well, its not a layout problem in any obvious sense. I turned on reflow command dumping in the presshell (env NSPR_LOG_MODULES="verifyreflow:8" ...) and there is no reflow command being generated when the "r" key is pressed. Therefore it must have something to do with how the drop-down code handles events. Back to you rod.

After talking to Kipp and getting a better understanding of what is going on with reflow, the bug is appears that the select is making the reflow happen correctly (bug 14771) and this bug should not have been reopened - marking as fixed.

Verifying fixed.

Migrating from {css2} to css2 keyword. The {css1}, {css2}, {css3} and {css-moz} radars should now be considered deprecated in favour of keywords. I am *really* sorry about the spam...