From Bugzilla Helper: User-Agent: Mozilla/4.73 [en] (WinNT; U) BuildID: 20000071108 This report probably shows two different bugs. Not sure. Please read on. The attached testcase shows the definition of an incomplete CSS border shorthand (missing color) with an hover selector. IMHO this construct is parsed/applied in the wrong way. Reproducible: Always Steps to Reproduce: 0. Close Mozilla and restart it! 1. Load the attached testcase (2. you may run into bug 45209, incorrect layout) 3. Move the mouse across the browser window and notice the effects. Actual Results: 4. Suddenly, the images/the document will be reflowed. (This is caused from the hover selector, I assume. 5. Maybe - I'm not definetly sure - the effect also occurs if the mouse is moved over an unrelated element (f.e. the H1/H3 tags). I don't know enough about the propagation of :hover in this szenario. Expected Results: a) Initial layout as described under #45209 b1) The selector should (IMHO) select only IMG elements (if any). b2) The imcomplete shorthand should be either ignored or parsed into a no-border style b3) All elements in the parent chain of all IMGs have an initial (complete) no-border style, ie. border:0px solid black. b1+b2+b3) There should not be any reflow, because changing from no-border to no-border should be a visual no-op. This bug may be restricted to standard mode. This bug may be related to #45209 - using tables with position:absolute makes things definetly worse - but has also aspects which are unrelated to #45209.

Changed component - sorry.

This has nothing to do with borders. I modified the testcase to not mention borders anywhere, and to not apply the :hover to IMG elements, and the problem is still present. I will attach a simpler test case.

To reproduce: Hover over the text in the latest attachement. Results: Strange reflows in the absolutely positioned table. Expected Results: The :hover rule should have NO effect, since it refers to nonexistant elements. Tested on Mozilla 2000072008 build.

:hover and abs pos are CSS2, not CSS1.

I reduced the tescase further: I removed everything but the abs. pos. table and it flashes when I hover over the table, click on the body, or mouse-into the body (using Viewer). I'll see what is happening in SelectorMatches because, as Ian mentioned, the selector should match nothing.

This may be one of the cases where having the style context parentage out of synch with the frame parentage is causing grief. When FrameManager::ReResolveStyleContext is called for the TableOuterFrame content node, it is calling aPresContext->ResolveStyleContextFor on the TableOuterFrame but is passing in the parent style context of the parent frame, in this case the Body element. However, the parent style context for the TableOuterFrame's context is the TableInnerFrame's context, not the Body element's context, so when CaptureChange is called to compare the old and new contexts, if returnes out REFRAME and the frametree gets rebuilt. Given this particular code path, it appears that there are at least some serious performance impacts to not having the style tree match the frame tree - Could CaptureChange also err the other side and indicate less change than is really required because the context of the parent causes the child's new context to be closer to what it was then what it really should be? This looks like it could be illustrative of potential problems with other frames who's style context heirarcies do not match the frame tree's heirarchy (like several XBL frames). CC'ing Hyatt since we hav been discussing this issue in the context of another problem. Excellent find, Matthias - thanks for reporting this, and thanks to whoever CC'd me on it.

*** Bug 46099 has been marked as a duplicate of this bug. ***

As per meeting with ChrisD today, taking QA.

Critical for beta3: problems with reframing when style is re-resolved due to the inverse relationship of the stylecontext in relation to the corresponding frames.

Chris, it may be possible to get the style system to support style context parentage that is mismatched to the frame parentage: if style can call into a frame ask it for the parent-context, then it can use that parent context instead of the parent frame's context. If the frame chooses not to provide this parent-context then style will do what it does now, which is just use the parent frame's context. This can thus be implemented as a new method in nsIFrame and a default implementation can be created to return NULL, whereas the table frames can return the correct parent context. Style code wil have to change in ReResolveStyle where it walks the frame tree resolving style changes, but I think the change will be small. We need to talk it over to make sure we want to do this first, and of course if changing the table code is easier then that would be better.

How easy is it to workaround or avoid this problem?

I don't know of any way to 'workaround' this problem, other than avoiding the use of tables in web sites (which is clearly not a viable option).

Tested using the following builds: Win: 08_30_04_m18 Mac: 08_30_08_m18 Linux: 08_30_04_m18 Using Ian's testcase from 7/21, crashed on Win and Linux after hovering. Talkback incident #16599830. Details: 1. Open page 2. Hover over lines/images 3. Crash with following details: NETSCP6 caused an invalid page fault in module <unknown> at 00de:00000017. Registers: EAX=0fb6d3f0 CS=0177 EIP=00000017 EFLGS=00010207 EBX=00000000 SS=017f ESP=0068f760 Call Stack: (Signature = 0x00000017 92161e36) 0x00000017 nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 329] nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 346] nsViewManager2::DispatchEvent [d:\builds\seamonkey\mozilla\view\src\nsViewManager2.cpp, line 1429] HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 68] nsWindow::DispatchEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 618] nsWindow::DispatchWindowEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 635] nsWindow::DispatchMouseEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 3812] ChildWindow::DispatchMouseEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 4020] nsWindow::ProcessMessage [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 2909] nsWindow::WindowProc [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 884] KERNEL32.DLL + 0x363b (0xbff7363b) KERNEL32.DLL + 0x242e7 (0xbff942e7) 0x00688b3e

Maybe retry using an 8-31 build? A major crash in nsView::HandleEvent was fixed on 8-30.

Marc, I'm giving this back to you since I think it will be easier to change the style code than the table code. I tried doing the parentage the other way in tables and ran into problems which I can't seem to recall. We need to discuss this further.

Tested on Win 98 with 8/31/12 build and no crash. Will try on Linux tomorrow but as David indicated, the problem went away with a new build.

PDT thinks this sounds like a P3, as long as it doesn't crash (which it doesn't today)

Setting priority to P1 (leaving PDTP3 alone for PDT use). There is a related problem with HTMLButtonControlFrame children having the wrong parent style contexts. This needs to be fixed along with this bug I think, to avoid the same problem there.

Fixed. This required changes to: nsIFrame.h, nsFrame.h, nsFrame.cpp, nsFrameManager.cpp, nsTableFrame.h, nsTableFrame.cpp, nsTableOuterFrame.h, nsTableOuterFrame.cpp, and nsHTMLButtonControlFrame.cpp

Isn't similar work done to enable the .offsetParent DOM property?

Jonas, I'm not sure what you are refering to - can you point me to something more specific to look at please? I'm guessing that you mean that some DOM code is making assumptions about the frame tree matching the style tree? Thanks.

VERIFIED FIXED on Windows 2000 Commercial Build 2000091308 and Linux Commercial Build 2000091312 using second testcase.