Closed Bug 1018265 Opened 5 years ago Closed 5 years ago
This is really weird. After the back we seem to have dialogs disabled on the current inner of the top window nsGlobalWindow::AreDialogsEnabled finds... Are we ending up with things hooked up to the wrong inners somehow in the bfcache case?
Note: apologies for the stray text - the Example Outer Frame "outer.htm" example should be: <!DOCTYPE html> <html> <iframe src="frame1.htm"></iframe> </html>
Something bizarre going here. We load a new inner window?
Assignee: nobody → bugs
I don't _think_ we create new inners during the back navigation....
You don't need the any back-forward here to see the odd behavior. Let me upload a testcase.
Oh, silly me. That is coming from the <a>. We do load to a new page...
Attachment #8451013 - Attachment is obsolete: true
Attachment #8451016 - Attachment is obsolete: true
Ok, so we never unhide contentviewers coming from bfcache. Patch and test coming.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
(still figuring out the tests)
The test is a bit silly, but mimics the testcase in this bug without actual alert, but focuses on the actual bug about ContentViewer.isHidden https://tbpl.mozilla.org/?tree=Try&rev=5aa732556a1a
And yes, the whole setup of restoring from bfcache is rather horrible in ContentViewer/Docshell. I'm sure mconley wants to clean it up ;)
Comment on attachment 8451174 [details] [diff] [review] +tests r=me if you add a nice IDL comment about who is or is not allowed to set that attribute and what setting it means.
Attachment #8451174 - Flags: review?(bzbarsky) → review+
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla33
You need to log in before you can comment on or make changes to this bug.