71–80 of 160 posts
What's a legit use for this?
repl.it which uses an iframe and it might be good to showcase prompt
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…
Earlier quoted context omitted.
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 $(' ') vs document.createElement('element').append(document.createElement()) bullshit
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 sens…
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…
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.
Earlier quoted context omitted.
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.
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.
Hopefully Chrome can do the same soon."
Is this the time to shine for our dear old friend?
Earlier quoted context omitted.
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 regard…
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.
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…
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
> "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...
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…
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