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.

[Michael Yingling]

Chromium is planning to abandon alert and confirm altogether?  I don't think synchronous JavaScript is bad just because it is synchronous.  Sometimes it is intentionally implemented that way.  For example, on my software we do a very simply form validation on submit, with code that looks something like the following:

var warn = false;
var error = false;
var message = "";
if(some error condition) {
    error = true;
    message += "\n - Fix error condition";
}
if(another error condition) {
    error = true;
    message += "\n - Fix other error condition";
}
if(warning condition) {
    error = warning;
    message += "\n - Fix warning condition";
}
// etc, etc...
if(error) {
    alert(message);
    return false;
}
else if(warning) {
   return confirm(message);
}
else return true;

I would argue this is great JavaScript: it's light-weight, easy to read, easy to extend, performs both error and warning checks, relies upon the browser's built-in alert/confirm functions (which is obviously the problem now) so it should be easily adapted to various browsers, accessibility tools and device sizes.  Why break this?  And doesn't backwards compatibility have some weight here?  If every company has to re-write their entire site every 2-years 

I understand the security concern for users who don't pay attention to the "domain says..." prefix, but is there a way then (using a meta tag or something on the parent site) to whitelist safe iFrame domains to bypass this?  I'm asking sincerely, trying to understand if there is a work-around I just cannot find in the documentation (which may be there, I'm just failing to find the needle in the haystack).

I appreciate your help,

Michael Yingling

[Tim Glembin]

Hi Michael,

The only recourse you have is to register for the Origin Trial for Disable Different Origin Subframe Dialog Suppression & follow the Origin Trials Guide for Web Developers guide to add the token you receive upon registration to your iframe pages. This will buy you some extra time (until December 15th at this stage) to replace any JS dialogs in your application. Once the trial has ended, the behaviour you're experiencing in your application at the moment will be permanent.

Regards,

Tim

[Michael Yingling]

I apologize if I sound contrite, but what was the logic behind this major change?  I see a few threads, but am afraid I'm not finding any underlying reason beyond people missing the domain in the alert forewarning, so this was done to prevent careless users from phishing attempts (arguably only from the prompt function, as alert and confirm give binary input, at most).

I understand web standards evolve rapidly, but I'm highly concerned about the future viability of Chromium if the plan (however distant) is to abandon basic underlying functions like alert and confirm altogether.  Backwards compatibility is still a very important function of all technologies; it's one thing to deprecate by changing a default setting while providing an override, but another to simply remove the foundation entirely.  It's akin to changing the voltage of outlets in everyone's house and expecting all manufacturers to adjust, rather than releasing a converter.

We have already begun replacing these functions since they are going to be completely removed in 2021 anyways (at least unless there is sufficient backlash to undo this, or people migrate to a different browser).  Meanwhile I am sincerely curious where the meeting for these types of changes take place?  It seems I missed the Beware of the Leopard sign, and per my experiences the past 48 hours (with broken jsfiddles, demos on sites, logins to various subscription services, etc) that I'm just one of many.

[PhistucK]

Do you think it is a sensible functionality, to block the world (block the entire tab, previously blocking the entire browser, but thankfully that is not happening anymore... Baby steps) just because an iFrame decided to show an alert? I think it is user hostile and this hostility brings a lot of complexity to the table in terms of browser/renderer implementation.

So while it is a basic functionality for a developer that just wants some quick solution for showing an alert, it is not a nice functionality for the user.

So user hostility is something that can indeed be resolved by delegating a feature policy/sandbox. But the code complexity will stay there. This complexity was/is, as far as I know, used for exploiting many security vulnerabilities, because it is extremely hard to get right.

Remember that cross origin iFrames live in different processes altogether now, so you have a lot of completely separate entities to stop/not stop/block/synchronize.

☆PhistucK

[Tim Glembin]

Hi David,

If you take the time to read this entire thread, you shall find the viable workaround you're after :)

Regards,

Tim

On Tue, 27 Jul 2021 at 20:37, David Coxon <david.dan...@gmail.com> wrote:

This change makes this attribute pointless now - https://html.spec.whatwg.org/multipage/origin.html#sandboxed-modals-flag

Would a better short term strategy be to make this false by default rather than disable the behavior entirely?

[David Coxon]

This change makes this attribute pointless now - https://html.spec.whatwg.org/multipage/origin.html#sandboxed-modals-flag

Would a better short term strategy be to make this false by default rather than disable the behavior entirely?

On Saturday, July 24, 2021 at 10:30:00 AM UTC+1 PhistucK wrote:

[Sir Diek Blak]

this decision has ruined our whole application that displayed its components via an iframe, where the main application was held on "client.domain.com" and the component was held on "subcomponent-api.domain.com"

i can imagine this will bring a lot of problems for applications that use their components as a service

[Václav Lukášek]

Some distributed system spread scripts from different subdomain like CRM Salesforce, for this fuctionality should exist similar directive as for CORS, otherwise it is problem to find any workaround.

Dne úterý 27. července 2021 v 12:50:17 UTC+2 uživatel Tim Glembin napsal:

[David Coxon]

Like others I am going to preface this entire email with a grovelling apology for the moan that is about to follow. I entirely agree with the change and roadmap towards removing these apis in the future.

However I must say I am quite surprised that this change has gone out without a short term workaround. We, and probably many others have been blindsided by this change and are now scrambling to resolve it. As much as we would all like to, we need to be honest and accept keeping abreast of all the upcoming chrome changes is always a distant priority when maintaining complex old software.

I am reminded a bit of the same site cookies change, however there was a viable workaround that would work in the short term, giving teams plenty of notice in case they missed the deadline. 

I realise 'alert' is a much more obscure feature, but to roll the change out without a short term workaround (e.g. sandbox flag / header) to give developers a bit more time to prepare  seems a little rash, even if it is for the greater good. 

Building an html-based equivalent to alert is a non trivial piece of work, especially when blindsided.. Furthermore, it may not even be sufficient if your code is dependent on the blocking nature of the alert. This is compounded by the fact that most sites that use 'alert', probably aren't actively maintained. There's not even a polyfill available yet!

End of moan, and again a formal apology for said moan. I would never have dreamed of the day when I was defending window.alert but here we are!

On Saturday, July 24, 2021 at 10:30:00 AM UTC+1 PhistucK wrote:

[Domenic Denicola]

From: Stephen Shaw <ste...@codepen.io>

> As a lot of new developers use our site to learn the basics of web coding, it's not uncommon for them to try out functions like `alert`, `confirm`, etc. in legitimate manners. We host the user authored code on a separate domain for many security & SEO reasons. That code is executed inside of an iframe, and after this change those methods are now unable to be used.

This is great! It means they won't use these functions in the future, which helps with our goal of eventually deprecating and removing them from the platform. I'm really glad that in this instance they get to learn about the problem in a low-stakes learning environment instead of in production.

[Stephen Shaw]

Developer at CodePen ( codepen.io ) here. 

As a lot of new developers use our site to learn the basics of web coding, it's not uncommon for them to try out functions like `alert`, `confirm`, etc. in legitimate manners. We host the user authored code on a separate domain for many security & SEO reasons. That code is executed inside of an iframe, and after this change those methods are now unable to be used.

After reading through this thread, I get the overall point of deprecating these methods. However it would really be helpful to have a `sandbox` or `allow` flag on an iframe that would permit these methods on cross-domain iframes. Doesn't seem like that's being considered, unfortunately.

For our unique case, are there any recommended solutions for allowing `alert` and related methods within the CodePen editor? A hacky `postMessage` solution like shown here ( https://groups.google.com/a/chromium.org/g/blink-dev/c/hTOXiBj3D6A/m/gFXmgIz9AwAJ ) seems to be the closest, though I don't think that would allow something like `confirm` to work correctly.

- Stephen

[Fran Alcántara Checa]

I have some apps as Gsheet Add-ons. I use alert and confirm to obtain confirmation from the user to make actions. Apps don't work. How can I solve this? I'm very worried

[Narbeh Minassian]

As a teacher, I have my students use Replit along with alert() statements when teaching JavaScript. This recent change broke this.

[Carlos IL]

Just to reiterate what was mentioned above: The origin trial mentioned previously in this thread has launched, and can be used as a temporary workaround. In addition, for use cases where affected users are in an enterprise setting, there is also a temporary enterprise policy that completely disables the block.

-Carlos

[Suman Aitha]

This fix is not working. we registered the app and added the token part of header still same issue coming

[Carlos IL]

The origins that need to be enrolled (and include the header) are those of the iframes, not the containing site. Are you implementing it that way and still seeing issues?

[Suman Aitha]

we are using frameset not iframes. 

[Carlos IL]

We decided to disable this deprecation temporarily (for 2 weeks, until August 15, 2021) to provide more time for websites to address the issues caused by this change, or enroll affected origins in the origin trial.

If neither the origin trial or the enterprise policy address your concerns, please comment in the implementation bug at crbug.com/1065085.

The configuration to disable the deprecation should reach most Chrome instances in a few hours, but in some cases might take longer. Chrome needs to be restarted for the change to take effect.

Thanks,

-Carlos

On Fri, Jul 30, 2021 at 11:35 AM Narbeh Minassian <nar...@gmail.com> wrote:

I wouldn't be surprised if MS found that the change broke some of their own systems and reverted back for the time being. That's just my speculation.

On Fri, Jul 30, 2021 at 11:22 AM Andy Buboltz <an...@awbuboltz.com> wrote:

We noticed today that Edge Version 92.0.902.62 is suddenly showing dialogs within iFrames. The previous release from last week had it blocked. Was this reversed by chance? Nothing in the release notes as of yet. Could Chrome be soon to follow?

[Narbeh Minassian]

I wouldn't be surprised if MS found that the change broke some of their own systems and reverted back for the time being. That's just my speculation.

On Fri, Jul 30, 2021 at 11:22 AM Andy Buboltz <an...@awbuboltz.com> wrote:

We noticed today that Edge Version 92.0.902.62 is suddenly showing dialogs within iFrames. The previous release from last week had it blocked. Was this reversed by chance? Nothing in the release notes as of yet. Could Chrome be soon to follow?

On Thursday, July 29, 2021 at 1:08:16 PM UTC-5 Suman Aitha wrote:

[Andy Buboltz]

We noticed today that Edge Version 92.0.902.62 is suddenly showing dialogs within iFrames. The previous release from last week had it blocked. Was this reversed by chance? Nothing in the release notes as of yet. Could Chrome be soon to follow?

On Thursday, July 29, 2021 at 1:08:16 PM UTC-5 Suman Aitha wrote:

[Daniel Bratell]

The change was temporarily disabled in both Edge and Chrome in that case. Team response here:

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAABgKfWmxZFuXg57z5DKvOMouDzNxc%2BLFfxW0kBQkjfCZHKU_g%40mail.gmail.com

/Daniel

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

[Daniel Bratell]

Better link: https://groups.google.com/a/chromium.org/g/blink-dev/c/hTOXiBj3D6A/m/V5BodiaZBAAJ

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a7ba46f5-fe0b-068c-e337-91746ca1fd86%40gmail.com.

[Andy Buboltz]

Daniel, both links appear to be deleted.

[K. Moon]

Looks like there was a linkification error; the link is correct, but clicking on it gave the old link.

This one should be fixed:

https://groups.google.com/a/chromium.org/g/blink-dev/c/hTOXiBj3D6A/m/V5BodiaZBAAJ

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e7005f9e-d68f-4f0c-9d33-b6a27ba79ed0n%40chromium.org.

[oliver grudem]

Outright deprecating the alert and confirm methods from an iframe? Why not add this to the allow attribute? 

<iframe allow="alert;confirm">

[Andy Buboltz]

An iframe attribute type solution could be a possibility, but what needs to happen first is an extension of this deprication removal to give proper time for discussion and code changes. August 15th is already quickly approaching and we're still in the discussion phase. Multiple months (ideally 6) are necessary for large enterprise organizations to push updates to the healthcare realm.

[Chris Harrelson]

Hi all,

Thanks for the continued feedback. In terms of next steps in the short term, I'll repeat Carlos's comment:

"If neither the origin trial nor the enterprise policy address your concerns [within two weeks], please comment on the implementation bug at crbug.com/1065085."

--

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/CAOjiz%3D8QAbk4GEdg7cnZoiU9dBs2Ek5pbxW0tnnDUSkueUtZKA%40mail.gmail.com.

[Narbeh Minassian]

I think the problem with alert(), confirm() are that they can be used cross-origin in iframes and the host website cannot control whether or not these dialogs are used correctly so I understand the reasoning behind it but there should be an override that the host can apply if they actually want this behavior (think of Replit, Codepend and other prototyping environments). Something to the effect of

<iframe allowdialogs="true">...

On Wed, Aug 4, 2021 at 12:19 PM Matthew Phillips <mat...@skypack.dev> wrote:

I'm a web developer who thinks removing alert/confirm is a bad idea, given the number of historical (and unmaintained) websites that use this feature.

The Motivation section here primarily discusses UI as a reason for removing the feature. I don't understand why it is not possible to make non-native looking UI for this feature. 

Why can't you place the exact same restrictions on window.alert that you place on HTML/CSS? For example if it is used within an iframe place the alert modal within that frame.

---

There are also other ways to make the modal not look native. For example:

* Give it a color scheme that is not the color scheme used by native modals. For example a hotpink background

* Use a shape for the modal other than a rectangle (maybe a triangle)?

* Include as a large title "THIS IS NOT A NATIVE MODAL".

These are absurd extreme examples, but I do so to try and understand what are the restrictions that stop you from making the modal more obviously non-native.

[Matthew Phillips]

I'm a web developer who thinks removing alert/confirm is a bad idea, given the number of historical (and unmaintained) websites that use this feature.

The Motivation section here primarily discusses UI as a reason for removing the feature. I don't understand why it is not possible to make non-native looking UI for this feature. 

Why can't you place the exact same restrictions on window.alert that you place on HTML/CSS? For example if it is used within an iframe place the alert modal within that frame.

---

There are also other ways to make the modal not look native. For example:

* Give it a color scheme that is not the color scheme used by native modals. For example a hotpink background

* Use a shape for the modal other than a rectangle (maybe a triangle)?

* Include as a large title "THIS IS NOT A NATIVE MODAL".

These are absurd extreme examples, but I do so to try and understand what are the restrictions that stop you from making the modal more obviously non-native.

On Tuesday, August 3, 2021 at 1:55:36 PM UTC-4 Chris Harrelson wrote:

[Carlos IL]

Thanks everyone for the feedback. We have decided to postpone this deprecation until at least January 2022 to give us time to do more outreach and propose alternatives to sites that rely on this behavior, and to give website owners more time to explore alternatives.

We will provide an update once we have a set milestone/date to re-enable the deprecation.

[Michael Yingling]

First I'd like to thank the Chromium Team for listening to us devs and delaying this.

My vote is still for an attribute on the iFrame to allow the frame to alert/confirm/prompt (ex: <iframe allow="alert"...), but even if that isn't the chosen path in 2022, might I suggest treating the iFrame as its own tab?  Not long ago an alert blocked the whole browser, and I don't think ANY devs minded it being a tab-specific blocking.  Could the iFrame's alerting just block the Frame ITSELF?  It could even appear only above the iFrame's visible window (which would then not impact malicious/hidden iFrames).  I don't pretend to know the complexities of Chromium dev, but this seems like a solution which would require zero dev by the millions of developers out there (by backwards compatibility), while still limiting end-user impact per your concern (since it wouldn't block the entire tab).  Mock of the change here: https://upload.picpaste.me/image/VogVx

I think that would solve every specific use-case I've seen in this thread, plus it would maintain standardization of the native alert/confirm/prompt functions without requiring devs like myself to overwrite them.  Frankly, I trust your dev implementation to change an existing function more than I trust myself to overwrite it, or implement a work-around.  And given the feedback here I think everyone else agrees.

Again, thanks to the Chromium Team for responding to the feedback.  I hope this suggestion works, especially if the <iframe allow="alert"... option is not adapted.

[Matthew Phillips]

Thanks Carl, this is tremendous news. Can you speak on what to do about historical / unmaintained sites?

[Chris Harrelson]

Hi,

On Thu, Aug 5, 2021 at 12:42 PM Matthew Phillips <mat...@skypack.dev> wrote:

Thanks Carl, this is tremendous news. Can you speak on what to do about historical / unmaintained sites?

When web platform changes are made, they apply to all sites. Chromium doesn't have special treatment of historical or unmaintained sites.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/fb0bfacc-0342-4645-9ea7-3aa8a4633ba0n%40chromium.org.

[PhistucK]

Yes - they stopped developing it and stopped adding new features. Which is precisely what happens to Chrome, right? Total stagnation? Funny.

☆PhistucK

On Tue, Aug 10, 2021 at 9:33 AM Narbeh Minassian <nar...@gmail.com> wrote:

Remember what happened when Microsoft thought they owned and controlled the web with their Internet Explorer?

On Tue, Aug 10, 2021 at 12:44 AM Pixel <markoz...@gmail.com> wrote:

Can you please stop this, you already destroyed Flash and the backspace key which a lot of websites/companies/people still use. If you keep removing things in this fashion its time for people to switch browsers that supports everything and not nothing. Your starting to make the old Internet Explorer look like the golden phase.

Only just found out about this via this post:

https://css-tricks.com/choice-words-about-the-upcoming-deprecation-of-javascript-dialogs/

Twitter thread related:

https://twitter.com/chriscoyier/status/1420027533005836298

Only constructive feedback to give is not to do it.

[Andy Buboltz]

Hey Carlos, with year end approaching, we really need some sort of clue into what the plan will be. Will these dialogs be removed at some point, if so, when?

If not, that's great, but either way, we need to know what to tell our customers.

[Carlos IL]

Hi Andy,

Thanks for reaching out. We are still analyzing whether it's feasible to re-launch in January, but we'll have news soon.

-Carlos

[Brandon McConnell]

Hi all,

In the event that the alert/confirm/prompt window methods are entirely deprecated, not just for framed windows, this could actually be just as much an opportunity to take a large step forward in innovating for the future of the web, especially in regard to a11y accessibility.

At this time, semantic HTML has grown in popularity and use, yet there is still no native function for anything equivalent to alert/confirm/prompt without a developer creating a full view-blocking modal, forcing either acknowledgment, confirmation/declination, or input. The current methods are not only dated—as much as I use them—but they are also dangerous. We all know the classic example of a site repeatedly bringing up confirmation modals to trap someone on their site, whether intentional or not. Thankfully, Chrome and other browsers combat this by showing a checkbox to suppress repeated pop-ups if they occur in repetition. It's a nice fix, but still not quite the ideal solution, which is what leads us here.

With semantic HTML in mind, it may be time for some sort of native `<modal>` element which could support native focus-trapping for accessibility and even modal stacking. Of course, this is much more easily said than done, but the web has virtually been begging for something like this for over a decade. The entire idea of modals is largely ambiguous for many developers, and there are many, many developers on platforms like WordPress who still rely on 3rd party plugins for such features because developing your own modals take too much effort, mixing HTML, CSS, JS just right to get the perfect modal architecture and hierarchy. Developing a native modal within a semantic `<modal>` element would solve several problems:

   — pop-up spam abuse prevention: solves the issue of repeated pop-ups preventing exiting the page, because all `<modal>` would exist in the page's code itself at the DOM-level, not at the browser's level (via window)
   — accessibility: a `<modal>` tag with built-in focus trapping would instantly make modals much more accessible, solving many of the issues with most modals today. Similar to the `for` attribute for input labels, there could even be a built-in method for opening and closing these modals, other than the `:target` trick floating around today
   — bar of entry: many developers uncomfortable with JavaScript would be able to more easily create modals if there were a native `<modal>` tag which supported many of the same functionalities which cause them to jump to much simpler though archaic solutions like the alert/confirm/prompt methods
   — full artistic license: adding a native `<modal>` element with whatever needed custom attributes, default styling, and pseudo-elements would allow for vast customization, potentially opening an entirely new world of potential for developers and packages to be built around the idea of `<modal>` customization
   — JS flexibility: for those developers who are more comfortable with JavaScript and who typically do craft their own modals from scratch, animating them in and out as needed, implementing focus-trapping, the whole nine yards— adding a native `<modal>` element would also bring with it new and more modern APIs, potentially as simple to use as the alert/confirm/prompt methods are today.

Especially regarding that last point, as it's likely applicable to most of us in this thread, there are many benefits to implementing our own custom modal systems. I personally have spent MANY hours fine-tuning exactly the way I like my modal components over the years, so much so that it's one of the few pieces that I copy and paste into almost every client project I work on, and then style and refactor as needed for the given project. Modals are a beast of their own rank, and because of that, they're seldom uniform. My modals will be different from those of the developer, and so on. Implementing `<modal>` with custom APIs would better uniformize how we developers create, use, and maintain modals on the web and remove the need for the alert/confirm/prompt window methods, while also incentivizing much of the web to make the switch with greater ease.

At the very least, I think we should hold off on full deprecation until Q1 or Q2 of 2023 to allow sites a year to catch up and restructure their processes. For us developers, most of us can pivot and make this change overnight in most cases, but for the thousands/millions of clients out there who still use this functionality, we may need much more time to transition them. 2022 should be a year of transition, moving all sites away from these methods. Firstly, if there isn't a warning already, we should probably trigger some sort of warning to the console any time an alert/confirm/prompt is found in JS code bring used, warning the site owner(s)/manager(s) that the feature will soon be deprecated.

Of course, these are all just my thoughts, and I am aware that I am introducing a somewhat off-topic idea here, but I believe it is fully relevant to this discussion and may in fact the key, or at least one potential key to moving the web away from some of the older methods.

Best regards,
Brandon McConnell

[Daniel Herr]

That's what <dialog> is for.

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog

[Brandon McConnell]

I have since been informed of the experimental `<dialog>` element, which is more or less what I was describing, so please disregard my previous comment, except in regard to my closing thought on the timeline of this deprecation, repeated here for convenience:

> At the very least, I think we should hold off on full deprecation until Q1 or Q2 of 2023 to allow sites a year to catch up and restructure their processes. For us developers, most of us can pivot and make this change overnight in most cases, but for the thousands/millions of clients out there who still use this functionality, we may need much more time to transition them. 2022 should be a year of transition, moving all sites away from these methods. Firstly, if there isn't a warning already, we should probably trigger some sort of warning to the console any time an alert/confirm/prompt is found in JS code bring used, warning the site owner(s)/manager(s) that the feature will soon be deprecated.

On Thursday, September 23, 2021 at 12:25:24 PM UTC-4 Brandon McConnell wrote:

[Brandon McConnell]

I was not aware of `<dialog>` but yes, this is exactly what I had in mind. Thank you.

[Luuk Lamers]

Sorry to scream into the void, but as much as I would love to use <dialog>, it is not a feasible alternative to newcomers, or even senior devs.

For one, it has no native data binding (like prompt kind of has). It also doesn't work in Firefox (partially) or Safari (completely).

Now I know Chromium probably doesn't give a crap about the other browsers but this would create a split situation.

Chromium would be the browser that requires for a difficult workaround for devs:

• Dialog doesn't have data binding out of the box (like prompt)
• UI breaks because there are no defaults anymore
• Alert/Confirm/Prompt have (partially for Prompt) baked-in browser translations. Dialog does not.
• Alert/Confirm/Prompt can be cancelled by using the escape key. Dialog can not.
• Alert/Confirm/Prompt can be prevented from firing too many times by the browser. Dialog can not. (Ad terrors)
  
• Dialog is DOM, so it influences layout, paint, etc.
• Dialog is DOM, so it stacks in DOM order.
• Dialog is DOM, so preventing scroll when it's open has to be caught.
  
• Dialog default styling shoves it off screen when there's enough DOM before it. position:fixed won't help if it is contained
  
• For full cross-browser support, <form method=dialog> also has to be added by Firefox and Safari. Also, querying browser-support is kind of broken.
  
• A polyfill would have to implement all the functionality of alert/confirm/prompt (eg. include styling as dialog has none, button to confirm/cancel the dialog, i18n text, etc.)

I have set up a test page to see some of these things in action: https://codepen.io/xaddict/pen/LYLMrrr

Ever since I heard of <dialog> I return to it now and then because I love the idea. But this thing is far from ready as a drop-in replacement for production environments.

I also don't see any other devs bother with it since stuff like sweetalert/vue-js-modal/etc do the job better out of the box but deal with the exact same problems as above. And more (like a11y)

[Chris Harrelson]

Hi,

I'd like to correct one misconception about <dialog>. Dialogs only open when you call showModal() on them. (Setting the open attribute is not enough.) This causes them to be placed in the top layer, which re-parents them in the layout tree (but not DOM) into a stacking context above all other content, and makes them position:fixed, plus some other default UI styling (and which can be overridden by the author to customize). The top layer also isolates the dialog in terms of layout from the <html> element and its subtree. As a result, dialogs will not cause any layout or paint side-effects on the existing content.

Once shown, a dialog also supports dismissal via the escape key.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ee380346-9d92-4b74-b21d-5ea812cfd3d7n%40chromium.org.

[Luuk Lamers]

Good to know. I've updated the example to use modals through showModal() and a dialog through show()

This would negate my points 4, 6, 7 and 9. But it decreases browser support even more (no support whatsoever in Firefox and Safari at the moment)

But I think the use of a modal will always incur composite and paint right? (it's at least what I'm seeing in the Performance panel and setting backdrop to transparant seems to make no difference)

And to get back to the original point of alert/confirm/prompt in cross-origin iframes…

I don't get why the solution couldn't be to by default sandbox cross-origin iframes (which don't have the sandbox attribute) to all possible values and just remove the allow-modals value.

The author for the implementation could then choose to add this back in (Codepen, Glitch, Codesandbox, etc. already do this).

Big websites like YouTube, Wistia, etc. do not have to change their embed codes.

Meanwhile big CMS'es, plugins, etc. can add checks to make sure the iframe doesn't have 'allow=modals' in their sandbox attribute in their constant battle to keep user input secure.

[Narbeh Minassian]

How did the conversation about alert/confirm specifically in iframes morph into the <dialog> element? If the general direction is to deprecate the alert/confirm all together and replace with <dialog> then this should be made clear and ample amount of time given for applications to make the necessary changes to catch up. This half-assed approach of focusing on iframes today then moving forward with all modal popups altogether in a couple years makes the pain last longer.

[Graham Huck]

A couple of things:
First:

Whatever concern you all have about the cross origin alert/confirm/prompt dialog boxes, what if instead of blocking alert/confirm/prompts for cross origin iframes, why not just make that native browser behavior only apply to the contents of the iframe (don't block the parent)? That is essentially what we web developers would have to end up implementing ourselves. Why do we as web developers have to take on the burden of making this functionality work correctly when we are just using the tools that the browser provides us?

Secondly:
Total count of usage of this feature is a terrible metric to go by on its own. Yeah, a lot of sites don't need to use cross origin iframes. You got us there. But the financial impact that this change will make is huge. Large institutions rely on this functionality to work when they have to have integrations with other institutions. This change is going to have serious impact on large legacy code bases that do these types of integrations that utilize cross origin iframes. Relying on UseCounter alone for determining what features to keep is a terrible way to make decisions.

[Michael Yingling]

Narbeh,

Boris is not wrong to be concerned, given the plan sto subset this for even NON-iFrame cases, per this comment:

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)

Source: https://groups.google.com/a/chromium.org/g/blink-dev/c/hTOXiBj3D6A/m/HTHCP5FsAgAJ

On Wed, Nov 3, 2021 at 12:39 AM Narbeh Minassian <nar...@gmail.com> wrote:

Boris,

It will work if it's the same origin. This thread is regarding cross-origin alert() and confirm() often used in prototyping environments or other systems that embed iframes and those iframes raise alert messages.

On Tue, Nov 2, 2021 at 11:23 PM Boris Milanovic <milano...@gmail.com> wrote:

Okay, so I am a beginner at learning JS, and I am using VSC (Code), with right extensions. Following the best tutorial, I came to the part where tutor wants to show an example of the script being loaded from the index file and outside with alert(1), from Dev Console. Before that, typing the actual message to people alert("message"); worked just okay.

Is this Chrome only removing due to???

Or?


Kind regards,
Boris Milanovic,
Certified System Administrator for IT Network Infrastructure