Updates for Firefox 120

[Elchi3]

I've run the collector for Firefox 120 beta.

This PR sets the following features to 120:

User activation (confirmed by https://bugzilla.mozilla.org/show_bug.cgi?id=1791079)

• api.Navigator.userActivation
• api.UserActivation
• api.UserActivation.hasBeenActive
• api.UserActivation.isActive

ToggleEvent (confirmed by https://bugzilla.mozilla.org/show_bug.cgi?id=1817122) (Not in Ruth's list!)

• api.ToggleEvent
• api.ToggleEvent.ToggleEvent
• api.ToggleEvent.newState
• api.ToggleEvent.oldState

WebAuthn addition (confirmed by https://bugzilla.mozilla.org/show_bug.cgi?id=1810851)

• api.PublicKeyCredential.authenticatorAttachment

The following features are already marked as shipping in Firefox 120 in BCD:

• css.types.color.light-dark
• css.types.length.lh
• css.types.length.rlh

---

The tracking issue Ruth filed contains a few more things that the collector doesn't know about.

More complex cases that need separate investigation:

• html.iframe.lazy: This is nightly only, so not in list for 120. Set to preview in FF120 iframe support lazy loading in nightly #21126
• <source media> for media elements: See Firefox 120: Add notes for media support in <support> across firefox releases #21158
• moz-transform: See relnote(120): Mark prefixed transition and transform props as removed in Nightly #21195 (a nightly-only change)

Cases to add manually:

• http.status.103: Added manually in de13a92 and 7dda752
• WebAuthn minPinLength extension: Added manually in FF120 CredentialsContainer.minPinLength extension #21116
• css.types.-moz-image-rect: Added manually in 6e065e2
• css.properties.text-wrap.balance: need to add manually

cc @Rumyra @bsmth

[github-actions]

This pull request has merge conflicts that must be resolved before it can be merged.

[Elchi3]

@hamishwillee Thanks for your review. If we would provide a PR like this one for every future Firefox release, would this work for you? What would you improve?

[hamishwillee]

@hamishwillee Thanks for your review. If we would provide a PR like this one for every future Firefox release, would this work for you?

Absolutely

What would you improve?

It would be better to split by affected document and name the change based on the highest-level-most-granular modified feature and the source of the change. So in this update you'd end up with Bot: FF120 Update to UserActivation and Bot: FF120 Update to Navigator.userActivation.

This hasn't merged because it is monolithic. If it was just my bits I would already have approved and merged those parts. If there had been any nuances missed by testing then no one else would have to wait on me looking at those. I'm thinking cases where the API is stubbed so it passes an existence test, but doesn't actually "work".

Counter argument for monolithic issue is that it gives just one place for all information about the release changes.

Note, I edited this because I originally requested better documentation, then I looked more closely and you provided exactly what I asked for already. Doh.

[hamishwillee]

@Elchi3 Perhaps though, I'm not thinking of this in the same way as you.

I've been envisaging a model where you create this PR(s), they then get reviewed by people like me while we're doing docs for the release, and then merges. But perhaps that is not the intent, and even if it is, perhaps not the right approach.

We could instead create the PRs then auto merge (or merge after cursory inspection). Writers would then retrofit fixes to specific cases afterwards if needed - for example adding a note that something is a partial implementation.

I quite like the second approach because most of the time the tests end up being correct. It might or might not be quite as accurate on submission, but likely to be a much more efficient process with fewer delays.

Upshot, I'd amend my answer to the previous comment if the intent is to auto merge and correct, rather than manually correct and then merge.

[hamishwillee]

Probably another tool, but "auto addition of spec urls and MDN URLs if known and not present" would be nice.

[hamishwillee]

html.iframe.lazy: This is nightly only and I guess it should be in Ruth's list as an experimental feature :)

FYI it is currently nightly and behind pref. Expectation is probably will end up in 121. I have added to preview in #21126

[Elchi3]

It would be better to split by affected document and name the change based on the highest-level-most-granular modified feature and the source of the change. So in this update you'd end up with Bot: FF120 Update to UserActivation and Bot: FF120 Update to Navigator.userActivation.

This hasn't merged because it is monolithic. If it was just my bits I would already have approved and merged those parts. If there had been any nuances missed by testing then no one else would have to wait on me looking at those. I'm thinking cases where the API is stubbed so it passes an existence test, but doesn't actually "work".

Counter argument for monolithic issue is that it gives just one place for all information about the release changes.

Note, I edited this because I originally requested better documentation, then I looked more closely and you provided exactly what I asked for already. Doh.

Yes, I tried to capture everything we know about Firefox 120 in this PR so we could look at its release as a whole. Maybe you are right though and smaller PRs are better than this monolithic approach. We could have a release tracking issue instead that collects all information about a release and point to smaller (automatic) PRs from it.

I've been envisaging a model where you create this PR(s), they then get reviewed by people like me while we're doing docs for the release, and then merges.

Yes exactly, I chose the monolithic approach because I was hoping to have "release drivers" from browser vendors or tech writers like you look at it and tell us if we have everything for a release.

We could instead create the PRs then auto merge (or merge after cursory inspection). Writers would then retrofit fixes to specific cases afterwards if needed - for example adding a note that something is a partial implementation.
I quite like the second approach because most of the time the tests end up being correct. It might or might not be quite as accurate on submission, but likely to be a much more efficient process with fewer delays.

Yes, we could try this.

Another thing I will say is that timing matters. This PR for 120 was opened at the beginning of its beta cycle when we had almost no manual submissions from people like you or Brian or Dipika. That said, let's play with a tracking issue and smaller PRs for the 121 cycle and see if that feels better.

[hamishwillee]

That said, let's play with a tracking issue and smaller PRs for the 121 cycle and see if that feels better.

Works for me, but let's see what others want. Either way, thank you. This is going to save a lot of time and be more accurate either way.

[dipikabh]

@Elchi3, thanks for this PR!

For Firefox 120, I am working on doc updates for [HTML] implement source media. I noticed you mentioned the need for investigation around this:

<source media> for media elements: investigation needed where exactly we need to update compat data

As I've also captured in the issue comment, the BCD table does indicate support for the media attribute. However, it doesn't specify that this support varies depending on the parent element of <source>. To elaborate:

• media was initially supported in Firefox 15.
• In Firefox 53, its support was restricted to <source> elements with a <picture> parent.
• Now, with Firefox 120, the attribute is supported when <source> is a child of either <audio>, <video>, or <picture>, that is back to how it was originally implemented.

Looks like other browsers went through a similar cycle.

Do you think we should update the BCD table to include this information as notes? Had these notes been in place for previous releases, do you think the collector would have picked up these details? I guess the notes would have helped us to understand changes across releases rightaway. What do you think?

[Elchi3]

• media was initially supported in Firefox 15.
• In Firefox 53, its support was restricted to <source> elements with a <picture> parent.
• Now, with Firefox 120, the attribute is supported when <source> is a child of either <audio>, <video>, or <picture>, that is back to how it was originally implemented.

Thanks for researching this, Dipika! 🎉 I think this sort of behavior-related stuff is hard for us to automate. That said I think it would be cool if we could have notes added to html.elements.source.media and introduce three ranges for Firefox 15-53, Firefox 53-120, and Firefox 120+. I can try that in this PR or we make that happen in a separate PR if you want to open one. Let me know. Thanks again for finding this out!

[hamishwillee]

FYI @Elchi3 Just added Sec-GPC HTTP header and the navigator property which are only on desktop. Don't know why not picked up by your scripts for at least the navigator change. See https://bugzilla.mozilla.org/show_bug.cgi?id=1856029

[Elchi3]

Don't know why not picked up by your scripts for at least the navigator change.

I think it is because the collector uses WebIDLs from W3C's webref. GPC is not an official spec, so therefore it is not in the webref project.

[dipikabh]

we could have notes added to html.elements.source.media and introduce three ranges for Firefox 15-53, Firefox 53-120, and Firefox 120+.

Thanks for the hint, @Elchi3. I've opened a PR to add the note: #21158. I tried adding three separate notes but I was getting validation errors. I've retained one note to convey the support info.

[Elchi3]

• css.properties.text-wrap.balance: need to add manually

I think this is the only thing we have not done in this PR or in a separate PR.

If otherwise everyone is happy with the state of the Firefox 120 updates done here, we could merge this in if you like! Thanks everyone for your feedback, hoping to make this as smooth as possible in the future for you all!

[hamishwillee]

I'm happy for it to merge - we can always iterate and this ensures that the data will be up to date on the site when the release happens.

[Elchi3]

As discussed this morning, we should run the collector when browsers hit the beta stage and then again when they hit the release stage. Today I checked if there is any difference to from Firefox 120 beta to Firefox 120 stable. There isn't much:

• The collector found one more thing to document for Firefox 120: Window.sizeToContent is gone.
• Not found by the collector but by Tomayac: Firefox 120 supports WasmGC.