Live data from Hacker News

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

bugs.chromium.org

111–120 of 160 posts

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

#111
post #98

Earlier quoted context omitted.

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…

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.

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

#112
post #108
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…

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

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.

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

#114
post #107

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…

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?

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

#115
post #63

Earlier quoted context omitted.

That's a way of saying "decades old". Not to count years literally.

yes, and it's also understood that people are not really from the future with the information that I requested. Did you really think that was what I believed so that you needed to pedantically explain it to me?

Thought you meant he was wrong to claim "for 50 years".

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

#116
post #108
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…

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

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.

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

#117

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

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 ` `, (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 comme…

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

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

#118
post #9

Earlier quoted context omitted.

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

Idk why everyone jumps to these paranoid conspiracy theories - alert() box to trick people has been a thing for decades, and its super rare for it to be used legitly outside of debugging.

Who uses alert for debugging anymore?

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

#119

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

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

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

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

#120
post #109

Earlier quoted context omitted.

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…

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)

Post reply on HN