Closed Bug 611798 Opened 9 years ago Closed 9 years ago
Loading a simple web page stops rendering in the entire browser window
STR: Load the test case in Firefox. WARNING: it will basically make your browser window unusable until you restart Firefox. What happens is that first I see the tab bar being drawn in the window background color, and then if I switch windows, the entire window turns grey and no rendering happens any more. The only work around seems to be restarting the browser. Keyboard shortcuts seem to continue to work, so I can for example Cmd+L, type mozilla.com and press Enter, but nothing shows up on the screen.
This needs to block, I think. A web page should not be able to stop the rendering in the entire window.
blocking2.0: --- → ?
Gonna take a stab at this and say Rob is able to fix this. Reassign if necessary!
Assignee: nobody → roc
blocking2.0: ? → final+
Generally this type of thing happens if we hit a cairo error. Setting a breakpoint on _cairo_error should show whether that's the case...
###!!! ASSERTION: Dying in the middle of our own update?: 'mUpdateCount == 0', file layout/base/nsCSSFrameConstructor.h, line 89 ###!!! ASSERTION: Someone forgot to call EndUpdateViewBatch!: '!mRootVM', file nsIViewManager.h, line 297
(In reply to comment #4) > Created attachment 491755 [details] > assertion stacks This makes it seem more like a layout problem.
Component: Graphics → Layout
QA Contact: thebes → layout
Ehsan, this looks a lot like other bugs you fixed. Is this already fixed? If not, can you take it? :-)
(In reply to comment #6) > Ehsan, this looks a lot like other bugs you fixed. Is this already fixed? If > not, can you take it? :-) Sure. It's not already fixed, but I'll take a look.
Assignee: roc → ehsan
About the test changes, the change to 432114-2.html makes sure that we actually wait until the test is finished. The inner iframe uses a timeout, so we can't just rely on chance for the test to be finished before the reftest framework loads the next test. The crashtest.list change is necessary to remove the assertion from bug 571020 (which was really a side-effect of this problem), and also mark the assertion as deterministic. I suspect the assertion annotation was set to 0-2 because sometimes we weren't waiting long enough for the test to finish, therefore we did not get any assertions.
Comment on attachment 496926 [details] [diff] [review] Patch (v1) r=me
Attachment #496926 - Flags: review?(bzbarsky) → review+
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Whiteboard: [needs landing]
Target Milestone: --- → mozilla2.0b8
Comment on attachment 496926 [details] [diff] [review] Patch (v1) >diff --git a/docshell/base/crashtests/crashtests.list b/docshell/base/crashtests/crashtests.list >--- a/docshell/base/crashtests/crashtests.list >+++ b/docshell/base/crashtests/crashtests.list >@@ -1,11 +1,11 @@ > load 40929-1.html > load 369126-1.html > load 403574-1.xhtml > load 430124-1.html > load 430628-1.html > asserts(1-4) load 432114-1.html # bug 570215 >-asserts(0-2) load 432114-2.html # bug 570215, bug 571020 >+asserts(1) load 432114-2.html # bug 570210 bug 570210 isn't bug 570215. Could you please fix?
(In reply to comment #13) > Comment on attachment 496926 [details] [diff] [review] > Patch (v1) > > >diff --git a/docshell/base/crashtests/crashtests.list b/docshell/base/crashtests/crashtests.list > >--- a/docshell/base/crashtests/crashtests.list > >+++ b/docshell/base/crashtests/crashtests.list > >@@ -1,11 +1,11 @@ > > load 40929-1.html > > load 369126-1.html > > load 403574-1.xhtml > > load 430124-1.html > > load 430628-1.html > > asserts(1-4) load 432114-1.html # bug 570215 > >-asserts(0-2) load 432114-2.html # bug 570215, bug 571020 > >+asserts(1) load 432114-2.html # bug 570210 > bug 570210 isn't bug 570215. Could you please fix? Thanks a lot for noticing this! Pushed a fix: http://hg.mozilla.org/mozilla-central/rev/5d9e1a56d922
You need to log in before you can comment on or make changes to this bug.