Intent to Remove: Cross origin subframe JS Dialogs

[Carlos IL]

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]

--
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]

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]

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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/MN2PR13MB36137FD51915AF2DA5E71725DFCE0%40MN2PR13MB3613.namprd13.prod.outlook.com.

[Guokai Han]

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]

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.

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.

[Avi Drissman]

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3Dfsovub9WC%3D2S5%2BRJoG1QosBJ10cLLcOH1rRquq3XA31Q%40mail.gmail.com.

[Carlos IL]

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]

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]

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]

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAABgKfW34qCM_dNsV8GVx6VxfXdFBtjAxKTt5R4Brzcj1EGY0A%40mail.gmail.com.

[Joe Medley]

Please create a Chrome Status entry. We do let developers know about deprecations and removals.

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

[Carlos IL]

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]

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]

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJUhtG8AThGD8zdTL77gRT4av%2BVPyq4C13S%3Dz9JrNq6vbzVSrg%40mail.gmail.com.

[Carlos IL]

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]

Any interest in picking this back up?

[Carlos IL]

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

[Carlos IL]

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]

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]

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]

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DeJxy%2BQGJfPJzySYUk1FiVRsRFO0J2uYNiO7R3fqpDKMQ%40mail.gmail.com.

[Daniel Bratell]

LGTM3

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

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEjZPQCAug_EPJEZCG_kcqoOmgoBvkzJJ-nYKtn8gd%3Dw7Q%40mail.gmail.com.

[Carlos IL]

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

[Guokai Han]

I read the discussion on this issue, and it seems that browser vendors basically agree with this change. A few days ago, some users encountered this problem when using Chrome 91 Beta.

Adapting to this change is not difficult, if the website is maintained by someone. But two questions come to my mind:

1. How do you inform developers of this change? Although this change has been delayed for a year, I haven't seen a post about this change published on the official Chromium blog, so I guess many developers don't know this change.

2. How can developers write robust code? All developers know window.alert() function, But not everyone realizes that it does not work in some edge cases.

[Carlos IL]

Hi Guokai,

Sorry that this change came by surprise, due to an oversight it was not included in the M91 release blog post in blog.chromium.org, but we have now updated the post to include this change. In general, this mailing list, the Chromium blog, and chromestatus.com are good places to monitor for changes like this. Additionally, since this change also involved a spec change, it was also discussed in the relevant spec repository (https://github.com/whatwg/html/issues/5407), those can be useful to monitor for changes that affect the spec, and to get an idea of what is coming or changing, but less so for specific milestone plans.

As for your question regarding code robustness, we added a console message informing why alert(), prompt(), and confirm() are not working. The alternative for sites is to show the messages in the site's UI itself, rather than on a modal dialog it they require this to work embedded in other sites.

Let me know if you have any other questions,

-Carlos

[Guokai Han]

Hi Carlos,

I watched this issue last year. It has nothing to do with me personally, I just have a premonition that some websites may be affected by this.

About communicating with developers. I know that browser vendors cannot send emails to all developers on the planet. I also know that many developers do not pay attention to these places(this mailing list, chromestatus.com or spec repository). You can only do your best to inform developers of this incompatible change, and give developers enough time to adapt to this change. From the perspective of information dissemination, official blog and official social accounts are most likely to notify developers (glad to see you updated the blog post). Then other developer-related media channels will further spread the news. In addition, MDN web docs should also be updated to add a note, so future developers will notice this change.

I treat "console messages" as a means of notification and interpretation to developers. It is very useful, but it is not related to code robustness. In general, whether a web developer or a chromium engineer, if you don't know all the possible situations when you write the code, then the code may have bugs, which only occurs in certain specific situations. In my opinion, we should try to avoid designing APIs that are affected by the runtime environment, or we'll need to do a runtime check when we use it. However, alert/confirm/prompt are APIs with a long history, not new APIs, so the notification method and the time set aside are very important.

The above is my personal opinion, I hope this change will not affect too many people.

Jackie

[Carlos IL]

Hi Guokai,

We appreciate the feedback, and will be more careful to include these types of changes in the release blog posts in the future. I will also file an issue with MDN once this goes to stable so a note can be added to the window.alert, prompt, and confirm documentation. We will also monitor for breakage as this is rolled out.

Thanks,

-Carlos

[Joe Medley]

Yeah, we should really fix this.

Gang, when you're in a stage on Chrome Status and you update the process stage (usually at the bottom of the stage panel) be sure to scroll down and fill out the "Status in Chromium" section. If you're not sure how to get back to it you can also go to "Edit all fields" then set "Implementation Status" (in "Feature Metadata"). If your status is "origin trial", set milestones in the "Origin Trial" box. If you your status is "Enabled by default", set milestones in the "Ship" box.

[User670]

Guess I'm a bit too late to give my two cents but...

While most professional, production websites avoided using alert, confirm and prompt, they are still quite common for people learning JS/web dev, and many tutorials include them. And when using a web-based prototyping tool like Codepen, this change may block the dialog boxes, potentially causing confusion to those that are following the tutorial. (I got this problem once, and took me quite a while before I noticed the console message! It's gonna be worse if someone relied on the dev tool's web-based "console" and never opened the actual browser's console.)

[Tim Glembin]

Hi,

As much as I understand the need for & the positive benefits of this change, it's going to break the web application for the company I'm currently working for. & that means interrupting the businesses of hundreds of companies who use our product globally, & by extension of that many, many thousands of users. I do understand how you arrived at your thinking that this change won't affect many people, given your % of page loads statistic, but if ever there were a misuse of statistical data then I feel that'd be right up there..

Is there any way you can rethink your solution on this one, & maybe come up with a strategy which has less of an impact upon those using cross origin iframes in a legitimate manner? Our website loads different parts of the application into a number of different iframes, & which come from a number of different domains depending upon which part of the application they represent. We own every one of these domains, but this change you're forcing upon us will make it incredibly difficult for our application to run without some major restructuring which will not only take time in development, but then a great deal longer in testing & QA. This kind of restructuring would take months, & cost who knows how much. We have less than two weeks.

Would it not be possible for there to be a way to whitelist trusted domains, so that cross frame functionality between these domains can continue to work as it always has? I don't see why you need to take away functionality which has a legitimate use, & is being used I would imagine a great deal more than the 0.00906% you claim it to be.

Like I said, I do understand the reasons for this change & appreciate the work you're doing to make the internet a better experience. I'm just asking you to please consider the collateral damage this solution will cause in it's present form.

Regards,

Tim

[Carlos IL]

Hi Tim,

I want to reiterate that we did consider the tradeoffs carefully. I also want to clarify that this will not completely remove the ability to embed cross domain iframes, or disable anything other than JS dialogs (i.e. window.alert, window.confirm, and window.prompt) for them. It's unclear to me from your comment whether your application relies on those modal dialogs, or just on cross origin iframes themselves.

 If your application does rely on modal dialogs, there are alternatives:

• If the application is mainly used in an enterprise setting, the SuppressDifferentOriginSubframeDialogs policy can be used to temporarily disable the restriction. This policy will remain in Chrome until M94.
• The dialogs can be reimplemented in web UI, and shown as part of the application itself instead of a through a modal dialog.
• If you control both the embedding site and the iframe'd site, which seems to be the case here, and require modal dialogs, you can postMessage from the iframe to the main frame site instead, then have the main frame site trigger the dialog.

Let me know if I can help with anything,

-Carlos

[Tim Glembin]

Thank you Carlos for your quick reply!

Unfortunately the application is not contained within an enterprise setting, so that flag won't help buy us that extra time before release M94 to work out an appropriate & robust solution. We do mainly use our own modal dialogs, but it's a massive application & there are still places where JS dialogs are being used. Ideally we'd like to replace all of those instances & that would be the long term plan, but with 11 days that's not at all realistic.

I have tried implementing a POC using postMessage to intercept the call to alert, confirm & prompt & send a message to the parent window to pop up the respective dialog there, which works fine except I haven't been able to find a way to halt JS execution in the child frame & wait for the response from the parent window before continuing to mimic the behaviour of these dialogs. If you know if this is at all possible & can help me out with an example that would literally save the day, but from my understanding of JS & how it processes commands, & I'm definitely no expert, but my understanding is that after calling postMessage there's no reason for the child iframe JS to not move onto the next task in it's queue. I'd love to be proved wrong on this understanding!

We do control all of the sites, so there are no restrictions there as far as I'm aware of.

I had thought about loading the child frames through a proxy so that they're loaded from the parent window domain, & have created a very simple POC to prove that this could work which it does. However, our application is not so simple & I'd be concerned trying to make that work might end up being more trouble than it's worth. Plus there's the issue of there being very limited time to do any thorough testing to be mindful of.

I think the postMessage solution seems like the best way to go, but only if I can find a way for the child frame JS to halt & wait for the result of the dialog. Otherwise I'd have to go through & add code to each JS dialog instance within the application to handle the callback to fix the flow problem this would create. & there's also another problem with that solution, as we allow customers to add custom JS & they could be using JS dialogs which I wouldn't be able to change, not without introducing some extra functionality to handle that. & again with that, time for thorough testing of such a code change isn't available.

So we really are a bit hamstrung by this change.

Please feel free to offer any advice you might have, & thanks again for taking the time to reply so quickly. Much appreciated :)

Regards,

Tim

[Tim Glembin]

I did have a suggestion, which was if you could whitelist trusted domain names in the parent window. Then people who are loading websites from domains which they own, into iframes within a website hosted in a different domain but which they also own wouldn't be affected. But it would still have the effect that I think you're after for all other scenarios, such as people loading iframes with websites which they do not own etc.

I feel that if this were the change you were implementing, it would make for an even better internet :P

Because I don't think it's your intention to affect people who have legitimately architectured websites which they wholly own to be adversely affected by this. The target is obviously people who are deliberately seeking to misuse iframe functionality.

Just my opinion of course :)

On Fri, 14 May 2021 at 14:06, saeid asade <saeidas...@gmail.com> wrote:

Do not worry and focus on your work with strength. As you said, this is the best solution for a better internet, and if you have a solution, offer it to compensate the damage. Otherwise, I will do my best to find a solution with consultants.  But we need some women, I hope you are patient.  Make sure we do the right thing

در تاریخ جمعه ۱۴ مهٔ ۲۰۲۱،‏ ۷:۰۷ Tim Glembin <tim.g...@gmail.com> نوشت:

--
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/CAMsakZMXU4d03Y_xLH2ztXHZ_%2BJRMD2KDQ3QZAfFsh8JBhcv-g%40mail.gmail.com.

[Tim Glembin]

You can whitelist domains with the CORS Access-Control-Allow-Origin header.

I feel as if that's the piece missing with this change, & adding it wouldn't make this change any less redundent than it has made CORS. It simply allows legitimate usage to continue to function.

[Ian Clelland]

On Fri, May 14, 2021 at 12:41 AM Tim Glembin <tim.g...@gmail.com> wrote:

I did have a suggestion, which was if you could whitelist trusted domain names in the parent window.

This sounds very much like the permissions policy model -- a feature allowed in top-level documents can be delegated to trusted frames with something like <iframe src="..." allow="dialogs">, but by default the feature is blocked in cross-origin frames.

I don't know enough of the context around this specific deprecation and removal to say whether it's appropriate in this case, but it might be a feasible path forward. It would have the effect of immediately blocking all cross-origin usage, while providing developers with a simple fix to reinstate the old behaviour on a frame-by-frame basis.

Ian

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMsakZNgtbmG%3DE7nvkbYjOsWgpTPQjAAvwQrtMpdtD9qkt6V4w%40mail.gmail.com.

[Tim Glembin]

Thanks Ian, you hit the nail right on the head!!

That would definitely be a more complete & elegant solution, & if the intent were still there later on to phase out using dialogs altogether then that could still be the end goal. But at least it'd give developers time to phase them out of their own websites & applications first. Which for some might not be such a big change, but I know for the applications I'm looking after at the moment, we would need at least 6 months if we started yesterday.. because it's not a case of simply swapping out one dialog for another, that's the easy part. The JS dialogs halt command execution, & there's no exisiting way to simply swap that out. Entire sections of code relying upon those halts will need to be rewritten to accomodate the change in execution flow, & then all those changes need to go through QA. It's certainly no minor task.. 

Here's hoping :D

[Rick Byers]

+1 to a permission-policy based opt-out. It's a big part of why we created feature policy in the first place - to enable a pragmatic migration path for deprecating bad/annoying 3p behavior (sync-xhr was one of the first use cases). Perhaps API owners should be looking to require a permissions policy opt-out for any iframe-specific intervention going forward? I'd catalog this under "ease of adaptation" in our compat principles. Since a postmessage-style workaround is theoretically possible (just hard to convert sync code to async to maintain blocking behavior), is there any real reason why a policy opt-out would harm the goals of this intent?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d73e72d6-8510-466a-8ad0-61428a8a91dan%40chromium.org.

[Chris Thompson]

To clarify this particular use case, are you relying on the fact that window.alert() pauses task execution, or are you relying on it being a blocking operation for the JS code? The latter seems like it could be resolved with a monkey-patch, while the former is technically optional behavior per the HTML spec (although my guess is all browsers pause).

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_Xuqe1tCspMLrMAgp6SxUDo7mPc%2Bx63VFVPGyLtbZZ%2BA%40mail.gmail.com.

[Domenic Denicola]

I’m less sure in this case that permissions policy is a good idea, unless it’s time-limited. We’re on a long, slow path to deprecate and remove window.alert/confirm/prompt and beforeunload handlers due to their role in user-hostile event loop pausing, as well as phishing and other abuse mechanisms. We’ve been successfully chipping away at them in various cases, e.g. background tabs, subframes with no user interaction, and now cross-origin subframes. Each step is hard-fought progress toward the eventual goal, and we should consider carefully whether we want to regress, even in an opt-in manner.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_Xuqe1tCspMLrMAgp6SxUDo7mPc%2Bx63VFVPGyLtbZZ%2BA%40mail.gmail.com.

[Rick Byers]

Yeah I get that, they're clearly a mistake in the platform and we're all anxious to be able to get rid of them. But I personally believe that opt-in phases are the most pragmatic way we can ever really phase out the hardest parts of the platform to remove. Otherwise we're just constantly in this state of one site (like this) saying we break them and having to decide do we turn it back on for everyone or not? Reverse origin trials are another good mechanism for this (as proven with ShadowDOM V0), arguably better than permissions policy when we believe something to really be temporary. Perhaps we should consider a reverse OT in this case?

This is maybe a smaller example where removal without an opt-in period was plausible. But for the harder cases like sync XHR and unload handlers, I can't imagine them at all being pragmatic without some form of longish opt-in period. WDYT?

[Domenic Denicola]

Yeah, I think we have a good spectrum of options: no opt-in, enterprise policy opt-in, reverse origin trial, and permissions policy. In my opinion, in this case the discussion should be whether the existing enterprise policy opt-in was sufficient, or whether we should also deploy something like a reverse origin trial. Going all the way to permissions policy does not seem warranted, although I tend to agree it’ll be an important tool for things like sync XHR.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-XJn14Gy1SJ%2B6HNs%3DwAwfyBKHyThMHtYC1ThUUG05VfQ%40mail.gmail.com.

[Carlos IL]

+1 to what Domenic mentioned. I am open to discuss whether we need a reverse origin trial, but I'm not in favor of a permissions policy. I think reverse OT is much better suited for a temporary case, and in my opinion any such opt-outs have to be strictly temporary (like the enterprise policy), since as long as we are allowing any type of opt-out, the UX explaining this case has to be maintained, and removing it was an explicit goal of this deprecation (both due to it being abuse prone, and due to it holding back other efforts to improve JS dialogs UI).

-Carlos

[Tim Glembin]

I'd be more than happy with a reverse OT :D

As I've mentioned previously, I do appreciate & support the direction you're taking & certainly aren't here to present as some kind of annoying speed bump.. 

I'm just here to plead a case for there to be a transition period, so we have time to properly assess & schedule the work we need to do to bring our code up to speed.

Thank you all for taking the time to consider & discuss this issue as well. I wasn't sure I'd even get a response, so to see so many replies.. I'm very grateful :)

[Rick Byers]

Thanks Tim, glad to hear reverse OT would work for you. And thank you for reaching out. We are lucky to hear of scenarios like this BEFORE the changes hit stable and are causing problems at large scale.

Thanks for being open to the OT option Carlos. In our experience, hearing one story like this prior to a breaking change hitting stable typically means there will be at least 10x as much breakage and frustration post-stable. Given that there's really no low-cost "ease of adaptability" story for scenarios like this (eg. if a subframe must block to get the result of a 'confirm' dialog), my preference would be to figure out how to get a reverse OT setup for this before it's deployed en masse. But other API owners may still feel it's fine to launch as-is. 

The M91 stable cut is fast approaching - if we wanted to make a change what are our options? Is it under finch control? Would we just disable for 91 and get a reverse OT setup for M92? Would there be any great downside or other cost to a one milestone delay like that?

Thanks,

   Rick

[Rick Byers]

[-eric...@google.com since that address is bouncing]

[Carlos IL]

Adding a temporary reverse origin trial sounds ok with me. It is a bit late to merge the change in my opinion, so this does mean we will have to delay to M92 for the launch. The biggest cost from the delay might be developer confusion when they don't see the change, but I think that can be mitigated by keeping this thread and chromestatus updated.

This is indeed behind a Finch flag, but we were planning to launch default on (and keep the flag as an emergency switch). Since there is still time to disable the flag in code, I think we should do that if we are delaying (and merge the reversal to 91), then re-enable when the origin policy is added. 

Thanks all for the feedback,

-Carlos

[Rick Byers]

On Fri, May 14, 2021 at 5:03 PM Carlos IL <carl...@chromium.org> wrote:

Adding a temporary reverse origin trial sounds ok with me. It is a bit late to merge the change in my opinion, so this does mean we will have to delay to M92 for the launch. The biggest cost from the delay might be developer confusion when they don't see the change, but I think that can be mitigated by keeping this thread and chromestatus updated.

This is indeed behind a Finch flag, but we were planning to launch default on (and keep the flag as an emergency switch). Since there is still time to disable the flag in code, I think we should do that if we are delaying (and merge the reversal to 91), then re-enable when the origin policy is added. 

That sounds great to me, thank you.

Keep in mind that finch config doesn't apply on first run or for other chromium browsers, so the state in the code still matters quite a lot.

[Carlos IL]

This is now disabled by default on M91 (as of crrev.com/c/2900985). I'll go ahead and re-enable for 92 once the origin policy is in.

Thanks all,

-Carlos

[Tim Glembin]

Thanks so much Carlos, really appreciate you & your team taking the time & being so accommodating :)

[Rick Byers]

Thank you Carlos!

And thank you Tim for giving us this feedback before the change hit stable :-). If you haven't used an origin trial before, check out the docs so that you're ready to add the tags to your site when the trial becomes available for M92.

Thanks,

   Rick

[Michael Yingling]

Hey guys.

This change rolled out to a bunch of sites the past two days as you know, and it's seriously breaking for all embedded widgets who were using browser-based alert and confirm boxes.  Given these alerts and confirms are by an iFrame injected by an external JS file (in my case, a SaaS business my customers subscribe to), is there a way to whitelist the domains (ex: myingling.bookingwidget.com) on the parent site (myingling.com) to allow alerts/confirms to go through this way?

Otherwise it's just forcing devs to build fake alert/confirm boxes instead of using the browser-native ones, which seems a bit like a step backwards in terms of standardization.

[PhistucK]

It is strongly recommended that you build those fake-alert/confirm-boxes because the direction the platform (well, the browsers and then the platform) is going is to eventually (still a very long way to go, though) deprecate and remove alert/confirm/prompt altogether (even for non-iFrame cases) as far as I know, due to their blocking nature, bad (albeit consistently bad ;)) user experience and their complexity in the browser/renderer code.

Those functions were pretty much a mistake in hindsight, just like showModalDialog which went away years ago.

☆PhistucK

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/27c12307-f114-4f96-bf98-285a29422114n%40chromium.org.