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