Implement window.{alert, prompt, confirm} removal from cross-origin iframes(bugs.chromium.org)
bugs.chromium.org
Implement window.{alert, prompt, confirm} removal from cross-origin iframes
https://bugs.chromium.org/p/chromium/issues/detail?id=1065085
159 comments
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.
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.
How often is it that you have a malicious iframe on your website being used to trick people though?
Why only remove it from iframe and not the entire browser if that is the concern?
Why was this concern not alleviated with better UI for the standard alert dialogs?
Alert dialogs and prompts are huge for accessibility - they're genuinely one of the best ways to get a screenreader's attention and have the user interact immediately with something. They are great for the web. They provide a standard interface and I think we should use them more often.
To me, this is Chromium team doing one of two things: (1) Trying to fix a security concern and instead of improving the UI so it's clear where the dialog is coming from, being lazy and just turning the feature off, or (2) Boiling the frog: remove dialogs from iframe, wait a while, then remove them from top-most with the rationale that "hey, they're already not supported in iframes" because they think dialogs are so Web 1.0
I don't like it either way. Just let me opt-in via `sandbox` like I do for other iframe features. Honestly, even that's rude to make website developers have to do, but at least we're not left high and dry.
I'll be irrationally angry if this all boils down to some UXD thinking that alert dialogs are "ugly" or something.
Why only remove it from iframe and not the entire browser if that is the concern?
Why was this concern not alleviated with better UI for the standard alert dialogs?
Alert dialogs and prompts are huge for accessibility - they're genuinely one of the best ways to get a screenreader's attention and have the user interact immediately with something. They are great for the web. They provide a standard interface and I think we should use them more often.
To me, this is Chromium team doing one of two things: (1) Trying to fix a security concern and instead of improving the UI so it's clear where the dialog is coming from, being lazy and just turning the feature off, or (2) Boiling the frog: remove dialogs from iframe, wait a while, then remove them from top-most with the rationale that "hey, they're already not supported in iframes" because they think dialogs are so Web 1.0
I don't like it either way. Just let me opt-in via `sandbox` like I do for other iframe features. Honestly, even that's rude to make website developers have to do, but at least we're not left high and dry.
I'll be irrationally angry if this all boils down to some UXD thinking that alert dialogs are "ugly" or something.
> How often is it that you have a malicious iframe on your website being used to trick people though?
Definitely more often than whatever hacky edge case websites relies on this behavior.
Definitely more often than whatever hacky edge case websites relies on this behavior.
Such as a gaming website that hosts arbitrary JS games written to fit within a particular size limit? Code sample web IDEs that are designed to teach people how to code quickly? An iframed rich text editor? An embedded reporting widget that wants to remind users to save their changes before they navigate away on the parent page? An enterprise application that's using the strangler pattern to wall off greyfield parts of their application and those parts were written in 2004?
These are not common-use-cases-for-average-websites-on-the-net, but for web _apps_ where third-party `iframe` is the quickest way to real isolation between divergent code, iframes are pretty common. And `alert`, `confirm`, and `prompt` are not common in such code either, but when they are used they're often used in code paths that expect blocking behavior and are therefore definitely not amenable to alterations.
And the fact of the matter is that as the developer of a web application _I can still get this blocking behavior_. "All you need to do is have the parent and the child cooperate by sharing a TypedArray between the origins and use `Atomics.wait`" [1]. If by having the parent and the child cooperate I can get the blocking behavior, why not allow me to do it simply with a `sandbox` attribute, rather than having me publish a `@backcompat/alert` NPM module that both sides can pull in to polyfill a functioning `window.alert`?
[1]: https://twitter.com/KekitoF/status/1420220292429926400
These are not common-use-cases-for-average-websites-on-the-net, but for web _apps_ where third-party `iframe` is the quickest way to real isolation between divergent code, iframes are pretty common. And `alert`, `confirm`, and `prompt` are not common in such code either, but when they are used they're often used in code paths that expect blocking behavior and are therefore definitely not amenable to alterations.
And the fact of the matter is that as the developer of a web application _I can still get this blocking behavior_. "All you need to do is have the parent and the child cooperate by sharing a TypedArray between the origins and use `Atomics.wait`" [1]. If by having the parent and the child cooperate I can get the blocking behavior, why not allow me to do it simply with a `sandbox` attribute, rather than having me publish a `@backcompat/alert` NPM module that both sides can pull in to polyfill a functioning `window.alert`?
[1]: https://twitter.com/KekitoF/status/1420220292429926400
The only time I've seen alert boxes used is in XSS demos and attack ads that break the sandbox to spawn 1000 popups that they say the FBI is blackmailing me, and that I should send 0.5 bitcoin to this address now.
> How often is it that you have a malicious iframe on your website being used to trick people though?
This is one of the most common phishing vectors.
This is one of the most common phishing vectors.
When chrome was new and fresh... they fixed the alert dialog... making it possible to escape the tab that popped the alert and even close it... this was real progress. Kind of see their point with iframe but feel it was rash to assume you can just disable a feature. Everything should be permission dialogs... IMO... So then you open a new web app from Fancy CRM or productivity tool and you get a dozen permission dialogs for that domain... fine... do it once and move on... instead you login to Fancy CRM or productivity tool and it's broken now...
[deleted]
plenty of ads are malicious, and if you want to use an adbroker its super hard to control or address
> its super rare for it to be used legitly outside of debugging
Simply false. This change broke several of my companies apps, and it broke Salesforce, and God knows what else. And it's not just a layout problem; it's material behavior which changed.
Simply false. This change broke several of my companies apps, and it broke Salesforce, and God knows what else. And it's not just a layout problem; it's material behavior which changed.
> it broke Salesforce
take 1: Salesforce is already a broken heap of fertilizer
take 2: Hmm, didn't Google try and fail to acquire Salesforce?
take 1: Salesforce is already a broken heap of fertilizer
take 2: Hmm, didn't Google try and fail to acquire Salesforce?
It's not paranoid conspiracy theory, it's good ol' "fire and motion" - https://www.joelonsoftware.com/2002/01/06/fire-and-motion/. Google is absolutely doing this with the web. Everyone else is too busy either trying to catch up with Chrome or react to unending stream of Google's proposed changes to web standards - which keeps them pinned down, and gives Google the freedom of movement, allowing them to direct the evolution of the web as a platform.
That's the not the real complaint. The real issue is this: Opting out requires signing up with Google and become a customer of theirs: https://developer.chrome.com/origintrials/#/register_trial/2...
Who uses alert for debugging anymore?
And I don't know why you have to smear beliefs that differ from yours and the people holding them as "paranoid conspiracy." You can present your case without name calling (if you have one).
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.
The entire web does this, not just Google.
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).
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).
I would like to point out that stealing focus is part of the browser implementation. I don't think anyone would object to less stuff (if anything) stealing focus.
If the problem is "this functionality steals focus", how about making it not steal focus rather than removing it entirely on short notice? Why don't the Chrome developers focus on fixing their browser?
If the problem is "this functionality steals focus", how about making it not steal focus rather than removing it entirely on short notice? Why don't the Chrome developers focus on fixing their browser?
Ugly and limiting as they may be, I find standard UI widgets quite easy to leverage as a dev and as a user.
Though they may need to move beyond the line of death to mitigate spoofing.
Though they may need to move beyond the line of death to mitigate spoofing.
basic auth is super useful for protecting staging sites, however.
>(at least on my 50 year old fork of firefox).
Since you're obviously from the future, can you give me tips on some stocks or sporting events to "invest"?
Since you're obviously from the future, can you give me tips on some stocks or sporting events to "invest"?
That's a way of saying "decades old".
Not to count years literally.
Not to count years literally.
[deleted]
> Who the hell is in charge over there, and what compels them to incessantly break the web?
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.
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.
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.
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.
To try and restate this, in case I misunderstand:
You believe that Apple and Mozilla are rubber-stamping anything Google asks for because they’re afraid of a Google marketing campaign.
Have I accurately represented your beliefs?
You believe that Apple and Mozilla are rubber-stamping anything Google asks for because they’re afraid of a Google marketing campaign.
Have I accurately represented your beliefs?
The situation is not so clear with Apple (but there is some evidence that it puts up at least some opposition: see hit-pieces like https://news.ycombinator.com/item?id=27968394 and note all the pro-Chrome/Google opinions there...) but Mozilla is funded by Google.
...and regardless of whether you're using Chrome, the immense power of Google's marketing abilities cannot be overstated. It is an ad company, after all. (If you're using Chrome, it's self-explanatory; if you're not, you should notice just how much you get "recommended" to.)
...and regardless of whether you're using Chrome, the immense power of Google's marketing abilities cannot be overstated. It is an ad company, after all. (If you're using Chrome, it's self-explanatory; if you're not, you should notice just how much you get "recommended" to.)
> see hit-pieces like https://news.ycombinator.com/item?id=27968394 and note all the pro-Chrome/Google opinions there...)
Hit pieces? It's extremely plausible the people are fed up by Apple's refusal to implement basic features and fix show stopping bugs in their force-fed browser to protect their monopoly and money that comes in (30% cut of App Store sales).
Hit pieces? It's extremely plausible the people are fed up by Apple's refusal to implement basic features and fix show stopping bugs in their force-fed browser to protect their monopoly and money that comes in (30% cut of App Store sales).
Definitely report what you perceive as astroturfing to the mods using the footer Contact link; they will want to know more.
[deleted]
Firefox and Webkit are always rejecting proposals from Chrome, or the other way around or whatever.
There's just no evidence that points to what you're suggesting.
There's just no evidence that points to what you're suggesting.
> 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".
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.
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.
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.
It is a mantra that web browser teams heed. That's why the HTML living standard is the absolute mess it is.
"We don't break userspace" is not an absolute rule, and has plenty of exceptions in practice, including security and things where no legitimate use case has been identified.
"We don't break userspace" is not an absolute rule, and has plenty of exceptions in practice, including security and things where no legitimate use case has been identified.
Linus Torvald coined the phrase "We don't break userspace" and he has been less than nice to people who seek to undermine compatibility in the name of security:
http://lkml.iu.edu/hypermail/linux/kernel/1711.2/01701.html
I understand where the phrase is from. I am saying the rule is not as absolute as you think it is. Linus himself breaks userspace on occasion where it is warranted.
Interestingly enough, the kernel has broken my (userspace) programs at two different occasions. Both times were knowing and intentional, as in the commit messages acknowledged that they were making breaking changes, and they weren't because of security either.
But these were only two occasions over ~10 years, so it's not too big of a deal.
But these were only two occasions over ~10 years, so it's not too big of a deal.
[deleted]
[deleted]
[deleted]
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.
>Who the hell is in charge over there, and what compels them to incessantly break the web?
What do you mean, the linked article is just a blank white page...
What do you mean, the linked article is just a blank white page...
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.
[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...
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...
So over a year ago they did publish their "Intent to remove" for this https://groups.google.com/a/chromium.org/g/blink-dev/c/hTOXi...
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?
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.
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 more general version of this is
1. Tell people who read the news (blog)
2. Tell people who make the thing you're breaking (devtools)
3. Tell users, but without breaking it since it's not something they can solve (padlock)
4. Maybe finally break it
1. Tell people who read the news (blog)
2. Tell people who make the thing you're breaking (devtools)
3. Tell users, but without breaking it since it's not something they can solve (padlock)
4. Maybe finally break it
I've removed some feature from the web in Chrome after a long deprecation phase with warnings in devtools, proper announcements in ALL the relevant mailing lists and release notes. Still, many major websites broke as they failed to implement the very simple required changes in their products.
Did they break in Chrome? No, we landed the change at a later date than announced. But Firefox did the same removal and it landed to stable a few weeks before Chrome. They also advertised for the removal extensively and were hit by all the "Major site X and Y are broken" bugs unfortunately. A couple days later, everything was fixed though, when Chrome's side of thing reached stable, no sites were really impacted.
The replacement API had been available for many years before, people used the old non-standard and deprecated way still.
So no, websites owner will not be proactive and fix their products no matter what you do unless they break. We do our best to be upfront with the changes, but both sides have to be willing to communicate for it to happen.
Did they break in Chrome? No, we landed the change at a later date than announced. But Firefox did the same removal and it landed to stable a few weeks before Chrome. They also advertised for the removal extensively and were hit by all the "Major site X and Y are broken" bugs unfortunately. A couple days later, everything was fixed though, when Chrome's side of thing reached stable, no sites were really impacted.
The replacement API had been available for many years before, people used the old non-standard and deprecated way still.
So no, websites owner will not be proactive and fix their products no matter what you do unless they break. We do our best to be upfront with the changes, but both sides have to be willing to communicate for it to happen.
> We do our best to be upfront with the changes, but both sides have to be willing to communicate for it to happen.
What processes did Chrome follow in this case to identify sites that might break, and did it reach out directly to any of the people who would be affected?
I'm seeing comments from people like Chris Coyier that they were caught off guard with this change: https://twitr.gq/chriscoyier/status/1420027533005836298#m
If the creator of CodePen didn't realize this was coming, and if it didn't register to anyone in charge of this change that he should be contacted about it and included in the discussion before late July, then to me it really doesn't seem like the communication breakdown here is happening because of website developers.
What processes did Chrome follow in this case to identify sites that might break, and did it reach out directly to any of the people who would be affected?
I'm seeing comments from people like Chris Coyier that they were caught off guard with this change: https://twitr.gq/chriscoyier/status/1420027533005836298#m
If the creator of CodePen didn't realize this was coming, and if it didn't register to anyone in charge of this change that he should be contacted about it and included in the discussion before late July, then to me it really doesn't seem like the communication breakdown here is happening because of website developers.
There are archives you can sample to measure the impact of a change to some degree. We can use them to have an estimation of how common some patterns are. It's tricky to query so it may not work for advanced use cases or identify cross origin issues.
And it's not possible to reach out directly to those people. We can't just send deprecation notices to random contact emails (if there's any) on websites. We can't just open a "support request" to L1 customer support of websites telling them their site might not work soon. We're not going to send dead-tree mail to addresses listed on websites either.
If you want to support specific browsers, as part of your ongoing maintenance, you should test your site with canary and beta versions of browsers to catch issues before they go live at a minimum. You can also read the relevant mailing lists or blog posts for the major browsers to have an idea of the direction they're taking.
Chrome 91 went stable July 15. But the first beta was April 22. The change was probably in Canary before that as well. Quite a long time to catch issues with the right automation.
Personally, I wouldn't want to have to read the mailing lists and other articles. I would want a dashboard that tells me everything is tested and working fine automatically. And when it doesn't, I know I have many months to fix the issue before it hits stable and find the relevant documentation about the changes that might be causing the issues. Or just open an issue to the browsers, sometimes people are using APIs in very unexpected ways, or you know, a bug sneaked in despite the testing we have in place.
And it's not possible to reach out directly to those people. We can't just send deprecation notices to random contact emails (if there's any) on websites. We can't just open a "support request" to L1 customer support of websites telling them their site might not work soon. We're not going to send dead-tree mail to addresses listed on websites either.
If you want to support specific browsers, as part of your ongoing maintenance, you should test your site with canary and beta versions of browsers to catch issues before they go live at a minimum. You can also read the relevant mailing lists or blog posts for the major browsers to have an idea of the direction they're taking.
Chrome 91 went stable July 15. But the first beta was April 22. The change was probably in Canary before that as well. Quite a long time to catch issues with the right automation.
Personally, I wouldn't want to have to read the mailing lists and other articles. I would want a dashboard that tells me everything is tested and working fine automatically. And when it doesn't, I know I have many months to fix the issue before it hits stable and find the relevant documentation about the changes that might be causing the issues. Or just open an issue to the browsers, sometimes people are using APIs in very unexpected ways, or you know, a bug sneaked in despite the testing we have in place.
> And it's not possible to reach out directly to those people. We can't just send deprecation notices to random contact emails (if there's any) on websites.
To be clear, we're talking about Chris Coyier right now. The Chrome team doesn't have any way to contact him? The team had to know that REPLs would be impacted by this, right?
You can blame people for not having the right automation and dev tools lined up and for not reading the right blogs, but it still seems to me like this is covering up the fact that the Chrome team does not view it as their job to reach out to web developers or put serious effort into marketing changes. If Chris didn't know about these changes, then I seriously doubt that the Chrome team was getting any kind of a representative sample of developer feedback during this process.
> Personally, I wouldn't want to have to read the mailing lists and other articles. I would want a dashboard that tells me everything is tested and working fine automatically.
What view of the web does the Chrome team have if they think the majority of site operators have this kind of testing setup running? It just feels so ridiculously out of touch with the reality of where web developers congregate and how news gets disseminated. I know it's a difficult problem, but the responsibility of Chrome is to work with the web community as it exists, not as the professional fully-automated community they'd like it to be.
Chrome couldn't send out some Twitter DMs? Chrome team couldn't post a heads up to HN? Any effort to post anything to the popular web dev communities on Reddit? Did the team reach out to any any popular bloggers or members of the community to ask them to spread the word? When the Chrome team is making changes to the dominant browser for what is (imo) the most important platform on the planet, it just is not enough to say "we put it in the mailing list, and you weren't testing well enough." The expectations for the Chrome team here are higher, because Chrome matters more than other products.
Yes, developers need to meet Chrome halfway on communication, but frankly, Chrome is not coming halfway right now to meet us. It should not have been a surprise to some of the biggest REPL sites on the web that their products were about to break. I don't know what to say about this, I'm not trying to be mean, but if the Chrome team's perspective is that developer communication isn't at least partially their problem to solve, and they think that if they roll out a feature and nobody knows about it that developers are the problem, then those people shouldn't be in charge of the dominant web browser.
To be clear, we're talking about Chris Coyier right now. The Chrome team doesn't have any way to contact him? The team had to know that REPLs would be impacted by this, right?
You can blame people for not having the right automation and dev tools lined up and for not reading the right blogs, but it still seems to me like this is covering up the fact that the Chrome team does not view it as their job to reach out to web developers or put serious effort into marketing changes. If Chris didn't know about these changes, then I seriously doubt that the Chrome team was getting any kind of a representative sample of developer feedback during this process.
> Personally, I wouldn't want to have to read the mailing lists and other articles. I would want a dashboard that tells me everything is tested and working fine automatically.
What view of the web does the Chrome team have if they think the majority of site operators have this kind of testing setup running? It just feels so ridiculously out of touch with the reality of where web developers congregate and how news gets disseminated. I know it's a difficult problem, but the responsibility of Chrome is to work with the web community as it exists, not as the professional fully-automated community they'd like it to be.
Chrome couldn't send out some Twitter DMs? Chrome team couldn't post a heads up to HN? Any effort to post anything to the popular web dev communities on Reddit? Did the team reach out to any any popular bloggers or members of the community to ask them to spread the word? When the Chrome team is making changes to the dominant browser for what is (imo) the most important platform on the planet, it just is not enough to say "we put it in the mailing list, and you weren't testing well enough." The expectations for the Chrome team here are higher, because Chrome matters more than other products.
Yes, developers need to meet Chrome halfway on communication, but frankly, Chrome is not coming halfway right now to meet us. It should not have been a surprise to some of the biggest REPL sites on the web that their products were about to break. I don't know what to say about this, I'm not trying to be mean, but if the Chrome team's perspective is that developer communication isn't at least partially their problem to solve, and they think that if they roll out a feature and nobody knows about it that developers are the problem, then those people shouldn't be in charge of the dominant web browser.
> To be clear, we're talking about Chris Coyier right now
People are just human, they will fail to understand changes sometimes and their impact. Or maybe, they're just not going to be listening at all. Or they saw it, and then a coworker interrupted them and they forgot. If you tell people that the Earth temperature is going to raise 1 degree, most will just glance over it and not understand the ramifications.
In the end, I don't know that much about this specific change, it's not my domain of expertise, but I know you can't expect random people to receive random messages from random sources. First it doesn't scale, and second it would be preferential treatment which doesn't seem to me in line with the healthy platform the web should be.
> What view of the web does the Chrome team have if they think the majority of site operators have this kind of testing setup running?
No, it's a personal opinion.
And yes, I believe that if you have expectations on the availability of your website, it should be tested frequently enough, with automation or simply having the regular team working on the product or QA use newer browser versions on the regular. If you're only reacting to breakage instead of being proactive, you'll never be able to have a service continuously running and should lower your expectations. The platform is evolving and changing. Most of the time, the impact will be negligible, but sometimes it's not, and you should be prepared. Or you should just freeze all software updates in your company context until you can vet that every critical component works fine.
> It should not have been a surprise to some of the biggest REPL sites on the web that their products were about to break
REPL websites are still largely working though, my samples are still working the same, I just don't use the affected APIs which I've avoided for a long time already. If they care deeply about some specific scenario, they should probably be tested. And every failure to catch an error is an opportunity to learn, for all sides involved.
People are just human, they will fail to understand changes sometimes and their impact. Or maybe, they're just not going to be listening at all. Or they saw it, and then a coworker interrupted them and they forgot. If you tell people that the Earth temperature is going to raise 1 degree, most will just glance over it and not understand the ramifications.
In the end, I don't know that much about this specific change, it's not my domain of expertise, but I know you can't expect random people to receive random messages from random sources. First it doesn't scale, and second it would be preferential treatment which doesn't seem to me in line with the healthy platform the web should be.
> What view of the web does the Chrome team have if they think the majority of site operators have this kind of testing setup running?
No, it's a personal opinion.
And yes, I believe that if you have expectations on the availability of your website, it should be tested frequently enough, with automation or simply having the regular team working on the product or QA use newer browser versions on the regular. If you're only reacting to breakage instead of being proactive, you'll never be able to have a service continuously running and should lower your expectations. The platform is evolving and changing. Most of the time, the impact will be negligible, but sometimes it's not, and you should be prepared. Or you should just freeze all software updates in your company context until you can vet that every critical component works fine.
> It should not have been a surprise to some of the biggest REPL sites on the web that their products were about to break
REPL websites are still largely working though, my samples are still working the same, I just don't use the affected APIs which I've avoided for a long time already. If they care deeply about some specific scenario, they should probably be tested. And every failure to catch an error is an opportunity to learn, for all sides involved.
> If you tell people that the Earth temperature is going to raise 1 degree, most will just glance over it and not understand the ramifications.
Wait, but... no. Scientists wouldn't have glanced over it and not understood the ramifications, and they didn't. Global warming doesn't seem like a great example to use here both because people have put a ton of effort into evangelizing it, and because it wasn't glossed over or ignored, many people took it seriously and worked to try and sound alarms. If only the Chrome team was putting even a fraction of the effort into evangelizing its changes as environmental advocates put into evangelizing global warming -- I would have no complaints in that world!
> but I know you can't expect random people to receive random messages from random sources
I have never personally spoken to Chris, but I can still promise you right now that he would not be offended or angry about being contacted for help evangelizing a breaking change. The Chrome team is not a random source, it should have contacts in the community. It should be a part of the community. If the Chrome team thinks of itself as outside of the community, as a random source that doesn't know anyone, that they would be intruding if it jumped into any conversations -- then that's a real big problem.
You want to meet us halfway on communication? Come meet us! Form some developer connections, get to know us. We're not all isolationists, we're in this together. We care about what the Chrome team has to say, we want the Chrome team to interact with us.
> First it doesn't scale
So, the alternative is to do no outreach at all? I don't get this.
> second it would be preferential treatment which doesn't seem to me in line with the healthy platform the web should be.
This is also such an odd take to me. The Chrome team should reach out to prominent members of the Javascript community that will be affected by breaking changes because those people will make it more likely that the news gets widely disseminated. Healthy communities talk amongst themselves, they communicate. If you went to developer advocates/bloggers like Coyier or Simmons who are deeply entrenched in these communities and asked for help spreading news about a change, they would help.
How much trouble would have been averted with Web Audio if anyone on the Chrome web team had thought to talk to people like Bennett and involve them in the actual decision making process and feature design? Nobody would have complained, game devs would have helped spread the word and warned the team about potential issues. We all would have been grateful!
I hope this idea is not representative of the overall Chrome team's opinions. I don't think anyone in the Javascript developer community thinks that "fairness" should mean that all developers are equally in the dark about every change.
> I believe that if you have expectations on the availability of your website, it should be tested frequently enough, with automation or simply having the regular team working on the product or QA use newer browser versions on the regular.
I would again point out that Google itself is not meeting your standards for testing upcoming browser features (https://news.ycombinator.com/item?id=28056738), and I still think it's tone-deaf to blame normal web developers for not following a process that nobody at all seems to have mastered. I don't expect Google to be perfect, but normal developers will always be less perfect than Google. The solution your proposing really isn't feasible for most companies.
But ignore the professional sites for a second. This is also just really troubling to hear as someone who cares about the web as a medium, not just as a business platform. The web is admittedly a moving platform, breaking changes will happen. That has always been the case. But we have also always emphasized that breaking changes are dangerous.
People die or they move on in life, and their websites stay up. Not every site can be migrated or updated, and when old sites break, that's a bad thing that we feel bad about. High school kids make games and weird offshoot communities put up forums in their basements. Nontechnical people build on the web to solve their problems because the web is accessible, which is good! We don't want a web that requires professional attention. It's not a purely professional platform, the professionals are in some ways the minority of the content that really matters to the web as a revolutionary, democratizing platform for human connection and innovation.
This has always been a core principle online: the tension between the need for the web to evolve vs the very serious charge that the web is for ordinary people and we don't break their stuff. Google itself has been a proponent of that view for so long. To ignore that tension or act like the real answer is to require developers to constantly have polished build/testing pipelines -- it's a really limited view of what the web is and what kinds of things get built on it, and it's kind of disappointing to hear it from someone on the Chrome team.
----
In general, I still don't understand this aversion to thinking of the web as a community or thinking of the web standards process as something that communities should be involved in. That's not meeting developers halfway on communication.
I've seen some takes and talked to people on the Chrome team before who have caught me by surprise, but I've never seen outright fatalism about the very idea of developers and browser makers having a close, collaborative relationship.
Wait, but... no. Scientists wouldn't have glanced over it and not understood the ramifications, and they didn't. Global warming doesn't seem like a great example to use here both because people have put a ton of effort into evangelizing it, and because it wasn't glossed over or ignored, many people took it seriously and worked to try and sound alarms. If only the Chrome team was putting even a fraction of the effort into evangelizing its changes as environmental advocates put into evangelizing global warming -- I would have no complaints in that world!
> but I know you can't expect random people to receive random messages from random sources
I have never personally spoken to Chris, but I can still promise you right now that he would not be offended or angry about being contacted for help evangelizing a breaking change. The Chrome team is not a random source, it should have contacts in the community. It should be a part of the community. If the Chrome team thinks of itself as outside of the community, as a random source that doesn't know anyone, that they would be intruding if it jumped into any conversations -- then that's a real big problem.
You want to meet us halfway on communication? Come meet us! Form some developer connections, get to know us. We're not all isolationists, we're in this together. We care about what the Chrome team has to say, we want the Chrome team to interact with us.
> First it doesn't scale
So, the alternative is to do no outreach at all? I don't get this.
> second it would be preferential treatment which doesn't seem to me in line with the healthy platform the web should be.
This is also such an odd take to me. The Chrome team should reach out to prominent members of the Javascript community that will be affected by breaking changes because those people will make it more likely that the news gets widely disseminated. Healthy communities talk amongst themselves, they communicate. If you went to developer advocates/bloggers like Coyier or Simmons who are deeply entrenched in these communities and asked for help spreading news about a change, they would help.
How much trouble would have been averted with Web Audio if anyone on the Chrome web team had thought to talk to people like Bennett and involve them in the actual decision making process and feature design? Nobody would have complained, game devs would have helped spread the word and warned the team about potential issues. We all would have been grateful!
I hope this idea is not representative of the overall Chrome team's opinions. I don't think anyone in the Javascript developer community thinks that "fairness" should mean that all developers are equally in the dark about every change.
> I believe that if you have expectations on the availability of your website, it should be tested frequently enough, with automation or simply having the regular team working on the product or QA use newer browser versions on the regular.
I would again point out that Google itself is not meeting your standards for testing upcoming browser features (https://news.ycombinator.com/item?id=28056738), and I still think it's tone-deaf to blame normal web developers for not following a process that nobody at all seems to have mastered. I don't expect Google to be perfect, but normal developers will always be less perfect than Google. The solution your proposing really isn't feasible for most companies.
But ignore the professional sites for a second. This is also just really troubling to hear as someone who cares about the web as a medium, not just as a business platform. The web is admittedly a moving platform, breaking changes will happen. That has always been the case. But we have also always emphasized that breaking changes are dangerous.
People die or they move on in life, and their websites stay up. Not every site can be migrated or updated, and when old sites break, that's a bad thing that we feel bad about. High school kids make games and weird offshoot communities put up forums in their basements. Nontechnical people build on the web to solve their problems because the web is accessible, which is good! We don't want a web that requires professional attention. It's not a purely professional platform, the professionals are in some ways the minority of the content that really matters to the web as a revolutionary, democratizing platform for human connection and innovation.
This has always been a core principle online: the tension between the need for the web to evolve vs the very serious charge that the web is for ordinary people and we don't break their stuff. Google itself has been a proponent of that view for so long. To ignore that tension or act like the real answer is to require developers to constantly have polished build/testing pipelines -- it's a really limited view of what the web is and what kinds of things get built on it, and it's kind of disappointing to hear it from someone on the Chrome team.
----
In general, I still don't understand this aversion to thinking of the web as a community or thinking of the web standards process as something that communities should be involved in. That's not meeting developers halfway on communication.
I've seen some takes and talked to people on the Chrome team before who have caught me by surprise, but I've never seen outright fatalism about the very idea of developers and browser makers having a close, collaborative relationship.
> And yes, I believe that if you have expectations on the availability of your website, it should be tested frequently enough, with automation or simply having the regular team working on the product or QA use newer browser versions on the regular.
This is so, so illustrative of the problem with the Chrome team's attitude - I'm not sure you could imply "the web is for businesses, amateurs should get out and just consume" any more heavily if you tried.
This is so, so illustrative of the problem with the Chrome team's attitude - I'm not sure you could imply "the web is for businesses, amateurs should get out and just consume" any more heavily if you tried.
Testing base, stable (from my perspective) infrastructure? Should I have tests that validate that JPGs still render? How about when used as a CSS background image? Does Chrome test the register reads assembly code produced by the C++ compiler in case there's a breaking change that gets missed?
I don't mean to hammer this point too hard, but when Chrome released click-to-play breaking changes for web audio, they broke alarms/timers on Google search.
So the "you'd catch all these changes if you were testing" excuse honestly kind of rubs me the wrong way, because as far as I can tell Google itself has trouble meeting that standard for even its biggest products.
So the "you'd catch all these changes if you were testing" excuse honestly kind of rubs me the wrong way, because as far as I can tell Google itself has trouble meeting that standard for even its biggest products.
Bugs happen, it's part of software development and no one is claiming any products from any company are exempt from them. We're only humans and it's still mostly humans writing the tests.
But the bigger story is not about solving specific bugs but how to learn from them, to make sure they don't happen in the future. It's not about putting the blame on specific individual or teams for their insufficient communication or testing.
But the bigger story is not about solving specific bugs but how to learn from them, to make sure they don't happen in the future. It's not about putting the blame on specific individual or teams for their insufficient communication or testing.
> It's not about putting the blame on specific individual or teams for their insufficient communication or testing.
We don't need to put the blame on anyone, but to your point on learning from bugs and making sure they don't happen in the future, how can that happen if we're fatalistic about why those bugs were caused?
I don't know what the Chrome team is doing differently now to prevent another situation like web audio from happening, because there was never any followup about process changes. The only thing that we were ever told during the web audio failure was that we needed to trust the Chrome team, and that they cared. But that never turned into anything tangible or visible. And X years later and X broken feature launches later, we're still having the same conversation.
If avoiding blame means we can't talk about why something went wrong, then that's a broken process. You're telling me that reaching out to developers is futile, and unless we pay a ton of attention to the mailing lists we're going to miss stuff, and that testing is the only thing that can save us. That's a regression from what I heard from Chrome devs during the web audio debacle. The team seems to have gotten more insular, not less.
We don't need to assign blame, but it would be good to actually learn from these situations. Nothing is changing, the dysfunctional communication between the Chrome dev team and developers is still just as bad today as it has ever been. Is the Chrome team going to do anything at all to help make the situation better?
We don't need to put the blame on anyone, but to your point on learning from bugs and making sure they don't happen in the future, how can that happen if we're fatalistic about why those bugs were caused?
I don't know what the Chrome team is doing differently now to prevent another situation like web audio from happening, because there was never any followup about process changes. The only thing that we were ever told during the web audio failure was that we needed to trust the Chrome team, and that they cared. But that never turned into anything tangible or visible. And X years later and X broken feature launches later, we're still having the same conversation.
If avoiding blame means we can't talk about why something went wrong, then that's a broken process. You're telling me that reaching out to developers is futile, and unless we pay a ton of attention to the mailing lists we're going to miss stuff, and that testing is the only thing that can save us. That's a regression from what I heard from Chrome devs during the web audio debacle. The team seems to have gotten more insular, not less.
We don't need to assign blame, but it would be good to actually learn from these situations. Nothing is changing, the dysfunctional communication between the Chrome dev team and developers is still just as bad today as it has ever been. Is the Chrome team going to do anything at all to help make the situation better?
> We can't just send deprecation notices to random contact emails (if there's any) on websites. We can't just open a "support request" to L1 customer support of websites telling them their site might not work soon.
What about folks who've registered for either origin trials or Google Search Console? Or Google Analytics?
That said, I'd love it if telemetry APIs were baked into the web, perhaps OpenTelemetry API support? Then website owners could set up their own error reporting OTLP endpoints or services to receive sampled deprecation alerts in a standard way, rather than assuming everybody can read the developer console in an end-user's browser (especially when it's hidden most of the time...)
Bonus points if we can ignore errors caused by extensions, or have extra feedback as to which extensions might be causing problems. Double bonus points if there's a UI so end users can choose whether to share this data or not, or to cache and sync the data so it only gets shared when on wifi or idle, in an extremely compressed way, and to provide a settings screen where you can browse what telemetry or errors are shared from/to websites in your history.
What about folks who've registered for either origin trials or Google Search Console? Or Google Analytics?
That said, I'd love it if telemetry APIs were baked into the web, perhaps OpenTelemetry API support? Then website owners could set up their own error reporting OTLP endpoints or services to receive sampled deprecation alerts in a standard way, rather than assuming everybody can read the developer console in an end-user's browser (especially when it's hidden most of the time...)
Bonus points if we can ignore errors caused by extensions, or have extra feedback as to which extensions might be causing problems. Double bonus points if there's a UI so end users can choose whether to share this data or not, or to cache and sync the data so it only gets shared when on wifi or idle, in an extremely compressed way, and to provide a settings screen where you can browse what telemetry or errors are shared from/to websites in your history.
> If you want to support specific browsers
This is a pretty arrogant position. If this is your perspective, please go work on Android team or something with a traditional SDK churn cycle. The Web is special.
This is a pretty arrogant position. If this is your perspective, please go work on Android team or something with a traditional SDK churn cycle. The Web is special.
I read chromestatus every week or so and the intended landing date for this change caught me off guard.
But do you use Chrome Canary, Dev or Beta for development purposes? Would you have then noticed the change?
Do you have continuous testing on the websites you maintain with those versions?
I presume you're only human, so it's almost expected you will skip over a change as you don't think it's relevant or might even take days off work, in which case, it's easy to forget to read it. ChromeStatus is just one of the many signals you should use to filter issues before they reach customers.
I presume you're only human, so it's almost expected you will skip over a change as you don't think it's relevant or might even take days off work, in which case, it's easy to forget to read it. ChromeStatus is just one of the many signals you should use to filter issues before they reach customers.
Yes, and I used to use it as my daily driver. But I switched to Firefox a year ago to make sure I wasn't ignoring the minority experience.
Yes, we have CI (700+ machine hours for runs-on-master integration tests). No, we don't have a test that would have caught this (we are an app building platform and some of our features which our users use to deliver features to their users use iframes)
Yes, we have CI (700+ machine hours for runs-on-master integration tests). No, we don't have a test that would have caught this (we are an app building platform and some of our features which our users use to deliver features to their users use iframes)
> proper announcements in ALL the relevant mailing lists and release notes.
I can't emphasize enough that mailing lists are worthless for this. Your average web developer reads no mailing lists, I'd be surprised if even 5% did, and those 5% are going to be clustered. Release notes (that anyone reads) come too late, since people only read them once users are already installing the broken browser.
Announcements that you actually expect to be read need to be in a much higher profile place, it looks like this is an appropriate blog: https://www.blog.google/products/chrome/ - even then it should be written with the goal of it being picked up by places like reddit/HN/twitter/news. Even then you should expect that most web developers won't find out, and most who do find out won't change anything in regards to your announcement that your new version of the browser is going to break compatibility with their perfectly functional website, incentives just won't align for many of them to fix it pre-emptively.
That last part is why I advocate for indicating the issue in a user visible but non-breaking way first, that's going to be the only way to get funding/time to update to your new version for many websites.
I can't emphasize enough that mailing lists are worthless for this. Your average web developer reads no mailing lists, I'd be surprised if even 5% did, and those 5% are going to be clustered. Release notes (that anyone reads) come too late, since people only read them once users are already installing the broken browser.
Announcements that you actually expect to be read need to be in a much higher profile place, it looks like this is an appropriate blog: https://www.blog.google/products/chrome/ - even then it should be written with the goal of it being picked up by places like reddit/HN/twitter/news. Even then you should expect that most web developers won't find out, and most who do find out won't change anything in regards to your announcement that your new version of the browser is going to break compatibility with their perfectly functional website, incentives just won't align for many of them to fix it pre-emptively.
That last part is why I advocate for indicating the issue in a user visible but non-breaking way first, that's going to be the only way to get funding/time to update to your new version for many websites.
Another idea that could reach a significant fraction of web developers: have the crawler check for potential use of deprecated features and alert the website owners through Google Search Console e-mail flow (using a separate message from regular GSC updates). The people who read GCP reports are likely to get worried and forward it to devs responsible for the site.
Another variant of this: surface such warnings on Google Analytics page/report. The easiest way to get software developers to do something is to convince sales&marketing that conversions will drop if they don't do it.
Another variant of this: surface such warnings on Google Analytics page/report. The easiest way to get software developers to do something is to convince sales&marketing that conversions will drop if they don't do it.
Announcement of SameSite=Lax by default was good. They were posted on web.dev.
There's always room for improvement on all of this stuff, but I'm generally in agreement, I thought the SameSite=Lax rollout went a lot more smoothly, and I saw people outside of Chrome mailing lists talking about it and sounding alarms that sites might break.
I try to pay attention to upcoming potentially breaking changes, but I didn't know about the iframe changes (luckily they didn't affect any of my projects). I did hear about the SameSite changes from multiple sources, it felt like there was a real effort there to try and break the news into the mainstream.
I also think a big part of what made SameSite=Lax better was that it wasn't just Chrome notifying people about the changes, it was other developers in the community helping to spread the word. I saw multiple blog posts and Twitter threads warning about it.
I don't think the model of "Chrome announces something then wipes its hands and steps away" works in the real world. Developers need to be included in efforts to spread awareness, because there are communities that the Chrome team doesn't have access to, and not everyone pays attention to what the Chrome team posts. It's better if multiple stakeholders both inside and outside of Chrome are invested in getting the word out.
It sounds to me like a big part of the complaint about the removal is that there isn't currently a good replacement for `alert` in intro tutorials, or a clear process for sites that depend on `alert` to quickly move to something else. I don't expect the Chrome team to understand that in advance, the web is enormous and they are going to miss use-cases, no single team can predict the full impact of every browser change. But early awareness of changes and early interaction with communities outside of the main mailing lists will make it more likely that developers and communities raise these issues so they can be addressed before there's a PR fallout.
I try to pay attention to upcoming potentially breaking changes, but I didn't know about the iframe changes (luckily they didn't affect any of my projects). I did hear about the SameSite changes from multiple sources, it felt like there was a real effort there to try and break the news into the mainstream.
I also think a big part of what made SameSite=Lax better was that it wasn't just Chrome notifying people about the changes, it was other developers in the community helping to spread the word. I saw multiple blog posts and Twitter threads warning about it.
I don't think the model of "Chrome announces something then wipes its hands and steps away" works in the real world. Developers need to be included in efforts to spread awareness, because there are communities that the Chrome team doesn't have access to, and not everyone pays attention to what the Chrome team posts. It's better if multiple stakeholders both inside and outside of Chrome are invested in getting the word out.
It sounds to me like a big part of the complaint about the removal is that there isn't currently a good replacement for `alert` in intro tutorials, or a clear process for sites that depend on `alert` to quickly move to something else. I don't expect the Chrome team to understand that in advance, the web is enormous and they are going to miss use-cases, no single team can predict the full impact of every browser change. But early awareness of changes and early interaction with communities outside of the main mailing lists will make it more likely that developers and communities raise these issues so they can be addressed before there's a PR fallout.
I'll add onto this, putting an announcement out needs to be followed up by checking to see if the announcement has gained any traction.
Announcing breaking changes is not a checklist that can be filled out and then ignored. Put out an announcement, see if any other sites or prominent developers pick up on it, if they haven't picked up on it then the job isn't done and the change needs to be advertised more.
Maybe for some things posting it to the blog might be enough, and the major stakeholders that need to know will pick it up. Then you can move on to the next steps. But if they don't see it, and you don't see any reaction to the blog posts, then don't just move onto stage 2 because "they had their chance, if it breaks now it's their fault." :)
Have some standards of what level of conversation and preparation you expect to see from web developers before you consider the community adequately informed.
Announcing breaking changes is not a checklist that can be filled out and then ignored. Put out an announcement, see if any other sites or prominent developers pick up on it, if they haven't picked up on it then the job isn't done and the change needs to be advertised more.
Maybe for some things posting it to the blog might be enough, and the major stakeholders that need to know will pick it up. Then you can move on to the next steps. But if they don't see it, and you don't see any reaction to the blog posts, then don't just move onto stage 2 because "they had their chance, if it breaks now it's their fault." :)
Have some standards of what level of conversation and preparation you expect to see from web developers before you consider the community adequately informed.
Here's an example of a major bank website with some user visible non-breaking issue I saw recently: https://youtu.be/GFvaRgFf4LU?t=482 . It seems that it's been visible for a while, yet is not fixed. It's actually quite common to see errors unfixed in software as you may know.
No matter what you do, some websites will only be fixed a long time after very obvious warnings are displayed. Some will never be fixed until they actually stops working. Some will just never be updated at all.
Maybe you're one of the people who take their car to the repair shop when the engine light is on, but there are also many others who will just ignore it as the car still drives "fine" (for now at least).
Regarding your suggestion of using Reddit, HN, Twitter, news, it's not always possible or relevant. I've seen a lot of very interesting publications just not getting any traction on those are they're boring in nature or cater to experts mainly. They're also read only by a fraction of users.
Unfortunately, if you're hit by any issue, you shouldn't be only asking what others should do for you, but also what you can do to catch those issues in the future yourself. All sides can maybe do better at broadcasting information about some changes, or voice their opinion better and sooner, but it's not an easy problem with an easy solution.
No matter what you do, some websites will only be fixed a long time after very obvious warnings are displayed. Some will never be fixed until they actually stops working. Some will just never be updated at all.
Maybe you're one of the people who take their car to the repair shop when the engine light is on, but there are also many others who will just ignore it as the car still drives "fine" (for now at least).
Regarding your suggestion of using Reddit, HN, Twitter, news, it's not always possible or relevant. I've seen a lot of very interesting publications just not getting any traction on those are they're boring in nature or cater to experts mainly. They're also read only by a fraction of users.
Unfortunately, if you're hit by any issue, you shouldn't be only asking what others should do for you, but also what you can do to catch those issues in the future yourself. All sides can maybe do better at broadcasting information about some changes, or voice their opinion better and sooner, but it's not an easy problem with an easy solution.
> No matter what you do, some websites will only be fixed a long time after very obvious warnings are displayed.
Okay, let's try another angle. Does the Chrome team have any stats at all about how many developers were informed about this change and were able to adapt to it before it went live?
You're right, some people are going to slip through the cracks, that's inevitable. How many people? How does the Chrome team determine if they're doing a good enough job with communication, what metrics for developer uptake are even being measured here? Is the Chrome team watching any public spaces like Twitter or Reddit to see whether or not changes are actually being seen and disseminated in developer communities?
You're phrasing this as if it's just a subset of developers who didn't realize what was going on. I would surprised if that's the case, I suspect the vast majority of developers did not realize what was going on.
> I've seen a lot of very interesting publications just not getting any traction on those are they're boring in nature or cater to experts mainly. They're also read only by a fraction of users.
Also can't stress this enough, still more users than read the mailing lists. They will still get more traction than Chrome's existing announcements. You don't have to stop posting to the mailing lists, just put a little bit of effort into going into communities where developers actually spend time.
We know that developers don't read the mailing lists. So let's try to find out what they do read.
> Unfortunately, if you're hit by any issue, you shouldn't be only asking what others should do for you, but also what you can do to catch those issues in the future yourself.
Definitely, but this is a really tone-deaf response to people telling the Chrome team that they have a problem with communication.
This is also one of my evergreen complaints about how breaking changes work in Chrome -- it always ends up being phrased as either the developers fault or an unsolveable problem. The best we can get is "all sides can maybe do better at broadcasting information". Yes, we have to treat Chrome like it might break our stuff randomly. We have to constantly be engaged in the web standards process, even when it's exhausting, even when it means we're drinking a firehose of information. Yes, we need to set up automated testing for all of our projects, we can't put sites up online and expect them to keep working.
We do our best to mitigate the problems that the Chrome team is causing by refusing to proactively reach out, by refusing to do anything beyond just posting their changes and giving people time to read them. And we don't get any indication that the process is ever going to improve.
Please meet us halfway.
Or at least the Chrome team could take your own advice and ask itself what it can do to make messaging more effective, rather than "only asking what developers should do for them" to make breaking changes go more smoothly.
Okay, let's try another angle. Does the Chrome team have any stats at all about how many developers were informed about this change and were able to adapt to it before it went live?
You're right, some people are going to slip through the cracks, that's inevitable. How many people? How does the Chrome team determine if they're doing a good enough job with communication, what metrics for developer uptake are even being measured here? Is the Chrome team watching any public spaces like Twitter or Reddit to see whether or not changes are actually being seen and disseminated in developer communities?
You're phrasing this as if it's just a subset of developers who didn't realize what was going on. I would surprised if that's the case, I suspect the vast majority of developers did not realize what was going on.
> I've seen a lot of very interesting publications just not getting any traction on those are they're boring in nature or cater to experts mainly. They're also read only by a fraction of users.
Also can't stress this enough, still more users than read the mailing lists. They will still get more traction than Chrome's existing announcements. You don't have to stop posting to the mailing lists, just put a little bit of effort into going into communities where developers actually spend time.
We know that developers don't read the mailing lists. So let's try to find out what they do read.
> Unfortunately, if you're hit by any issue, you shouldn't be only asking what others should do for you, but also what you can do to catch those issues in the future yourself.
Definitely, but this is a really tone-deaf response to people telling the Chrome team that they have a problem with communication.
This is also one of my evergreen complaints about how breaking changes work in Chrome -- it always ends up being phrased as either the developers fault or an unsolveable problem. The best we can get is "all sides can maybe do better at broadcasting information". Yes, we have to treat Chrome like it might break our stuff randomly. We have to constantly be engaged in the web standards process, even when it's exhausting, even when it means we're drinking a firehose of information. Yes, we need to set up automated testing for all of our projects, we can't put sites up online and expect them to keep working.
We do our best to mitigate the problems that the Chrome team is causing by refusing to proactively reach out, by refusing to do anything beyond just posting their changes and giving people time to read them. And we don't get any indication that the process is ever going to improve.
Please meet us halfway.
Or at least the Chrome team could take your own advice and ask itself what it can do to make messaging more effective, rather than "only asking what developers should do for them" to make breaking changes go more smoothly.
> . 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.
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]
Hmm, the linked bug is from March 2020, and this thing will be Removed in December 2021. That's nearly 2 years, no?
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.
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.
> Which is in some ways even worse to me, because what were they doing for those 2 years?
What everyone always does, which is put it off until the last minute. Also, unless there's actual breaking change, people often don't notice, hence putting it behind a Chrome Origin Trial for the last 6 months forcing people to actually address it.
What everyone always does, which is put it off until the last minute. Also, unless there's actual breaking change, people often don't notice, hence putting it behind a Chrome Origin Trial for the last 6 months forcing people to actually address it.
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
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.
https://bugzilla.mozilla.org/show_bug.cgi?id=1624978
The discussion about this started a year ago with the individual browsers and WHATWG.
https://bugzilla.mozilla.org/show_bug.cgi?id=1624978
Not a suitable answer for website owners. Even if they literally asked all their customers to switch, end users won't.
The issue isn't the cross origin alert change. It's the TOS required and opt-out process.
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.
[1] https://groups.google.com/a/chromium.org/g/blink-dev/c/hTOXi...
> "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...
> awknoledge that it is not in the web's best interest to do so
The two people you are quoting don't appear to be Google employees. Maybe I'm wrong, but it appears that the Google employees are usually using @chromium.org or @google.com email addresses.
Edit, correction: at least one of the people is a Google employee using a personal email address. I regret the error. Nonetheless, I don't agree with the characterization of the responses.
The two people you are quoting don't appear to be Google employees. Maybe I'm wrong, but it appears that the Google employees are usually using @chromium.org or @google.com email addresses.
Edit, correction: at least one of the people is a Google employee using a personal email address. I regret the error. Nonetheless, I don't agree with the characterization of the responses.
Yeah, I will never be asking "Google, May I" to make HTML work. Contrary to Mountain View opinion, the web is not their walled garden.
Although it might be time to bring back those stupid "Best viewed in" banners, because everything old is new again.
Although it might be time to bring back those stupid "Best viewed in" banners, because everything old is new again.
They never left the B2B and corporate world.
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.
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.
> which you have to abide by using google.com or any other Google web property
When did my web site become a Google property?
When did my web site become a Google property?
> When did my web site become a Google property?
It isn't. Not sure that's relevant to the discussion though. We're talking about Google's TOS, which presumably the person at the start of this thread is concerned about having to accept to get an origin trial token.
It isn't. Not sure that's relevant to the discussion though. We're talking about Google's TOS, which presumably the person at the start of this thread is concerned about having to accept to get an origin trial token.
Seems relevant to me. Requiring a website owner who may have no relationship with Google to enter into a contract with Google in order for their website not to be broken for their users -- I think that's antithetical to the idea of an Open web.
Google is not offering any kind of service for that contract, other than that they won't break exiting functionality for your website, a thing that they have no ownership over. I feel it's problematic for a user to visit a website and essentially get told "the site will no longer work for you because the owner wouldn't sign our TOS."
TLDR, I don't like the philosophy that a website operator needs to get Google's permission for their site to work in Chrome.
Google is not offering any kind of service for that contract, other than that they won't break exiting functionality for your website, a thing that they have no ownership over. I feel it's problematic for a user to visit a website and essentially get told "the site will no longer work for you because the owner wouldn't sign our TOS."
TLDR, I don't like the philosophy that a website operator needs to get Google's permission for their site to work in Chrome.
TLDR, I don't like the philosophy that a website operator needs to get Google's permission for their site to work in Chrome.
I absolutely agree with you and think that we need a term for (the opposition to) this: browser neutrality.
I absolutely agree with you and think that we need a term for (the opposition to) this: browser neutrality.
There will always be things about browsers that are different from vendor to vendor. It seems impractical to expect that you would be able to access all the relevant resources without going to the vendor's website.
> It seems impractical to expect that you would be able to access all the relevant resources without going to the vendor's website.
I'm not sure I understand what you're trying to say here. Going to Google's website or looking at Chrome documentation is a lot different than signing a TOS with them.
And Chromium is Open Source, so I don't need to sign a TOS to test V8 changes or get access to Chromium features.
The only reason a TOS is coming into this is because Google artificially inserted one in front of an origin trial that realistically should be handled based on some kind of request header or at most as a signup form with a DNS check for owner verification. None of that should require a legal contract or Google account.
I'm not sure I understand what you're trying to say here. Going to Google's website or looking at Chrome documentation is a lot different than signing a TOS with them.
And Chromium is Open Source, so I don't need to sign a TOS to test V8 changes or get access to Chromium features.
The only reason a TOS is coming into this is because Google artificially inserted one in front of an origin trial that realistically should be handled based on some kind of request header or at most as a signup form with a DNS check for owner verification. None of that should require a legal contract or Google account.
“But look, you found the notice, didn’t you?”
“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.”
“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.”
This is the noticeboard for upcoming proposed changes for Blink. You may not have known about its location before, but that does not mean it was hidden away or intentionally obscure.
And now everyone who has ever made a website needs to carefully track that location, just because it might otherwise quietly break their production site? There are plenty of better ways for people to spend their time than searching through every website of everything you have ever made code for.
Software changes. It's an unfortunate reality of the profession. If you're someone who relies on the web platform for your living, you, at a minimum, need testing on the beta and dev versions of all major browsers your users use, so you'll get early notice of these types of issues. There's not any alternative approach besides never changing any installed feature, which is a possible approach, but not the one we as a species are taking.
Ideally, people would. But for most, a browser breaking such a basic feature is just not on the radar. I would imagine there is a good number of extremely simple sites (or parts of sites that you'd easily assume wouldn't ever need maintaining) that this breaks. IMO, breaking a feature requires it to either be pretty much never used, have a very good reason, or be heavily publicized. This change has none.
Reasoning seems fine to me. This is reflective of different priorities, I suppose, but my view is that the primary use of alerts are scams and new JS users on sites like codepen. Removing the feature would prevent the abuses, which do far more harm than the few legit use cases do good. Especially since, for the legit uses, there are mostly straightforward fixes. A tiny handful out of the billions of users of the web platform were affected negatively. It's not an optimal tradeoff, but it's pretty close.
> What's weird about the TOS?
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?
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]
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.
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.
At this point HTML is quickly turning into not a markup language
I miss writing HTML instead of telling Javascript how to create the HTML that I would use. I preferred JQuery's $('<htmlcodegoeshere>') vs document.createElement('element').append(document.createElement()) bullshit
> 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?
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.)
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.)
Plans on Alpha Centauri
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.
Works fine in Firefox, too.
Not for me on OSX. New FF profile to rule out extensions/settings; https://youtu.be/XGTyDQGTC4E.
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.
Screen capture: https://imgur.com/RmoSZRB
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
[deleted]
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?
im also getting it after trying with troubleshooting mode on (disables extensions, themes and custom settings.) this is on windows and latest firefox 90.0.2
https://i.imgur.com/y5lkfHI.gif
https://i.imgur.com/y5lkfHI.gif
Huh, TIL. I suppose I'd recommend a report to Webcompat.
Tried with a brand new Firefox profile, on OSX. Still wonky.
Screencast: https://youtu.be/XGTyDQGTC4E
Screencast: https://youtu.be/XGTyDQGTC4E
From a comment near the bottom of the page from "[email protected]":
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>
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>
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?
[... 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.
This could have been handled better:
* 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.
* 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.
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.
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.
"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.
Hopefully Chrome can do the same soon."
Is this the time to shine for our dear old friend?
Hopefully Chrome can do the same soon."
Is this the time to shine for our dear old friend?
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.
As a counter-point to this, `document.write` is (currently) a render blocking action, and thus allows one to load assets without a bunch of `document.addEventListener("DOMContentReady", (ohgawd) => {})` business to ensure a `window.__whatever__` is initialized before 10 quadrillion megs of JS run
Maybe in some pseudofuture there will be a less heinous way to schedule the order of JS evaluation, but until that future materializes, document.write is damn handy
Maybe in some pseudofuture there will be a less heinous way to schedule the order of JS evaluation, but until that future materializes, document.write is damn handy
...and window.alert is a blocking action, which allows you to display a message like "You lost! Your score: 1234 points" without having to build additional UI or adapt the loop of your game to be able to prevent game logic from continuing until the user clicks "ok" - which for jam games is damn handy ;)
I’ve been tracking a massive mobile malvertising and drive-by malware download operatition for the last several months.
The malvertising company is abusing a script found on GitHub called: “alerty” hXXps://github.com/undead2/alerty#readme
The malvertising company is abusing a script found on GitHub called: “alerty” hXXps://github.com/undead2/alerty#readme
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.
* 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.
So everybody has to write or to add some kind of UI-kit and use async-await or callbacks. The loss of a blocking state for that particular thread is in practice the only result of this (besides breaking a lot of backward compatibility).
However, the loss of system dialogs in favor for custom UI-kits implemented in the DOM is a major attack on accessibility.
Edit, regarding backward compatibility: A sustainable web-stack is really of major concern. For some decades now, most of human creativity and content production has been published on the Web, much of this exclusively so. Backward compatibility is important, if we don't want to leave a singular black hole as our legacy and as the heritage of future generations. For us as a society, as a culture, this is of much more importance than adding yet another fancy capability to the standard. – As it turns out, the singularity is not artificial superintelligence (ASI), but the evergreen browser and rolling web standards (EGB-RWS).
However, the loss of system dialogs in favor for custom UI-kits implemented in the DOM is a major attack on accessibility.
Edit, regarding backward compatibility: A sustainable web-stack is really of major concern. For some decades now, most of human creativity and content production has been published on the Web, much of this exclusively so. Backward compatibility is important, if we don't want to leave a singular black hole as our legacy and as the heritage of future generations. For us as a society, as a culture, this is of much more importance than adding yet another fancy capability to the standard. – As it turns out, the singularity is not artificial superintelligence (ASI), but the evergreen browser and rolling web standards (EGB-RWS).
Those are not "use cases". What is being blocked here is alert. It's like I need to put "that also calls alert" at the end of every example you put forward.
It's not just alert, it's also confirm which I think it's a perfectly legit popup, and you see it a lot for navigation with unsaved changes.
[deleted]
Penetration testing proof of concept XSS code. We commonly use alert to demo that it is executing code. Certainly there are other options, it’s just a common tool for many testers.
True, however when people pop an alert from a cross origin iframe for a bug bounty, 80% of the time they're pretending to be on the parent origin when they aren't and get sad when their report is rejected.
Occasionally people use it for print debugging... but realistically its 99% malvertising.
To show an alert to the user
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.
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.
prompt & confirm are native, and so automatically and correctly work with all your accessibility software.
Most "modern" modals struggle to correctly inform a screenreader, let alone all the other accessibility tools.
So yes, I would say that 'confirm' is a far better way of doing it.
Most "modern" modals struggle to correctly inform a screenreader, let alone all the other accessibility tools.
So yes, I would say that 'confirm' is a far better way of doing it.
I'm building https://starboard.gg, it has the same issue. The iframe is important for sandboxing user code, and alert is often used in tutorials (despite being bad practice, it's intuitive for beginners).
In our app we use this as a simple way to notifiy the user of rare, exceptional errors. E.g. Network errors, being out of sync with the backend.
I think some Moodle plugins use it.
alert is also broken in other way. When triggered by onblur, it causes infinite loop. But the bug is marked as WontFix because "Chromium team highly recommends that you not use JavaScript dialogs".
https://bugs.chromium.org/p/chromium/issues/detail?id=666205
https://developers.google.com/web/updates/2017/03/dialogs-po...
https://bugs.chromium.org/p/chromium/issues/detail?id=666205
https://developers.google.com/web/updates/2017/03/dialogs-po...
Yeah, I kind of agree with them here, alert is such a massive anti-pattern that it's not worth anyone's time to fix nonsense edge cases
Chrome is more and more becoming the new Internet Explorer :(
[deleted]
this broke our chrome devtool plugin. They should have notified people before hand.
Hasn't Firefox been blocking cross-origin iframes for years?
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...