FF127 base href forbids javascript and data URLs

[hamishwillee]

FF127 removes support for data: and javascript: URLs in the base element href in https://bugzilla.mozilla.org/show_bug.cgi?id=1850967

Related docs changes can be tracked in mdn/content#33566

[Elchi3]

Why not make use of impl_url?

[hamishwillee]

Why not make use of impl_url?

@Elchi3 Honestly? I don't know how, and I don't see any value to them - certainly not beyond one or two specialist users.

Edit: Certainly not "value for money" of my time.

Because it shouldn't block this.

[Elchi3]

@Elchi3 Honestly? I don't know how, and I don't see any value to them - certainly not beyond one or two specialist users.

• We recently converted notes to imps_urls: Convert simple "See bug" notes to impl_url keys #20608
• MDN is one "specialist" user :) fix(bcd): re-surface "see bug xxxxx" notes yari#10549
• @captainbrosset is a user for https://patrickbrosset.com/lab/2024-03-01-bcd-impl-url/

Edit: Certainly not "value for money" of my time.

Okay... 🤷 I made the change in cbc3b34 for you. Merging.

[captainbrosset]

@hamishwillee wrote:

Honestly? I don't know how, and I don't see any value to them - certainly not beyond one or two specialist users.

I see a lot of potential for impl_url in BCD. They're not exposed front and center on MDN (you have to click to expand the cell first). But I've been trying to find ways to add more of them to BCD over time and to make them more visible in multiple places.

See this Can I Use issue for example: Fyrd/caniuse#7009

I'm also side-working on a web features explorer site which shows them: https://captainbrosset.github.io/web-features-explorer/nobaseline/ (some of the red compat blocks have links to bugs, many don't, and I'm trying to fix this).

My thinking is about "closing the loop". I get it that most devs will not care or have the time to interact with browser vendors, but I don't see a valid reason not to give developers a way to go from "this features is not yet implemented in browser X" to "oh, here's why, and let me vote/comment on this bug", if we can.

[hamishwillee]

@Elchi3 @captainbrosset FWIW I find the argument for a notional unimpl_url for tracking standards positions and unimplemented features very compelling.

But impl_url is for stuff that is already done right? I spend much of my day looking at those bugs to work out what has been done so developers don't have to. If it is for future looking tracking bugs then I missed the memo sorry. I would differentiate what has been done and is to be done because presumably they have different target audiences.

Either way, it's important to you, and if this is just a matter of putting bug URL in then I will do it in future.

[hamishwillee]

PS. THanks for adding it and reviewing @Elchi3

[captainbrosset]

Oh interesting, my understanding was that impl_url was for any state of the feature, and I use it mostly (only) for unimplemented things. I don't really have a use case for finding the bug url once a feature has shipped.
My use case is really centered around increasing visibility around featuress that haven't shipped yet. Either the bug is already on file, in which case BCD having it as impl_url property helps a lot. Or the bug doesn't exist yet, presumably because the browser vendor doesn't agree with the feature, in which case having a link to the standards position repo helps a lot (see web-platform-dx/web-features#186).

[hamishwillee]

Oh interesting, my understanding was that impl_url was for any state of the feature, a

@captainbrosset My understanding was that "historically" it was for before official release when you didn't have full implementation, and that after release it got removed. But if you look at the schema, you are right: https://github.com/mdn/browser-compat-data/blob/main/schemas/compat-data-schema.md#impl_url

So perhaps it changed. As long as the rendering can differentiate between bugs, standards positions and whatever then we're fine. If not, then you might want to adjust that section in the schema doc.