Bug 95794 - [chromium] beforeunload handlers in iframes only fire if there is a top-level beforeunload handler
Summary: [chromium] beforeunload handlers in iframes only fire if there is a top-level...
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: UI Events (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-09-04 16:15 PDT by Ojan Vafai
Modified: 2013-04-15 08:40 PDT (History)
8 users (show)

See Also:

Attachments
test case without top-level handler (278 bytes, text/html)
2012-09-04 16:15 PDT, Ojan Vafai 		no flags Details
testcase with top-level handler (354 bytes, text/html)
2012-09-04 16:16 PDT, Ojan Vafai 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Ojan Vafai 2012-09-04 16:15:20 PDT 
Will add test-cases. Tested in Chrome 23.0.1246.0 (Official Build 153452) dev on Linux. Not sure if this happens in non-Chrome WebKits.
Comment 1 Ojan Vafai 2012-09-04 16:15:44 PDT 
Created attachment 162120 [details]
test case without top-level handler
Comment 2 Ojan Vafai 2012-09-04 16:16:54 PDT 
Created attachment 162122 [details]
testcase with top-level handler
Comment 3 Ojan Vafai 2012-09-04 16:17:35 PDT 
Actually, looks like we fire the unload handlers in both cases if you hit reload, but not if you close the tab.
Comment 4 Alexey Proskuryakov 2012-09-05 09:56:28 PDT 
Appears to work as expected in Safari 6.
Comment 5 Ojan Vafai 2012-09-05 10:00:29 PDT 
Seems likely that we're just not propagating the hasUnloadHandlers bit up to the browser process on the Chrome side. Will remove the chromium prefix on the bug summary if it turns out to be a generic webkit issue.
Comment 6 Ryosuke Niwa 2012-09-13 11:19:39 PDT 
(In reply to comment #5)
> Seems likely that we're just not propagating the hasUnloadHandlers bit up to the browser process on the Chrome side. Will remove the chromium prefix on the bug summary if it turns out to be a generic webkit issue.

Sounds like this is an issue in Chromium codebase?