User Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0a1) Gecko/20110903 Firefox/9.0a1 Build ID: 20110903030832 Steps to reproduce: 1. Go to the http://www.wetterzentrale.de/topkarten/fswrfmeur.html 2. Wait 2 seconds till the bar "Nightly prevented this site from opening a pop-up windows" appear. 3. Drag the mouse cursor over the links on the top of the page such as "Hohe Wolken" etc. Actual results: 4. The top of the page is then rendered badly. Expected results: The top of the page should be aligned properly as in Aurora of Firefox 8, Beta of Firefox 7 or Firefox 6.

Works for me: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.21) Gecko/20110830 Firefox/3.6.21 Mozilla/5.0 (X11; Linux x86_64; rv:6.0.1) Gecko/20100101 Firefox/6.0.1 Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20100101 Firefox/7.0 Mozilla/5.0 (X11; Linux x86_64; rv:8.0a2) Gecko/20110903 Firefox/8.0a2 Reproduced: Mozilla/5.0 (X11; Linux x86_64; rv:9.0a1) Gecko/20110904 Firefox/9.0a1 Last good nightly: 2011-09-03 First bad nightly: 2011-09-04 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2011-09-03&enddate=2011-09-04

Please ignore regression range in last part of comment 1. The correct one seems to be: Last good nightly: 2011-08-24 First bad nightly: 2011-08-25 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=198c7de0699d&tochange=e58e98a89827

Regression range using hourly builds: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b354d9b3e9e1&tochange=e58e98a89827

Looks like fallout from bug 653649 Kill nsIFrame::GetAdditionalChildListName

Local track down using Linux x86_64: Due to skipped revisions, the first bad revision could be any of: changeset: 75840:5c0d46747250 user: Mats Palmgren <matspal@gmail.com> date: Wed Aug 24 22:54:29 2011 +0200 summary: Bug 653649 - New way of getting child lists from frames. (part 1/5) r=roc sr=dbaron changeset: 75841:bbb68899df56 user: Mats Palmgren <matspal@gmail.com> date: Wed Aug 24 22:54:29 2011 +0200 summary: Bug 653649 - New way of getting child lists from frames. (part 2/5) r=roc sr=dbaron changeset: 75842:de17763f5ba7 user: Mats Palmgren <matspal@gmail.com> date: Wed Aug 24 22:54:29 2011 +0200 summary: Bug 653649 - New way of getting child lists from frames. (part 3/5) r=roc changeset: 75843:d9797d99f5f7 user: Mats Palmgren <matspal@gmail.com> date: Wed Aug 24 22:54:30 2011 +0200 summary: Bug 653649 - New way of getting child lists from frames. (part 4/5) r=roc

Thomas, thanks for tracking down the precise regression window.

The error is in InternalInvalidateThebesLayersInSubtree: http://mxr.mozilla.org/mozilla-central/source/layout/base/FrameLayerBuilder.cpp#1906 The original code was: PRInt32 listIndex = 0; nsIAtom* childList = nsnull; do { nsIFrame* child = aFrame->GetFirstChild(childList); if (!child && !childList) { nsSubDocumentFrame* subdocumentFrame = do_QueryFrame(aFrame); if (subdocumentFrame) { // Descend into the subdocument child = subdocumentFrame->GetSubdocumentRootFrame(); } } while (child) { if (InternalInvalidateThebesLayersInSubtree(child)) { foundContainerLayer = PR_TRUE; } child = child->GetNextSibling(); } childList = aFrame->GetAdditionalChildListName(listIndex++); } while (childList); In the SubDocumentFrame case, note that it recurses on its root frame, whereas the new code iterates the root frame's children and recurse on those. Patch coming up...

Synthesize a child list from the subdocument root frame and add it to the array of child lists to iterate. I'll try to find a way to test this without relying on the popup blocker, let me know if you have any tips on how to do that.

Comment on attachment 558287 [details] [diff] [review] fix Review of attachment 558287 [details] [diff] [review]: ----------------------------------------------------------------- Thank you!