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-came-along web app to keep working.
Who the hell is in charge over there, and what compels them to incessantly break the web?
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.
Idk why everyone jumps to these paranoid conspiracy theories - alert() box to trick people has been a thing for decades, and its super rare for it to be used legitly outside of debugging.
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.
Alert is pure garbage and should not have made it past the 90s. Also, basic auth popups need to go too. Not sure why browsers would ever make those focus stealing in the first place. There should not be one single way for a web application to steal focus. The current workaround is to download a buggy ad blocker (last time I used chrome, just like firefox it has no way to turn popups off).
Edit: I just remembered alert no longer steals focus on modern browsers (IIRC). But basic auth still does (at least on my 50 year old fork of firefox).
and both Firefox and Webkit were in favour of the spec change.
They could oppose, but then Google would just spread propaganda about how their browsers are "less secure" or whatever. There's really no choice for other browsers at this point.
From the point of view of neutrality, the whole "origin trial" thing is seriously messed up. You are effectively having to ask for permission from one megacorp to treat your site differently from others in its browser.
> 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.
Given their current market share, they have no incentive to behave otherwise. They will do what they wish. And since it’s Google paying the bills, if it doesn’t harm Google’s business then it’s not a problem for them.
This is peak Chrome; what seems to be a reasonably good idea that's hampered because it was pushed out thoughtlessly without putting any serious effort into notifying the people affected or making sure that nothing else breaks, or making sure that it thoroughly solves the problem. The product owners at Chrome are smart, but they're careless and constantly break the web because they don't seem to have enough of a sense of gravitas or caution about what they're doing.
From what I can tell, this isn't a terrible change -- at least at first glance, it seems to me like we should probably remove prompts/alerts eventually. Just... competently remove them, without breaking people's sites and then shaming them for not keeping up with Chrome's official blog.
I also love the juxtaposition here between how careless Chrome is about things like web audio/URLs/extensions, and how careful they've been recently about privacy and anti-tracking proposals. Heaven forbid that we block 3rd-party cookies by default without first rolling out 3 different proposals[0][1][2] and having an extensive very public debate about how to replace them. Breaking web audio for nearly every interactive site on the web (including timers on Google's own search page) is one thing, but breaking ads? That would be irresponsible.
Honestly, what is the right way to "notify the people affected" for changes like this, apart from publishing them to their mailing list. There is no centralised place for these sorts of things, apart from each developer's mailing lists, or the standards mailing lists.
I'm a web developer and I've never paid attention to the blink-dev mailing list, but perhaps I should more?
1. Blog posts on a real big corporate blog, not on some mailing list no one reads.
2. A few months later: Warnings in the dev tools.
3. A few months after 2, at least a year after 1: Warnings on websites using the feature, for this feature it would probably have made sense to make a yellow or red ex through the padlock.
4. A year after 3, at least 2 years after 1, maybe actually consider actually removing it.
It's folly to think that all important websites are actually maintained, it's certainly not the case that they can all roll out updates within months (think internal websites from vendored software that is rarely updated), and there's no reason to rush. I'd consider what I outlined here to be a very aggressive rollout schedule.
Better than removing it entirely, would be to permanently put in a version of the feature that is still functional but avoids the issues with it. E.g. change the alert dialog to something hideous that clearly explains "this might not be from where it claims it is", but don't entirely break backwards compatibility.
> . The product owners at Chrome are smart, but they're careless and constantly break the web because they don't seem to have enough of a sense of gravitas or caution about what they're doing.
Now imagine when Chrome has no competition whatsoever anymore, which will eventually happen. Google will control the web, at the very least on PC and Android, which is like 90% of the audience or something. They will take terrible, unilateral decisions because of their monopoly and "standards" will be as good as dead.
Yes, and yet people were still caught off guard. Which is in some ways even worse to me, because what were they doing for those 2 years?
When someone maintains the largest browser in the world, and almost every public website in the entire world relies on maintaining compatibility with that browser, then the standards for reaching out about breaking changes are a lot higher. The amount of time is only one aspect of this, the other is making sure that people actually understand the change is happening.
That is of course, a wildly difficult problem. But while I'm sympathetic to the sheer difficulty of getting people's attention at that scale, I also feel that nobody is forcing the Chrome team to own the entire web. If they're going to be in that position, then they need to act like they're in that position.
At the very least, what internal studies were done over those 2 years to check and see which sites would be broken? How did they miss services like Repl.it during those studies?
My frustration with the Chrome dev team is that they handle feature changes and testing as if they're managing some kind of niche Open Source project, when in reality they are maintaining one of the most important pieces of software in the world. They're not Arch, they're not in a position where they can reasonably dismiss people who get caught by breaking changes because they aren't following the release notes. At the scale of Chrome it becomes their job to make sure website maintainers know about future changes and that nothing breaks.
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 INSANE. The opt-out process is INSANE. Forcing developers to opt into a TOS just to address YOUR changes is INSANE. This is such a small issue to be flexing so massively on, more evidence that we need users (and embedded browsers!) to switch to Mozilla
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.
From the Google discussion on this change back in March, located here [1].....
> "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 first comment response reads.....
> "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 next comment agrees.....
> "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."
So here we see on full display Google acknowledge that they have enough market share to ignore other vendors, awknoledge that it is not in the web's best interest to do so, and yet somehow that part of the discussion was allowed to completely die out.
So yeah, switch to Mozilla. The conversation they had on the topic was much more aligned with what I want to see from my supply chain than the conversation I saw over at Google.
Microsoft Edge released 92.0.902.62 today which now re-allows the dialogs in cross domain iFrames. We are suggesting that our user base moves from Chrome to Edge.
What's insane about the timeline? They started talking about this a year and a half ago, approved it winter this year, and had it out in beta in May. How much longer should they take?
What's insane about the opt-out process? It seems very easy to me. I was able to generate an opt-out token in about three minutes for example.com. I'm a backend developer so I don't know too much about web servers, but I imagine it would take another ten minutes for an experienced person to make a commit that adds the reverse origin trial header to the default headers for their servers, possibly as a cherry pick to their existing release.
What's weird about the TOS? It's just the Google standard TOS, which you have to abide by using google.com or any other Google web property. 99.99% of possible interested developers are already covered by it, right? There is no way Google could offer you a service like this, or even documentation for it, without some kind of terms of service.
R.e. switching to Firefox, sure, browser diversity is great, but that won't affect anyone who uses your web site. They'll still be on Chrome or Safari, so this type of thing is still going to be something you have to handle. And anyway I guess that Mozilla will probably remove this option before too long as well.
“Yes,” said Arthur, “yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.”
There's an ongoing conversation that has lasted about four years on https://github.com/whatwg/html/issues/2791 regarding whether or not browsers should implement `<include>`, (think client-side SSI, php's `include`, ngInclude, or similar fragment import functionalities from different software) which basically comes down to the four(?) editors (Mozilla, Microsoft, Google, Apple) not liking it.
I noted that it's the most commented on issue in the whatwg/html discussion space, and for good reason.
It's just tiring to read through discussions where a small number of people control web technologies. Oh well.
> four(?) editors (Mozilla, Microsoft, Google, Apple) not liking it. [...] a small number of people control web technologies
Isn’t this expected? The other people can say whatever, but the final decisions will be made by people committing the code into major browsers. If they say “no, we won’t implement this”, what can others do?
> 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.
Most sites aren't even gonna find out about it in a two week period, let alone be able to fix it.
(Side note: Google has broken the text selection on this page, at least in Firefox. Didn't try in Chrome. Copy/pasting a paragraph was a trial.)
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 markup excess that they just didn't bother to test with Firefox. Whether it's a bug with Firefox itself and how these elements are handled, I guess would need some investigation. But if it were my web app, I'd probably just fix it instead of blaming the browser.
Regarding adding it to the sandbox attribute (which was my suggestion - I'm the guy that was quoted earlier in this issue, as well as the one raising a bit of a stink in whatwg/html) or to the allow attribute (which I'm not super familiar with) -- there seems to be some bigger ideological push going on behind the scenes with members of the WHATWG to push for the removal of any blocking methods in JavaScript. To quote from https://github.com/whatwg/html/issues/6897 :
> _In general all of the simple dialogs (alert(), prompt(), confirm(), and beforeunload) are deprecated and being removed slowly but surely from the web platform. They use trusted browser UI, which opens them up to abuse, and they block the event loop, which is not in keeping with the web's cooperative task model_
<opinion>
In my opinion, the issue potential misuse of dialogs, which was long ago addressed by showing the source of the dialog in the dialog itself, has been resurrected as means to push forward the removal of any and all blocking calls from JavaScript -- not just in this case. Removing it from cross-origin iframes, I believe, is more meant to establish a precedent to justify the removal of these functions from the entire spec.
</opinion>
Haha i love the tone deaf, dontgiveashit responses of the chromium team, just trolling devs:
[... Dev engages in paragraphs long rant detailing their intricate use case and why it's so essential not realizing the chrome team doesn't give a shit...]
We implemented an origin trial to temporarily opt out from the blocking. Would this solve your concerns while you migrate your app? If so, please see ...
But if it doesn't solve your concerns, guess yer fresh outta luck there, slick.
but more practically I think the suggestions of developers for a sandbox attribute is a great idea and I don't understand the purpose of this change nor how it seems the community wasn't consulted. But I love how when the pushback from devs happens, it's like because the chrome team failed to anticipate these various valid use cases, they're not even going to acknowledge the dev sentiment as a real thing... Pretty weird dynamic obviously they don't care about consultation I wonder what really drives the development mission?
But I also get the point of view of the chrome Dev team if it's something like they just choose to not deal with so much feedback from people. I do the same thing that's why I disable issues on my popular open source projects....
The difference is that you - presumably - aren't the de facto steward of one of the most important open communication platforms on the planet that literal nation states rely on to function correctly, in addition to the general public.
Honestly I always thought it was weird that popping up a native browser dialog was even a feature offered by browser JavaScript APIs in the first place.
Isn't the DOM the API for controlling anything visual?
If that feature never existed and someone proposed it today there's no way it would get added.
Readit News
Who the hell is in charge over there, and what compels them to incessantly break the web?
[0]: https://developer.chrome.com/origintrials/#/register_trial/2...
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.
Alert is pure garbage and should not have made it past the 90s. Also, basic auth popups need to go too. Not sure why browsers would ever make those focus stealing in the first place. There should not be one single way for a web application to steal focus. The current workaround is to download a buggy ad blocker (last time I used chrome, just like firefox it has no way to turn popups off).
Edit: I just remembered alert no longer steals focus on modern browsers (IIRC). But basic auth still does (at least on my 50 year old fork of firefox).
Well, to be fair, they went to the standards body and proposed it, and both Firefox and Webkit were in favour of the spec change.
They could oppose, but then Google would just spread propaganda about how their browsers are "less secure" or whatever. There's really no choice for other browsers at this point.
From the point of view of neutrality, the whole "origin trial" thing is seriously messed up. You are effectively having to ask for permission from one megacorp to treat your site differently from others in its browser.
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".
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.
Deleted Comment
Deleted Comment
What do you mean, the linked article is just a blank white page...
From what I can tell, this isn't a terrible change -- at least at first glance, it seems to me like we should probably remove prompts/alerts eventually. Just... competently remove them, without breaking people's sites and then shaming them for not keeping up with Chrome's official blog.
I also love the juxtaposition here between how careless Chrome is about things like web audio/URLs/extensions, and how careful they've been recently about privacy and anti-tracking proposals. Heaven forbid that we block 3rd-party cookies by default without first rolling out 3 different proposals[0][1][2] and having an extensive very public debate about how to replace them. Breaking web audio for nearly every interactive site on the web (including timers on Google's own search page) is one thing, but breaking ads? That would be irresponsible.
[0]: https://developer.chrome.com/docs/privacy-sandbox/first-part...
[1]: https://developer.chrome.com/docs/privacy-sandbox/floc/
[2]: https://developer.chrome.com/docs/privacy-sandbox/attributio...
Honestly, what is the right way to "notify the people affected" for changes like this, apart from publishing them to their mailing list. There is no centralised place for these sorts of things, apart from each developer's mailing lists, or the standards mailing lists.
I'm a web developer and I've never paid attention to the blink-dev mailing list, but perhaps I should more?
2. A few months later: Warnings in the dev tools.
3. A few months after 2, at least a year after 1: Warnings on websites using the feature, for this feature it would probably have made sense to make a yellow or red ex through the padlock.
4. A year after 3, at least 2 years after 1, maybe actually consider actually removing it.
It's folly to think that all important websites are actually maintained, it's certainly not the case that they can all roll out updates within months (think internal websites from vendored software that is rarely updated), and there's no reason to rush. I'd consider what I outlined here to be a very aggressive rollout schedule.
Better than removing it entirely, would be to permanently put in a version of the feature that is still functional but avoids the issues with it. E.g. change the alert dialog to something hideous that clearly explains "this might not be from where it claims it is", but don't entirely break backwards compatibility.
Now imagine when Chrome has no competition whatsoever anymore, which will eventually happen. Google will control the web, at the very least on PC and Android, which is like 90% of the audience or something. They will take terrible, unilateral decisions because of their monopoly and "standards" will be as good as dead.
Deleted Comment
When someone maintains the largest browser in the world, and almost every public website in the entire world relies on maintaining compatibility with that browser, then the standards for reaching out about breaking changes are a lot higher. The amount of time is only one aspect of this, the other is making sure that people actually understand the change is happening.
That is of course, a wildly difficult problem. But while I'm sympathetic to the sheer difficulty of getting people's attention at that scale, I also feel that nobody is forcing the Chrome team to own the entire web. If they're going to be in that position, then they need to act like they're in that position.
At the very least, what internal studies were done over those 2 years to check and see which sites would be broken? How did they miss services like Repl.it during those studies?
My frustration with the Chrome dev team is that they handle feature changes and testing as if they're managing some kind of niche Open Source project, when in reality they are maintaining one of the most important pieces of software in the world. They're not Arch, they're not in a position where they can reasonably dismiss people who get caught by breaking changes because they aren't following the release notes. At the scale of Chrome it becomes their job to make sure website maintainers know about future changes and that nothing breaks.
HOWEVER
What the hell, Chrome? This timeline for a change of this magnitude is INSANE. The opt-out process is INSANE. Forcing developers to opt into a TOS just to address YOUR changes is INSANE. This is such a small issue to be flexing so massively on, more evidence that we need users (and embedded browsers!) to switch to Mozilla
The discussion about this started a year ago with the individual browsers and WHATWG.
https://bugzilla.mozilla.org/show_bug.cgi?id=1624978
> "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 first comment response reads.....
> "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 next comment agrees.....
> "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."
So here we see on full display Google acknowledge that they have enough market share to ignore other vendors, awknoledge that it is not in the web's best interest to do so, and yet somehow that part of the discussion was allowed to completely die out.
So yeah, switch to Mozilla. The conversation they had on the topic was much more aligned with what I want to see from my supply chain than the conversation I saw over at Google.
[1] https://groups.google.com/a/chromium.org/g/blink-dev/c/hTOXi...
Although it might be time to bring back those stupid "Best viewed in" banners, because everything old is new again.
What's insane about the opt-out process? It seems very easy to me. I was able to generate an opt-out token in about three minutes for example.com. I'm a backend developer so I don't know too much about web servers, but I imagine it would take another ten minutes for an experienced person to make a commit that adds the reverse origin trial header to the default headers for their servers, possibly as a cherry pick to their existing release.
What's weird about the TOS? It's just the Google standard TOS, which you have to abide by using google.com or any other Google web property. 99.99% of possible interested developers are already covered by it, right? There is no way Google could offer you a service like this, or even documentation for it, without some kind of terms of service.
R.e. switching to Firefox, sure, browser diversity is great, but that won't affect anyone who uses your web site. They'll still be on Chrome or Safari, so this type of thing is still going to be something you have to handle. And anyway I guess that Mozilla will probably remove this option before too long as well.
“Yes,” said Arthur, “yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.”
When did my web site become a Google property?
My website has nothing to do with Google. Why should I have to agree to a contract with Google just so people can use my site?
Would you be fine with Facebook also forcing agreement with a contract just to view a completely third party website in a web browser?
Deleted Comment
I noted that it's the most commented on issue in the whatwg/html discussion space, and for good reason.
It's just tiring to read through discussions where a small number of people control web technologies. Oh well.
Isn’t this expected? The other people can say whatever, but the final decisions will be made by people committing the code into major browsers. If they say “no, we won’t implement this”, what can others do?
Most sites aren't even gonna find out about it in a two week period, let alone be able to fix it.
(Side note: Google has broken the text selection on this page, at least in Firefox. Didn't try in Chrome. Copy/pasting a paragraph was a trial.)
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 markup excess that they just didn't bother to test with Firefox. Whether it's a bug with Firefox itself and how these elements are handled, I guess would need some investigation. But if it were my web app, I'd probably just fix it instead of blaming the browser.
Screen capture: https://imgur.com/RmoSZRB
https://bugs.chromium.org/p/chromium/issues/detail?id=106508...
---
Regarding adding it to the sandbox attribute (which was my suggestion - I'm the guy that was quoted earlier in this issue, as well as the one raising a bit of a stink in whatwg/html) or to the allow attribute (which I'm not super familiar with) -- there seems to be some bigger ideological push going on behind the scenes with members of the WHATWG to push for the removal of any blocking methods in JavaScript. To quote from https://github.com/whatwg/html/issues/6897 :
> _In general all of the simple dialogs (alert(), prompt(), confirm(), and beforeunload) are deprecated and being removed slowly but surely from the web platform. They use trusted browser UI, which opens them up to abuse, and they block the event loop, which is not in keeping with the web's cooperative task model_
<opinion> In my opinion, the issue potential misuse of dialogs, which was long ago addressed by showing the source of the dialog in the dialog itself, has been resurrected as means to push forward the removal of any and all blocking calls from JavaScript -- not just in this case. Removing it from cross-origin iframes, I believe, is more meant to establish a precedent to justify the removal of these functions from the entire spec. </opinion>
[... Dev engages in paragraphs long rant detailing their intricate use case and why it's so essential not realizing the chrome team doesn't give a shit...]
We implemented an origin trial to temporarily opt out from the blocking. Would this solve your concerns while you migrate your app? If so, please see ...
But if it doesn't solve your concerns, guess yer fresh outta luck there, slick.
but more practically I think the suggestions of developers for a sandbox attribute is a great idea and I don't understand the purpose of this change nor how it seems the community wasn't consulted. But I love how when the pushback from devs happens, it's like because the chrome team failed to anticipate these various valid use cases, they're not even going to acknowledge the dev sentiment as a real thing... Pretty weird dynamic obviously they don't care about consultation I wonder what really drives the development mission?
* Position and clip the alert box within bounds of the frame, so that it doesn't display anything that the frame couldn't do itself.
* Don't make framed alerts steal focus, so that it also loses special behavior.
* Ideally, provide some replacement like `await alert()` so that authors can migrate with minimal changes.
Isn't the DOM the API for controlling anything visual?
If that feature never existed and someone proposed it today there's no way it would get added.