This would let us simplify things in //content as well, so I think it's desirable. That being said... SubFrameBeforeUnloadFired is apparently fired on 2% of page loads (https://www.chromestatus.com/metrics/feature/timeline/popularity/98), which is pretty high!

Does that track beforeunload in general, or attempts to cancel beforeunload? We'd presumably still fire the event, just not allow it to pop up the dialog.

My impression from bugs like https://bugs.chromium.org/p/chromium/issues/detail?id=120933 is that a lot of people use onbeforeunload for analytics stuff, which (hopefully) doesn't attempt to cancel the unload.

Ah, you're right: the current UMA doesn't actually track how many of those actually block navigation. I'll add a metric for that then.

Note that we behave differently for `e.preventDefault()` and for `return "a string". Separate bug, I guess. So let's test "return a string" only: https://ns-wauccuusnb.now.sh for same-origin iframe; https://ns-zjaxputfgt.now.sh for cross-origin.

I tested Edge, Safari Tech Preview, Chrome, and Firefox. It appears everyone but Firefox pops up the dialog for same-origin, and nobody pops up the dialog for cross-origin.

For Firefox, the behavior depends on whether the user has meaningfully interacted with the document.  This is not limited to iframes.  The point of beforeunload is to prompt to save data or whatnot.  No interaction means nothing to worry about saving.

(Retitling this bug to reflect the updated understanding of sad reality)

Question: is this

1) Do not fire the `beforeunload` event on pages with no user interaction or
2) Fire the `beforeunload` event on all page but ignore dialog requests from pages with no user interaction

? This is what Domenic in comment 3, but no one seemed to answer.

I believe that Firefox is 2. I was going to propose 2 for Chromium. I suspect that 1 would be rather web-breaking and visible. If 2, then we should change the bug summary.

IMO doing #2 and (roughly) matching Firefox is the no-brainer change that gets the primary user value and what we should focus on in the short-term.

I'd eventually like to kill beforeunload altogether, but that's a much move involved idea with a very long deprecation timeline, etc.

Is everyone in agreement that we want to do 2? I'm a few days away from sending an intent to do it.

If we're good with 2, I can make this the bug.

If we're not, I'll pursue 2 anyway but in a different bug and we can have this be the bug for 1.

I'm just going to call this a dup.