Intent to Remove: Cross origin subframe JS Dialogs

345 views
Skip to first unread message

Carlos IL

unread,
Mar 24, 2020, 7:40:01 PM3/24/20
to blink-dev, Eric Mill, Mustafa Emre Acer, Emily Stark

Primary eng (and PM) emails

Eng: carl...@chromium.org, mea...@chromium.org

PM: eric...@google.com 


Summary

This is a proposal to disallow window.{alert, confirm, prompt} from a cross-origin iframe. Currently, Chrome allows iframes to trigger Javascript dialogs. Chrome shows “<URL> says ...” when the iframe is the same origin as the top frame, and “An embedded page on this page says...” when the iframe is cross-origin. The current user experience is confusing, and has previously led to spoofs where sites pretend the message comes from Chrome or a different website. Removing support for cross origin iframes’ ability to trigger the UI will not only prevent this kind of spoofing, but will also unblock further efforts to make the dialog more recognizable as part of the website rather than the browser.


Motivation

The current UI for JS dialogs (in general, not just for the cross-origin subframe case) is confusing, because the message looks like the browser’s own UI. This has led to spoofs (particularly with window.prompt) where sites pretend that a particular message is coming from Chrome (e.g. 1,2,3). Chrome mitigates these spoofs by prefacing the message with “<hostname> says...”. However, when these alerts are coming from a cross-origin iframe, the UI is even more confusing because Chrome tries to explain the dialog is not coming from the browser itself or the top level page. Given the low usage of cross-origin iframe JS dialogs, the fact that when JS dialogs are used they are generally not required for the site’s primary functionality, and the difficulty in explaining reliably where the dialog is coming from, we propose removing JS dialogs for cross-origin iframes. This will also unblock our ability to further simplify the dialog by removing the hostname indication and making the dialog more obviously a part of the page (and not the browser) by moving it to the center of the content area. These changes are blocked on removing cross-origin support for JS dialogs, since otherwise these subframes could pretend their dialog is coming from the parent page.


Interoperability and Compatibility Risk

We haven’t engaged with other browser vendors regarding this change yet, but plan to submit a spec change proposal once the change is approved for Chrome. Since PRs to the HTML spec require one more vendor to support (and none to oppose), we’ll reach out to other vendors before sending the PR.

The current spec allows for early return in all 3 algorithms that trigger JS dialogs (see step 3 in 1, 2, 3), so if Chrome early returns in the cross origin iframe case it will not be violating the current spec. That being said, if other browsers are on board with the change we’d prefer changing the spec so it requires early return in this case.


Current behavior in other browsers: 

Edge: Same behavior as Chromium.

Firefox: Always shows the dialog in the content area, with no URL if the message is from the main frame site or a same-origin iframe; shows “The page at <iframe URL> says:...” when the message is from a cross-origin iframe.

Safari: Always shows the dialog in the content area, with no URL in any case.


Alternative implementation suggestion for web developers

An alternative is for the dialog to be triggered by the mainframe website. Another option is for the subframe to create its own UI showing the message instead of using window.{alert, confirm, prompt}. If common enough, libraries could provide a polyfill that implements alert/confirm/prompt as web content if called from a cross origin iframe.


Usage information from UseCounter


Feature

% of Page Loads with usage (from cross-origin iframes)

window.Alert

0.006

window.Confirm

0.003

window.Prompt

0.00006

Total

0.00906


In total, around 0.009% of page loads would be affected by the removal. We believe that core functionality will not be severely degraded, since the ability for users to disable JS prompts means sites already can’t rely on JS dialogs to always be displayed. 

Additionally, we will provide an enterprise policy to allow cross-origin iframe JS dialogs to mitigate the compatibility risk for enterprise usecases.


Entry on the feature dashboard

We are not adding a feature entry to the dashboard. Since this is a modification of a feature, JS dialogs will remain, but a special case of them will be removed.


Iwan Riza

unread,
Mar 24, 2020, 7:52:44 PM3/24/20
to Carlos IL, blink-dev, Eric Mill, Mustafa Emre Acer, Emily Stark
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAABgKfUT5nARoK%3DBq2064qWd7kAEO%2BFO4UgSLJoA8c-m%3DcfYEQ%40mail.gmail.com.

Domenic Denicola

unread,
Mar 24, 2020, 8:03:29 PM3/24/20
to Carlos IL, blink-dev, Eric Mill, Mustafa Emre Acer, Emily Stark
This is a very exciting change, and I do hope it works out!

One general question: the two other blocking dialogs on the platform are the one triggered by the beforeunload event and window.print(). I believe we already ignore beforeunload for subframes, but do you know about plans for print()?

From: Carlos IL <carl...@chromium.org>

> We haven’t engaged with other browser vendors regarding this change yet, but plan to submit a spec change proposal once the change is approved for Chrome. Since PRs to the HTML spec require one more vendor to support (and none to oppose), we’ll reach out to other vendors before sending the PR.

Although the spirit is right, this isn't quite the correct approach procedurally. It's best to submit a specification pull request before any Intents are approved, to better help promote cross-vendor discussion, and allow the API owners to assess interop risk by looking at the spec (and accompanying web platform tests). The specification pull request doesn't have to be approved, but it should exist, so that there is a public record of what we are implementing at the level of detail of a full specification.

> The current spec allows for early return in all 3 algorithms that trigger JS dialogs (see step 3 in https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#dom-alert, https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#dom-confirm, https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#dom-prompt), so if Chrome early returns in the cross origin iframe case it will not be violating the current spec. That being said, if other browsers are on board with the change we’d prefer changing the spec so it requires early return in this case.

+1 to both the observation that this doesn't technically require any spec change, and to the intention to submit one anyway. It's always better to narrow the case of implementation-defined behavior if we can.

> An alternative is for the dialog to be triggered by the mainframe website. Another option is for the subframe to create its own UI showing the message instead of using window.{alert, confirm, prompt}. If common enough, libraries could provide a polyfill that implements alert/confirm/prompt as web content if called from a cross origin iframe.

In general using these dialogs at all is bad practice, and causes subpar user experience and performance because of how they block the main thread. So ideally web developers should switch to using a different UI, instead of alert/confirm/prompt on the parent frame.

One day (far in the future), maybe we can remove alert/confirm/prompt/beforeunload entirely. Incremental steps like this one are exciting.

> We are not adding a feature entry to the dashboard. Since this is a modification of a feature, JS dialogs will remain, but a special case of them will be removed.

It would be good to add a feature entry anyway, so that web developers (and others who monitor the feature dashboard, such as Chromium release blog post writers) are aware of the change.

Yoav Weiss

unread,
Mar 25, 2020, 6:06:41 AM3/25/20
to Domenic Denicola, Carlos IL, blink-dev, Eric Mill, Mustafa Emre Acer, Emily Stark
On Wed, Mar 25, 2020 at 1:03 AM Domenic Denicola <d...@domenic.me> wrote:
This is a very exciting change, and I do hope it works out!

One general question: the two other blocking dialogs on the platform are the one triggered by the beforeunload event and window.print(). I believe we already ignore beforeunload for subframes, but do you know about plans for print()?

From: Carlos IL <carl...@chromium.org>

> We haven’t engaged with other browser vendors regarding this change yet, but plan to submit a spec change proposal once the change is approved for Chrome. Since PRs to the HTML spec require one more vendor to support (and none to oppose), we’ll reach out to other vendors before sending the PR.

Although the spirit is right, this isn't quite the correct approach procedurally. It's best to submit a specification pull request before any Intents are approved, to better help promote cross-vendor discussion, and allow the API owners to assess interop risk by looking at the spec (and accompanying web platform tests). The specification pull request doesn't have to be approved, but it should exist, so that there is a public record of what we are implementing at the level of detail of a full specification.

I'd like to second that. A part of the reason we have our launch process is to evaluate interop risk, which requires engaging with other vendors to see if they'd follow our path.
A spec PR would enable them (as well as the API owners) to evaluate what this change actually means and allow them to express their opinions on it.
FWIW, I'd be surprised if they weren't supportive of this, assuming we prove that this change is web compatible.


> The current spec allows for early return in all 3 algorithms that trigger JS dialogs (see step 3 in https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#dom-alert, https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#dom-confirm, https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#dom-prompt), so if Chrome early returns in the cross origin iframe case it will not be violating the current spec. That being said, if other browsers are on board with the change we’d prefer changing the spec so it requires early return in this case.

+1 to both the observation that this doesn't technically require any spec change, and to the intention to submit one anyway. It's always better to narrow the case of implementation-defined behavior if we can.

> An alternative is for the dialog to be triggered by the mainframe website. Another option is for the subframe to create its own UI showing the message instead of using window.{alert, confirm, prompt}. If common enough, libraries could provide a polyfill that implements alert/confirm/prompt as web content if called from a cross origin iframe.

In general using these dialogs at all is bad practice, and causes subpar user experience and performance because of how they block the main thread. So ideally web developers should switch to using a different UI, instead of alert/confirm/prompt on the parent frame.

One day (far in the future), maybe we can remove alert/confirm/prompt/beforeunload entirely. Incremental steps like this one are exciting.

> We are not adding a feature entry to the dashboard. Since this is a modification of a feature, JS dialogs will remain, but a special case of them will be removed.

It would be good to add a feature entry anyway, so that web developers (and others who monitor the feature dashboard, such as Chromium release blog post writers) are aware of the change.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Guokai Han

unread,
Mar 25, 2020, 1:36:12 PM3/25/20
to blink-dev, eric...@google.com, mea...@chromium.org, est...@chromium.org
This proposal only remove them in cross origin subframe. No plan to remove them in other conditions(e.g. main frame), right?

window.{alert, confirm, prompt} have very unique features, which UI can't be affect by page style, that is useful. Other JS dialog alternatives, HTML <dialog> element is only available on Chromium; JS modal is not built-in, not easy to implement and can be affect by page style. So I hope browser vendors can improve window.{alert, confirm, prompt} or supply new built-in alternatives.

Mike West

unread,
Mar 26, 2020, 12:01:20 PM3/26/20
to Carlos IL, blink-dev, Eric Mill, Mustafa Emre Acer, Emily Stark
I went through the ~100 sites tagged as using cross-origin `alert()` by HTTP Archive on https://www.chromestatus.com/metrics/feature/timeline/popularity/1411. Most sites didn't actually pop up an alert. The ones that did were mostly error messages that users couldn't do anything about (e.g. https://onlinelearning.lendlease.com/http://www.rip-a-lip.sakura.ne.jp/, and http://warrant.jihsun.com.tw/). I went through half of `confirm()` (https://www.chromestatus.com/metrics/feature/timeline/popularity/1412), but couldn't get any of them to pop up a dialog. 

I would be comfortable shipping this change, based on these anecdotes, the overall low usage, and the confusing nature of our existing UX. If you can do the legwork of shepherding a patch against HTML on the one hand, and getting feedback from other vendors on the other, I'd happily approve the change.

With regard to Domenic's question around `print()`, I'd suggest doing more research there before deciding to disable it cross-origin. I recall running into some issues when we deprecated modal dialogs inside `<iframe sandbox>` around pages that were building print-appropriate views in sandboxed pages to reduce the risk, and who may have moved to cross-origin pages. `print()` also seems less directly abusable than the mechanisms you're targeting here; it may not be worth breaking.

With all that said, the current situation in the world at large makes me think that we should hold off on actually _shipping_ this deprecation until after we have a bit more confidence in developers' ability to absorb change. I'd recommend implementing it behind an off-by-default flag that we can find the right time to enable.

-mike


--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Avi Drissman

unread,
Mar 26, 2020, 12:16:49 PM3/26/20
to Mike West, Carlos IL, blink-dev, Eric Mill, Mustafa Emre Acer, Emily Stark
As someone who has shipped a few things like this, my comments on Mike West's comment:

- Yep, definitely do this behind a flag
- Yep, this probably isn't something that we want to ship immediately given the situation in the world
- Mixed feelings about "enabling a flag"; this might be something we want to align to an mstone for clarity and possible comms
- This smells to me of possible enterprise concern; you might need to hook this up to a policy

I'm super supportive of this change (personal LGTM) but, like any change in this area, we have to be very careful in the rollout to make it stick. Definitely talk to the enterprise folks to make sure any concerns they have are assuaged.

Avi

Carlos IL

unread,
Mar 26, 2020, 3:39:43 PM3/26/20
to Avi Drissman, Mike West, blink-dev, Eric Mill, Mustafa Emre Acer, Emily Stark
Thanks all for the comments,

Spec Change: That sounds good, I'll go ahead and write a PR and start gathering feedback, I'll send a link to the PR once that's ready.

Other dialogs: Yes, I believe onbeforeunload is already blocked for this case. As for print() I did take a look into it, but since the dialog triggers the usual print dialog it seems much harder to abuse, and the UI is actually coming from the browser in that case. I wouldn't oppose also removing it, but given this (and the concern Mike pointed out about valid uses), I'd prefer to do that separately from this change, which in my view is a bit more pressing.

Feature entry: Sounds good to me, added https://www.chromestatus.com/feature/5148698084376576, I'll update it as I get feedback from other vendors.

On shipping concerns: Fully agree that this is not the right time to actually make a potentially breaking change like this, so all development will be behind a default off flag. As for enterprises, also agreed, as mentioned in the intent the plan is to add an enterprise policy that preserves the dialogs (ideally for a set period of time).

Avi: I'm not sure I understand what you mean by mixed feelings about enabling a flag. Do you mean we shouldn't do a % rollout, but instead launch to 100% tied to a milestone? If so, I think that'd be ok to avoid confusing developers on the timing, however, I don't think commiting to a specific milestone right now would be a good idea.

Thanks all,
-Carlos







Avi Drissman

unread,
Mar 26, 2020, 3:46:29 PM3/26/20
to Carlos IL, Mike West, blink-dev, Eric Mill, Mustafa Emre Acer, Emily Stark
I'm thinking about a presentation that I saw by an enterprise user, where they were caught by a Finch rollout, and tried to roll back to an earlier Chrome which failed. For something that's this subtle, I think making it connected to a milestone would likely be a good idea. I am definitely not asking you to specify any particular one right now.

Good to hear you already have enterprises in mind.

Avi

Carlos IL

unread,
Mar 26, 2020, 6:11:38 PM3/26/20
to Avi Drissman, Mike West, blink-dev, Eric Mill, Mustafa Emre Acer, Emily Stark
Yeah, connecting it to a specific milestone sounds like a good idea, we can go ahead and announce a specific milestone once releases are back to normal.

As for the spec change, I now filed https://github.com/whatwg/html/issues/5407 as a starting point to get feedback from other implementers.

Thanks again,
-Carlos

Charlie Reis

unread,
Mar 27, 2020, 12:10:47 AM3/27/20
to Carlos IL, Avi Drissman, Mike West, blink-dev, Eric Mill, Mustafa Emre Acer, Emily Stark
On Thu, Mar 26, 2020 at 12:39 PM Carlos IL <carl...@chromium.org> wrote:
Other dialogs: Yes, I believe onbeforeunload is already blocked for this case. 

Wait, I don't think this is true (which I've just manually verified in 80.0.3987.137).  Cross-origin subframes are allowed to show beforeunload dialogs, and it's important for cases like Docs or Office365 embedded as iframes in another document, to avoid data loss if you start to navigate away.  We had to quickly fix that in https://crbug.com/853021 when Site Isolation launched, since it wasn't initially working in out-of-process iframes.

I agree it would be great to get to a future where beforeunload isn't needed, but until that feature can be deprecated, beforeunload dialogs will probably need to work in cross-origin subframes.

Charlie

Joe Medley

unread,
Mar 27, 2020, 12:31:22 PM3/27/20
to Carlos IL, blink-dev, Eric Mill, Mustafa Emre Acer, Emily Stark
Please create a Chrome Status entry. We do let developers know about deprecations and removals.

image.png
Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195
If an API's not documented it doesn't exist.


Carlos IL

unread,
Mar 27, 2020, 1:34:16 PM3/27/20
to Joe Medley, blink-dev, Eric Mill, Mustafa Emre Acer, Emily Stark
Charlie: Yeah, that's right, I just tested it, and it indeed works, I must have misread when checking it before. That being said, in that case there is not really a confusability risk, so I think it can be decoupled from this removal. Sorry about the confusion.

Joe: I created one after the first round of comments, it's https://www.chromestatus.com/feature/5148698084376576

-Carlos



Joe Medley

unread,
Mar 27, 2020, 3:48:44 PM3/27/20
to Carlos IL, blink-dev, Eric Mill, Mustafa Emre Acer, Emily Stark
Sorry I overlooked that. Thank you.

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195
If an API's not documented it doesn't exist.

Mike West

unread,
Apr 2, 2020, 3:25:39 PM4/2/20
to Joe Medley, Carlos IL, blink-dev, Eric Mill, Mustafa Emre Acer, Emily Stark
We talked about this briefly at the API owners' meeting this evening. I think we've agreed on this in the thread, but just to be extra clear: we consider this Intent to be on hold for the moment, and would ask that y'all come back to this thread when the world has stabilized and you're ready to actually ship it.

-mike


Carlos IL

unread,
Apr 2, 2020, 3:29:48 PM4/2/20
to Mike West, Joe Medley, blink-dev, Eric Mill, Mustafa Emre Acer, Emily Stark
Thanks for the update, that SGTM, in the meantime I'll put together a CL(s) with the changes for this, but hold off on sending it for review until things are back to normal.

-Carlos

Domenic Denicola

unread,
Jan 14, 2021, 10:42:47 AMJan 14
to blink-dev, carl...@chromium.org, Joe Medley, blink-dev, Eric Mill, Mustafa Emre Acer, est...@chromium.org, mk...@chromium.org
Any interest in picking this back up?

Carlos IL

unread,
Jan 14, 2021, 1:01:28 PMJan 14
to Domenic Denicola, blink-dev, Joe Medley, Eric Mill, Mustafa Emre Acer, est...@chromium.org, mk...@chromium.org
Yeah, this slipped through the cracks once we started catching up to postponed stuff. I'm planning to finally get back to this soon.

I'll go ahead and comment on the spec issue to try and revive the discussion with other browser vendors then come back to this thread once we get more signals.

-Carlos
Message has been deleted

Carlos IL

unread,
Jan 15, 2021, 11:31:37 PMJan 15
to blink-dev, Carlos IL, blink-dev, Joe Medley, Eric Mill, Mustafa Emre Acer, Emily Stark, Mike West, d...@domenic.me
Quick update from the spec issue discussion:Firefox is supportive of the change, and is considering implementing it (FF bug). There was also support from Webkit, though not immediate plans to implement.
I wrote a PR for the spec, though I'm holding off on sending it for review until I write the WPT test cases.

-Carlos

Carlos IL

unread,
Feb 17, 2021, 7:37:31 PMFeb 17
to blink-dev, Joe Medley, Eric Mill, Mustafa Emre Acer, Emily Stark, Mike West, d...@domenic.me
Reviving this discussion: The spec change has now been merged (in https://github.com/whatwg/html/pull/6297), WPT have been added, and the relevant functionality in Chrome has landed behind a flag (minus the enterprise opt out, which is currently out for review in crrev.com/c/2694186), so we're now officially looking for the intent LGTMs.

-Carlos

Mike West

unread,
Feb 26, 2021, 3:04:50 AMFeb 26
to Carlos IL, blink-dev, Joe Medley, Eric Mill, Mustafa Emre Acer, Emily Stark, d...@domenic.me
Hey Carlos, apologies. This intent was put on hold in the API owners' tracking document, and I didn't notice its revival. I've marked it as live again, so I hope we get you more feedback quickly.

I don't believe this requires TAG review, as the API shape isn't changing at all; you're simply returning early in the cross-origin nested case. That's also unlikely to cause problems for developers, though there's certainly a risk that some applications will have relied on these dialogs for some portion of their work. I'm happy to see that the enterprise flag landed yesterday,and equally happy to see that WebKit landed an implementation last week. With that fairly strong signal in mind, LGTM1 to ship.

Please work with the enterprise team to make sure the newly-landed flag shows up in our notes for administrators.
 
-mike

Yoav Weiss

unread,
Feb 26, 2021, 3:53:16 AMFeb 26
to Mike West, Carlos IL, blink-dev, Joe Medley, Eric Mill, Mustafa Emre Acer, Emily Stark, d...@domenic.me

Daniel Bratell

unread,
Feb 26, 2021, 5:45:44 AMFeb 26
to Yoav Weiss, Mike West, Carlos IL, blink-dev, Joe Medley, Eric Mill, Mustafa Emre Acer, Emily Stark, d...@domenic.me

LGTM3

(My only concern would be enterprise and you have covered that with an enterprise policy)

/Daniel

Carlos IL

unread,
Mar 1, 2021, 8:53:21 PMMar 1
to Daniel Bratell, Yoav Weiss, Mike West, blink-dev, Joe Medley, Eric Mill, Mustafa Emre Acer, Emily Stark, d...@domenic.me
Thanks all. I've now filed a launch bug for this at crbug.com/1183590 (Google Internal), and contacted the enterprise folks to make sure administrators get advance notice of the change and policy.

-Carlos
Reply all
Reply to author
Forward
0 new messages