Closed Bug 1018265 Opened 11 years ago Closed 11 years ago

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

Categories

(Core :: DOM: Navigation, defect)

Product:
Core
Component:
DOM: Navigation
Version:
29 Branch
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla33

People

(Reporter: dvs, Assigned: smaug)

Details

Attachments

(2 files, 3 obsolete files)

+tests
7.15 KB, patch
bzbarsky
: review+
Details | Diff | Splinter Review
+comment
7.30 KB, patch
Details | Diff | Splinter Review
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 +tests — — Splinter 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: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla33
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: