New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 851882 link

Starred by 12 users

Issue metadata

Status: Assigned
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Chrome , Mac
Pri: 1
Type: Bug

Blocked on:
issue 609963
issue 852204
issue 857274

Sign in to add a comment

unload event is not working when 'site-isolation' option is default.

Reported by, Jun 12 2018

Issue description

Chrome Version       : 67.0.3396.79
URLs (if applicable) :
Other browsers tested: 'site-isolation' option is only for chrome. so, i cannot test it in other browsers.
  Add OK or FAIL, along with the version, after other browsers where you
have tested this issue:

What steps will reproduce the problem?
(1) open the attached file in chrome(67 version)
(2) click 'Go cross-site' button
(3) click 'Go main page' button
(4) check 'unload event:' string under the buttons. 

What is the expected result?
The unload event has to be working.
(unload event : true)

What happens instead?
If you follow the steps, the unload event doesn't work. but, beforeunload event occurs.
(unload event : false, beforeunload event : true )
But, if 'site-isolation' option is turned off, the unload event occurs properly.

Please provide any additional information below. Attach a screenshot if

1.4 KB View Download

Comment 1 by, Jun 12 2018

Labels: -Pri-3 FoundIn-67 M-67 M-68 M-69 OS-Chrome OS-Linux OS-Mac OS-Windows Pri-1
Status: Assigned (was: Unconfirmed)
Thanks for the report!  We're looking into some potential fixes for unload on cross-process navigations (especially in subframes).  Alex knows the details.

Comment 2 by, Jun 15 2018

Blockedon: 852204 609963
To follow up, a partial fix landed in r567395 for  issue 852204 .  That should handle cases like beacons and image tags added in unload handlers, but not postMessages to other frames.  We'll track verification and merge for that CL in  issue 852204 , which you can star to follow along.

Nasko has started some CLs that should help the postMessage case as part of issue 609963, though there's some tricky parts to work through:

The issue about unload event on cross-process navigations was fixed?
This bug report is not related to postMessage. I just used it for example. 

Please check it
Thank you.

Comment 4 by, Jun 21 2018

Correct-- unload handlers in out-of-process iframes are now given a chance to run, as of r567395, which is in Chrome 69.0.3461.0 and later (currently on Canary and Dev channels).  The fix is also in the most recent Beta channel build (68.0.3440.33), which came out yesterday.

As long as you don't need postMessage support in the unload handler, this should be resolved.  Can you verify that it's working for you in one of the versions above?
It is still not working on v69.0.3472.0 (canary, 64bit, Windows 10)
I set "chrome://flags/#site-isolation-trial-opt-out" to Default and run Chrome as Secret Mode.

Can anybody test on another environments?

Thank you.
RE: #c5 / idiot86.creatiques@

Could you please provide repro steps that might help us understand what is not working on 69.0.3472.0?
- Does the unload event handler execute?  Do beacons and/or image tags not work (as a way to ping a http server)?  Are some other things broken?  
- Is there a URL that we can use to replicate your testing?
#5: Yes, repro steps or URL would be extremely useful.  Is you unload test fixed when you set chrome://flags/#site-isolation-trial-opt-out to "Opt-out"? I'll also add that (1) certain operations in unload, such as postMessage to other cross-origin frames, are still not yet supported (this will be fixed by issue 609963), and (2) beforeunload still may not run from cross-site iframes (tracked in  issue 853021 ).
I'm sorry I missed details.

I tested with the test code attached to the original article. (iframe_unload_test.html)
If I do all steps with latest Chrome Canary on my Windows 10 PC, only 'beforeunload' is turned to 'true'.
I tried to test on many environments and sometimes it shows 'true'.
I think half is succeed and half is failed. 

So I tried to test on a clean environment.
I uninstalled Chrome and removed all data about Chrome on the 'AppData' folder.
Finally, I succeed to see all things gone 'true'
I try this on the other failed environment and succeed to see 'true'

In conclusion, I think this issue is fixed.
Please let me know if you need more information about my test.

Thank you.

Comment 9 by, Jun 26 2018

I had uploaded the 'iframe_unload_test.html ' file to the JSFiddle.

I'm using mac.
After installing the chrome canary, it runs successfully the first time but fails the second time. (After running the chrome for the first time, I killed it and ran it again.)
#8 and #9: thanks for providing these testing details - very helpful!  I think everything you said is consistent with the current state of unload behavior:

1. The repro in iframe_unload_test.html requires a postMessage to the cross-site parent frame to be sent from unload.  That message won't be delivered until we fix issue 609963, which we're working on.  The unload event in the frame should fire though, after the fix in r567395.  One way to observe that is to make an outgoing request from it (e.g., with navigator.sendBeacon('http://some.domain/foo', 'bar')) and observe that it shows up in chrome://net-internals.  

2. Beforeunload runs correctly in this case because the subframe itself is navigated, and not the main frame.  This navigation setup is not affected by  issue 853021 .  If the main frame were navigated instead, we'd lose the beforeunload event in the subframe, and that's a bug that we're fixing in  issue 853021 .

3. When you install Chrome and run it for the first time (or when you run it with a new profile), it doesn't pick up field trial configs until first restart.  We currently enable strict site isolation via field trials, so your first Canary run was likely without site isolation, and the second one was with site isolation.  That explains why postMessage in unload worked the first time but not the second.
Thank you for your detailed description.
But, I think the unload event don't fire.
I tested it with the Chrome runtime debugger and attached the video.
2.4 MB View Download
#11: Thanks.  Unfortunately, you can't reliably use breakpoints inside unload with cross-process navigations.  At the time the breakpoint is supposed to hit, we've already switched to the new page and updated DevTools accordingly, and the old page's process is running the unload handler in the background.  I think unload breakpoints won't work for any cross-proecss navigation, which can also happen for main frames without site isolation, so it's not a new limitation. For example, I've checked that when you're on and type into the omnibox, breakpoints inside unload in won't get hit even with site isolation disabled.  We might consider supporting this in the future, but I'd imagine this is going to be very difficult to pull off.

So, I think the handler does run in your example, you just can't use the debugger to confirm.  You can confirm by having unload do another observable operation, like a network request per #10.  In this repro setup, you can also just use console.log("unload") inside the frame's unload, and you should see that output after clicking.  (In some cases, console.log() also won't work from unload(), like if the main frame navigates, and the old document's iframe has an unload handler that executes console.log().  That will be fixed in issue 609963.)

I looked a bit more into why postMessage doesn't work in this particular repro.  This is actually not a case of destroying the browser-side routable object before asking the subframe to run its unload handler, as in this case the frame itself navigates remote-to-local, the frame's old RenderFrameHost stays alive in pending delete state, and the parent frame's proxy in the subframe's process is alive as well at the time the unload handler is triggered from FrameMsg_SwapOut.  (The proxy is actually what the parent.postMessage would be sent through.)  However, due to the fix r550769 for issue 828529, remote postMessage is now scheduled, so its IPC is delayed and sent right after RenderFrameImpl::OnSwapOut finishes running and sends back the FrameHostMsg_SwapOut_ACK.  The browser process receives the SwapOut ACK first and promptly destroys the pending-delete RFH and all the remaining proxies, as this was the last active frame in the process.  Then, the incoming postMessage IPC is dropped because the RenderFrameProxyHost to which it was addressed was just deleted.  I think this is  worth tracking in a new bug, so I'll file one.

Blockedon: 857274
Filed  issue 857274  to follow up on the postMessage part of #12.
I have created a new sample that don't fire the unload event.

link :

Please check it.
I also attached test video.
6.6 MB View Download
#15: Thanks for another test case!  It looks like the network panel in DevTools is also not showing requests made from pending delete RenderFrameHosts when they execute unload in background.  The requests do show up in chrome://net-internals though.  I repeated your test with chrome://net-internals open in another tab and got this log:


when I navigated the iframe back and forth a couple of times.  So it appears that the foo.txt does get requested - can you verify this on your end as well?

I also noticed the console.log() actually doesn't seem to show up from unload when routed through pending delete RFH. I thought this should work - I'd need to investigate more about why it doesn't.

dgozman@/pfeldman@: is this behavior expected?  TLDR is that once we've switch the current RFH for a frame, it's hard to inspect side effects from the old RFH that runs an unload handler in background - network requests don't show up, console.log() doesn't work, breakpoints don't work, and probably more.  Anything we could do to improve this situation? (I suspect this might be hard.)
 > TLDR is that once we've switch the current RFH for a frame, it's hard to inspect side effects from the old RFH that runs an unload handler in background - network requests don't show up, console.log() doesn't work, breakpoints don't work, and probably more. 

That's right. Once we switch to a new host, we do not talk to the old one anymore. Since we abstract away the multiple processes magic from developers, we have a moment of time when page logically transitions to the new host. This moment is optimized towards the new host to improve debugging of the on-load issues, rather than on-unload issues (which are less common).

> Anything we could do to improve this situation? (I suspect this might be hard.)
Yeah, our infrastructure is not ready for talking to multiple hosts. There could also be UI issues, e.g. links from console.log to nodes of the old document, while the DOM tree already shows the new document.
#16: Thanks for your confirmation and comment.

Sign in to add a comment