Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

bugs.chromium.org

Post reply on HN
Print view View original

101–110 of 160 posts

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

#101

Post by [deleted] »

masswerk wrote: post #28
akersten wrote: post #8

Earlier quoted context omitted.

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

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

[deleted]

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

#102

Post by graderjs »

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?

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

#103

Post by userbinator »

danShumway wrote: post #96
asdfasgasdgasdg wrote: post #84

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…

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.

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

#104

Post by shakna »

TheRealPomax wrote: post #30
merb wrote: post #14

Earlier quoted context omitted.

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.

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.

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

#105

Post by asdfasgasdgasdg »

dzaima wrote: post #98
asdfasgasdgasdg wrote: post #82

Earlier quoted context omitted.

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.

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

#106

Post by svieira »

Orphis wrote: post #97
gpm wrote: post #75

Earlier quoted context omitted.

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 fo…

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…

I read chromestatus every week or so and the intended landing date for this change caught me off guard.

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

#107

Post by Orphis »

danShumway wrote: post #99
Orphis wrote: post #97

Earlier 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…

> 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/142002753300…

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.

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

#108

Post by gpm »

Orphis wrote: post #97
gpm wrote: post #75

Earlier quoted context omitted.

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 fo…

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 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.

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

#109

Post by Orphis »

svieira wrote: post #106
Orphis wrote: post #97

Earlier 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…

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.

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

#110

Post by danShumway »

Orphis wrote: post #107
danShumway wrote: post #99

Earlier quoted context omitted.

> 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/142002753300…

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…

> 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.

Post reply on HN