Earlier quoted context omitted.
> 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.
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…
Implement window.{alert, prompt, confirm} removal from cross-origin iframes
131–140 of 160 posts
Re: Implement window.{alert, prompt, confirm} removal from cross-origin iframes
#132Earlier quoted context omitted.
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.
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.
Re: Implement window.{alert, prompt, confirm} removal from cross-origin iframes
#133Earlier quoted context omitted.
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…
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.
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.
Re: Implement window.{alert, prompt, confirm} removal from cross-origin iframes
#134Earlier quoted context omitted.
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…
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?
...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.)
Re: Implement window.{alert, prompt, confirm} removal from cross-origin iframes
#135Earlier quoted context omitted.
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…
> 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.
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`?
Re: Implement window.{alert, prompt, confirm} removal from cross-origin iframes
#136Earlier quoted context omitted.
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.
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…
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?
Re: Implement window.{alert, prompt, confirm} removal from cross-origin iframes
#137Earlier quoted context omitted.
> 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…
> 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 th…
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.
Re: Implement window.{alert, prompt, confirm} removal from cross-origin iframes
#138Earlier quoted context omitted.
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?
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. (I…
Re: Implement window.{alert, prompt, confirm} removal from cross-origin iframes
#139https://bugs.chromium.org/p/chromium/issues/detail?id=666205
https://developers.google.com/web/updates/2017/03/dialogs-po...
Re: Implement window.{alert, prompt, confirm} removal from cross-origin iframes
#140Earlier quoted context omitted.
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 lan…
> 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 yo…