Closed Bug 1018265 Opened 5 years ago Closed 5 years ago

iFrame containing Javascript Alert dialog fails after leaving and returning to page

Categories

(Core :: Document Navigation, defect)

29 Branch
x86_64
Linux
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla33

People

(Reporter: dvs, Assigned: smaug)

Details

Attachments

(2 files, 3 obsolete files)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130216 Firefox/17.0 (Nightly/Aurora)
Build ID: 20130218031018

Steps to reproduce:

Create element within iframe which uses javascript onclick to call alert(). Go forward a page (either through a link or by typing in a new URL), then hit back button.

Example outer frame ("outer.htm"):
<!DOCTYPE html>
<html>
<iframe src="frame1.htm"></iframe> <frame src=frame1.htm>
</html>

Example inner frame ("frame1.htm"):

<!DOCTYPE html>
<html lang="en"><body>
<a href="" onclick="alert('alert')">Show alert</a>
<a href="otherpage" target="_top">Next page</a>
</body></html>

To reproduce with above example:

* load outer.htm
* click on "Show alert" to verify alert works.
* click on "Next page" 
* hit back button
* click on "Show alert". Alert fails.



Actual results:

No alert dialog appears. 


Expected results:

An alert dialog appears.
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?
Flags: needinfo?(bugs)
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
Flags: needinfo?(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.
Attached file inner.html (obsolete) —
Attached file test (obsolete) —
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
Attached patch patch (obsolete) — Splinter Review
(still figuring out the tests)
Attached patch +testsSplinter Review
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
Attachment #8451170 - Attachment is obsolete: true
Attachment #8451174 - Flags: review?(bzbarsky)
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+
https://hg.mozilla.org/mozilla-central/rev/62f11352d198
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.