Bug 94064 – Event listeners are no longer functioning inside iframe when loading from Page Cache

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: Frames

[Rob B]

Our HTML content is inside an iframe. We've deduced that ever since iOS 4, when our page is loaded again via Page Cache, the event listeners are no longer attached to anything inside the iframe. Any event listeners on the main page-level are still there. We used to work around this by attaching an empty window unload handler per http://www.webkit.org/blog/516/webkit-page-cache-ii-the-unload-event/. But, it appears in iOS 5's Webkit, this no longer works as a workaround. I'm assuming because of bug 29021?

The best possible bugfix would be to have everything inside the iframe fully functional when returning from Page Cache so that's what this bug report is about. But, in the meantime if anyone has an idea on how to disable Page Cache I would appreciate it. Please let me know if I can provide any further information.

Steps:
1) Load the URL specified above in iOS 5.
2) Click green box to go to Yahoo.com
3) Click back button
4) Try to click the green box again

Actual results:
Nothing happens

Expected results:
Navigates browser to yahoo.com again.

User Agent: 
Mozilla/5.0 (iPhone; CPU iPhone OS 5_1_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Version/5.1 Mobile/9B206 Safari/7534.48.3 (I'm unsure of how to figure out the version from this.)

[Alexey Proskuryakov]

I cannot reproduce in Safari 6 on Mac, so it's unclear whether this is actually an open source WebKit issue.

[Rob B]

I cannot repro on any Desktop Safari, Chrome, nor on Android devices' implementation of WebKit so it is likely an issue specific to iOS. Whether it's a bug in iOS or a bug in Webkit that iOS aggravated is another question. But, since there was a very similar sounding fix put in 34679 I wanted a way to figure out how to verify if that did fix it in iOS.

[Brady Eidson]

(In reply to comment #2)
> I cannot repro on any Desktop Safari, Chrome, nor on Android devices' implementation of WebKit so it is likely an issue specific to iOS. Whether it's a bug in iOS or a bug in Webkit that iOS aggravated is another question. But, since there was a very similar sounding fix put in 34679 I wanted a way to figure out how to verify if that did fix it in iOS.

As mentioned in your other bug - https://bugs.webkit.org/show_bug.cgi?id=34679 - iOS is a product of Apple and the WebKit open source project has nothing to do with Apple product releases.

By looking at publicly available information, I can say that:
-The example you attached to 34679 was noticed on iOS5
-iOS5 was released in 2011
-The fix for 34679 was made in March 2012

Please draw your own conclusions from this.

34679 is verified as fixed within the confines of the WebKit Open Source project, so this bug is just a dupe.

*** This bug has been marked as a duplicate of bug 34679 ***

[Rob B]

Cool, thank you. 

Just FYI I did not open this bug knowingly to try to spam anyone, I searched for the other bug I commented in in February and just assumed I was confused and there never was an open bug for this. Also, my response above was a reply to Alexey on environments that I had repro'd and those I had not to ensure that info was clearly stated, not trying to intentionally dupe anything.