Closed Bug 779430 Opened 11 years ago Closed 8 years ago

"Bad readystate" assertion in DocumentViewerImpl::LoadComplete


(Core :: DOM: Navigation, defect)

Not set



Tracking Status
firefox46 --- fixed


(Reporter: jruderman, Assigned: smaug)



(Keywords: assertion, regression, testcase)


(7 files)

Attached file testcase
Assertion failure: mDocument->IsXUL() || mDocument->GetReadyStateEnum() == nsIDocument::READYSTATE_INTERACTIVE || (mDocument->GetReadyStateEnum() == nsIDocument::READYSTATE_UNINITIALIZED && NS_IsAboutBlank(mDocument->GetDocumentURI())) (Bad readystate), at layout/base/nsDocumentViewer.cpp:1017

This instance of this assertion was added in:

changeset:   fa6a84e7ba53
user:        Henri Sivonen
date:        Fri Jul 27 16:35:09 2012 +0300
summary:     Bug 775467 - Make readyState progress through all states without duplicate transitions. r=bzbarsky.
Attached file stack trace
Does = "egg"; involve XBL somehow?
Note that bug 779100 is a case of bogosity known at the time of landing bug 775467. It appears that our "load" event firing logic is a very broken in interesting edge cases (such as this case here and the case in that networking bug). :-(
There shouldn't be any XBL involved there, no.

And I'm not sure why the new tab part is relevant...
I see this on

for Aurora, Nightly and Windows, Linux, Mac. You may need to load them multiple times to see it.
OS: Mac OS X → All
Hardware: x86_64 → All
Happened twice in the last day to me.  I was scrolling through a Google Groups page I think; I honestly don't remember what I was exactly doing other than trying to scroll as the page loaded.


IsXUL() is inlined, but: 
(gdb) p ((nsIDocument*) mDocument.mRawPtr)->mIsXUL
$5 = false

I believe I was trying to mousewheel scroll on a document I had just opened, but I'm not 100% sure

I'll attach a GDB log with dumps of the backtrace, document, docshell, etc.
Yup, crashed again when leaving that page via "Back" to a bugzilla bug
No longer blocks: sync-about-blank
Still happens on trunk:

###!!! ASSERTION: Bad readystate: 'mDocument->IsXUL() || mDocument->GetReadyStateEnum() == nsIDocument::READYSTATE_INTERACTIVE || (mDocument->GetReadyStateEnum() == nsIDocument::READYSTATE_UNINITIALIZED && NS_IsAboutBlank(mDocument->GetDocumentURI()))', file ../../../layout/base/nsDocumentViewer.cpp, line 1029

It was made non-fatal in bug 807442.
Attached file new assertion stack
still reproduced on win 7 debug build based on m-c tip from today
smaug: is this something for you ?
Flags: needinfo?(bugs)
So nsDocShell::GetRestoringDocument is lying us here. We actually do restore the testcase document as expected, but for some reason DocShell says we're not doing that.
And the issue happens only first time the button is clicked.

Assignee: nobody → bugs
Flags: needinfo?(bugs)
Attached patch patchSplinter Review
bfcache handling in docshell really doesn't expect layout flushes (which may add onload blockers, like in this case XBL does that) when this code is called at the end of restoration. Adding async onload blockers make bfcache restoration
behave as if normal page was loaded, which means we try to set the readyState again.

I tried to write mochitest for this, but something in the framework affects to the timing so that the assertion
isn't triggered without the patch.
Attachment #8708544 - Flags: review?(bzbarsky)
Comment on attachment 8708544 [details] [diff] [review]

Attachment #8708544 - Flags: review?(bzbarsky) → review+
One can probably still find ways to trigger the assertion, but please file new bugs for new cases.
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla46
You need to log in before you can comment on or make changes to this bug.