Primary eng (and PM) emails
Eng: carl...@chromium.org, mea...@chromium.org
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
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.
--
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.
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.
--
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.
--
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.
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.
Other dialogs: Yes, I believe onbeforeunload is already blocked for this case.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAABgKfW34qCM_dNsV8GVx6VxfXdFBtjAxKTt5R4Brzcj1EGY0A%40mail.gmail.com.
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.
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.
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.
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.
I did have a suggestion, which was if you could whitelist trusted domain names in the parent window.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMsakZNgtbmG%3DE7nvkbYjOsWgpTPQjAAvwQrtMpdtD9qkt6V4w%40mail.gmail.com.
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.
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.
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.
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.
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.
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.
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;
This change makes this attribute pointless now - https://html.spec.whatwg.org/multipage/origin.html#sandboxed-modals-flagWould a better short term strategy be to make this false by default rather than disable the behavior entirely?
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?
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:
The change was temporarily disabled in both Edge and Chrome in that case. Team response here:
/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.
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.
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.
--
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.
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.
Thanks Carl, this is tremendous news. Can you speak on what to do about historical / 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.
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:Twitter thread related:Only constructive feedback to give is not to do it.
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
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.
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)
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