Live data from Hacker News

Implement window.{alert, prompt, confirm} removal from cross-origin iframes

bugs.chromium.org

21–30 of 160 posts

Re: Implement window.{alert, prompt, confirm} removal from cross-origin iframes

#21
post #2

They've even eschewed the standard way to opt-in iframes to powerful, dangerous features like `alert` and `confirm` - you can't even `sandbox` the iframe to allow it. You have to enroll your website in a Chrome Origin Trial[0], which only lasts until December, and also requires you to create a Google account, agree to Google ToS, and you might be blessed with the ability for your perfectly-fine-before-Chromium-team-c…

> perfectly-fine-before-Chromium-team-came-along web app Sorry, I think you misspelt "years of tech debt on the brink of collapse, only held together with prayers and the liberty provided by cross-origin iframes to do whatever they want to the parent window".

But it works. And after, it wont.

Re: Implement window.{alert, prompt, confirm} removal from cross-origin iframes

#22
post #7

What's a legit use for this?

Examples from TFA:

* Web-based REPL or IDE environments, where the iframe is typically the primary user interaction space.

* Paid third-party website embedded into an internal website.

* Hosted JS content such as Kongregate games.

* Frames wrapping older webapps as part of an evolutionary uplift plan.

Re: Implement window.{alert, prompt, confirm} removal from cross-origin iframes

#23

This makes a lot of sense, and is (IMO) a really great thing to do for users. IMO Cross Origin iframe alert/prompt should only be allowable with CSP rules explicitly permitting the cross origin iframe in the first place (in allowlist capacity). The amount of abuse this has seen and will see is a blight, especially on the average user. HOWEVER What the hell, Chrome? This timeline for a change of this magnitude is INSA…

Switch to Mozilla? They are positive to this, and Webkit also. That is often the case, Chromium just has a faster turn-around then the others so usually are first to implement.

The discussion about this started a year ago with the individual browsers and WHATWG.

https://bugzilla.mozilla.org/show_bug.cgi?id=1624978

Re: Implement window.{alert, prompt, confirm} removal from cross-origin iframes

#24
post #2

They've even eschewed the standard way to opt-in iframes to powerful, dangerous features like `alert` and `confirm` - you can't even `sandbox` the iframe to allow it. You have to enroll your website in a Chrome Origin Trial[0], which only lasts until December, and also requires you to create a Google account, agree to Google ToS, and you might be blessed with the ability for your perfectly-fine-before-Chromium-team-c…

Who the hell is in charge over there, and what compels them to incessantly break the web? Google has a vested interest in doing so, and change is their weapon; it keeps control of the web in their hands when no other organisation has enough brute force to keep up with their changes.

In fairness, the constant change is because other organizations have the brute force to keep up. If everyone else gave up on a browser they would stop changing things.

Re: Implement window.{alert, prompt, confirm} removal from cross-origin iframes

#26
post #8

Earlier quoted context omitted.

Coping test seems to work fine in Chrome and Safari, so don't think Google broke anything in regards to text selection/copy/paste on the page.

Something's definitely misbehaving in Firefox on the page. Using a mouse to highlight text in a comment and then trying to move the highlight to the next paragraph, the selection jumps to the first paragraph as soon as the cursor leaves the `span` of each paragraph. From a quick look at the DOM, I'd bet dollars to donuts it's the weird combination of custom WebComponents and the #shadow-root stuff and other various m…

If you create a new Firefox profile alongside your usual one, and do not change any settings, can you reproduce the copy paste issue you’re seeing?

Re: Implement window.{alert, prompt, confirm} removal from cross-origin iframes

#27
post #2

They've even eschewed the standard way to opt-in iframes to powerful, dangerous features like `alert` and `confirm` - you can't even `sandbox` the iframe to allow it. You have to enroll your website in a Chrome Origin Trial[0], which only lasts until December, and also requires you to create a Google account, agree to Google ToS, and you might be blessed with the ability for your perfectly-fine-before-Chromium-team-c…

> perfectly-fine-before-Chromium-team-came-along web app Sorry, I think you misspelt "years of tech debt on the brink of collapse, only held together with prayers and the liberty provided by cross-origin iframes to do whatever they want to the parent window".

I'd encourage you to read some of the testimonials in the bug tracker - the applications this is breaking are not tech-debt-laden monstrosities, they're very simple examples like repl.it and educational coding websites where the IDE is hosted in an iframe and you can run your code in-browser. I can think of many more derelict features I'd have removed first if this was really about cleaning up code smells.

And regardless of whether you think `window.alert` is a giant pile of tech debt: "we don't break userspace" is a mantra that web browser teams would benefit to heed.

Re: Implement window.{alert, prompt, confirm} removal from cross-origin iframes

#28
post #8

Earlier quoted context omitted.

Coping test seems to work fine in Chrome and Safari, so don't think Google broke anything in regards to text selection/copy/paste on the page.

Something's definitely misbehaving in Firefox on the page. Using a mouse to highlight text in a comment and then trying to move the highlight to the next paragraph, the selection jumps to the first paragraph as soon as the cursor leaves the `span` of each paragraph. From a quick look at the DOM, I'd bet dollars to donuts it's the weird combination of custom WebComponents and the #shadow-root stuff and other various m…

The text isn't rendering at all in Safari/Mac. (Momentarily too lazy/tired to find out why. 2am here.)

Re: Implement window.{alert, prompt, confirm} removal from cross-origin iframes

#29
Here's waiting for when we finally rip out document.write because it's one of the most damaging functions to have been kept on life support "because we don't remove things from JS, it would break the internet". Except of course for all those times we already did by not "removing it from the spec", just either removing support in all browsers, or by changing the security policies so that "the code is still accepted" it just throws security errors and won't actually run.

Re: Implement window.{alert, prompt, confirm} removal from cross-origin iframes

#30
post #14
post #7

What's a legit use for this?

repl.it which uses an iframe and it might be good to showcase prompt

It'd hardly be even minor effort for the repl.it folks to just include a file in their sandbox loader that gives folks a normal, modern modal when some JS contains prompt() or confirm().

Remember: it's not about whether it's useful, it's about whether there isn't a better way to do it, because it's useful. In this case: yeah, absolute. There are way better ways.

Post reply on HN