WebAPI updates for Firefox 82

[chrisdavidmills]

Acceptance criteria

The following bugs are dev-doc-complete, BCD is updated, an entry to Firefox release notes is added, experimental features page is updated, the content has been reviewed as needed.

1. • [@hamishwillee] window.name can be used as an XSS attack vector — looks like a fairly simple update to cross-origin behavior of window.name; needs page updating to talk about it, maybe a small example, and a BCD update. Maybe also see if there is anywhere in our security pages that it would warrant a mention?
2. • [@hamishwillee] Enable MediaSession API — this is documented already, so it looks like this mostly just needs BCD updates, plus you should also check that the documentation is complete.
3. • [@hamishwillee] element.setPointerCapture should throw NotFoundError if the pointer id is invalid — not really sure what to do for this one; it's probably not big, but needs some investigation.
4. • [@hamishwillee] Refuse nested Document.execCommand() calls by default in release builds — I think this just needs a BCD entry, and nmaking sure this is noted on the execCommand() page somewhere sensible.

Total estimate: 2 days

[hamishwillee]

4. • Refuse nested Document.execCommand() calls by default in release builds — I think this just needs a BCD entry, and making sure this is noted on the execCommand() page somewhere sensible.

   • • BCD Entry: Document.execCommand - note that calls cannot be nested browser-compat-data#6842
   • • Updated execCommand page with note at beginning and against the return value.
   • • Release note - added note to DOM section

@chrisdavidmills This one ready for review.

[hamishwillee]

3. • [@hamishwillee] element.setPointerCapture should throw NotFoundError if the pointer id is invalid — not really sure what to do for this one; it's probably not big, but needs some investigation.

     • Quick review
       • The change appears straightforward - we were throwing wrong error (by spec) now we are throwing correct one. So we need BCD, Release note, and update to docs.
       • Wr.t. docs I think that right places is in setPointerCapture > Exceptions (Imo not worth having in higher level doc Pointer_events#Pointer_capture)
   • • BCD Entry: Element.setPointerCapture throws NotFoundError browser-compat-data#6843
   • • Updated setPointerCapture > Syntax > Exceptions - In "Exceptions" table changed exception to new value (NotFoundError) and added note about the exception used in earlier versions.
   • • Release note - added note to DOM section

@chrisdavidmills This one ready for review.

[hamishwillee]

1. • [@hamishwillee] window.name can be used as an XSS attack vector — looks like a fairly simple update to cross-origin behavior of window.name; needs page updating to talk about it, maybe a small example, and a BCD update. Maybe also see if there is anywhere in our security pages that it would warrant a mention?
     • Quick Review - 12 years of history on this one!
       • The problem is that window.name was shared among all pages loaded into the tab. This was providing:
         • an uncontrolled/risky mechanism mechanism for cross-domain sharing, which that was leveraged by some frameworks.
         • potential for a bad actor to get information that was stored by sites in window name "for convenience".
         • potential for a bad actor inject information into that value that might then be used by original origin.
       • The relevant change appears to that window.name is reset to an empty string when a tab opens content from another origin than the first page.
   • • BCD Entry
   • • window.name - extended the note section with a clear note that the browser will reset the windows.name on cross-domain load. This also explains why, and the version that is first impacted.
   • • Maybe also see if there is anywhere in our security pages that it would warrant a mention?
       • Decided not to. The logical place might be Web > Security in section on User information security or Data security with some general note "don't store important data where it might be visible to an untrusted page". But then the problem is now fixed - and without the problem the general suggestion isn't helpful
   • • Release note - added similar not to one in windows.name to DOM section. Note, I added comment "may impact frameworks that use window.name for cross-framework messaging - I figure we should highlight this.

@chrisdavidmills This one is now ready for your review

[hamishwillee]

2. • [@hamishwillee] Enable MediaSession API — this is documented already, so it looks like this mostly just needs BCD updates, plus you should also check that the documentation is complete.

   • • BCD Entry: MediaSession enabled all builds from FF82 browser-compat-data#6845
       • In discussion with BCD team
   • • Docs
       • Spec is still marked draft as is the BCD status of API, so have not modified experimental status notes anywhere. Note however that the bug fix removed it from the "experimental features list".
       • I have done basic review and done a few minor subedits. But the docs appear to cover the spec. There is no information related to this being enabled by preferences, so no "specific" change required.
       • • Review Media Session API
       • • Review MediaSession
       • • Review MediaSessionActionDetails - is importing syntax heading from MediaSessionAction but is also importing following sections.
       • • Review MediaSessionAction
   • • Release note - added note to Media, WebRTC, and Web Audio section

[chrisdavidmills]

Thanks @hamishwillee. Looks like most of this has been done fine. I have made a few edits to the pages to tighten up the prose a bit, and made some suggestions on improving the BCD for the MediaSession API.

I think it'd be great if @Rumyra looked at the MediaSession docs and thought about if anything is missing, if it needs better examples, etc.

[hamishwillee]

@chrisdavidmills Thank you. FYI, have acted on your BCD suggestions for MediaSession API - waiting for review Thanks for tidying prose; I did various changes along the way too, but mostly "to my taste".

Agree, very pleased if @Rumyra look has a look too. @Rumyra note that the BCD for MediaPositionState has now been updated, but until that goes in you'll see the table missing in the docs.

[Rumyra]

Thanks both, I'll check out the MediaSession docs now

[chrisdavidmills]

Cool, cheers @Rumyra , and thanks @hamishwillee for your continued work.

[Rumyra]

Just moved this back whilst I get some good code examples in

[Rumyra]

I've written a demo and added a pr to dom-examples for it...

I've updated all of the code examples within the API pages to be consistant and show the relevant code where appropriate.

The task for the future is to write up the demo as a tutorial (added as a task in web apis project), for which I have already made notes 👍

[chrisdavidmills]

@Rumyra the demo is great, and works really nicely on Chrome and Firefox. The only thing I was wondering about is — isn't one of the main points of the Media Session API to provide meta data about tracks that can be easily shown in notifications? therefore, would it make sense to add some Notifications API code to the demo so that when a track changes, a system notification is shown to display details of the next track?

[chrisdavidmills]

@Rumyra hi Ruth! I can't remember exactly what was said when we chatted about this, but I believe that we agree that the MediaSession docs were complete for their basic purpose, right? And that anything left, like adding a basic tutorial and figuring out a more advanced version with notifications or whatever could be left to an advanced tutorial?

In which case, shall we close this one, and then you can submit sprint issues for the tutorials?

[Rumyra]

Yes that's it :D I've added an issue to the Web APIs project, so once we've cleared the release issues I can go back and spend some more time making an explainer - see #3797

[chrisdavidmills]

@Rumyra perfect, thanks!

[Rumyra]

Just moved this to 'done' as it's closed 👍