91–100 of 160 posts
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.
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.
Earlier quoted context omitted.
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…
This is one of the most common phishing vectors.
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.
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 tur…
Though they may need to move beyond the line of death to mitigate spoofing.
Earlier quoted context omitted.
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 tur…
>(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"?
Earlier quoted context omitted.
> 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? 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.
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.
Earlier quoted context omitted.
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 develop…
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…
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.
Earlier quoted context omitted.
“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.”
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.
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…
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.
They've even eschewed the standard way to opt-in iframes to powerful, dangerous features like `alert` and `confirm` - you can't even `sandbox` the iframe to allow it. You have to enroll your website in a Chrome Origin Trial[0], which only lasts until December, and also requires you to create a Google account, agree to Google ToS, and you might be blessed with the ability for your perfectly-fine-before-Chromium-team-c…
> 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.
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.