550557 - Move the JavaScript code inside the audio/video controls XBL binding to chrome to make them work on pages where JavaScript is disabled

Status: RESOLVED DUPLICATE of bug 449358

(Toolkit :: Video/Audio Controls, defect)

Description

[(no longer active)]

I discussed this during the Firefox work week with Dolske and Sicking.  We can move the JS code inside the XBL to chrome, so that we can make them work for pages on which JS execution is disabled.

We may need specialized events from the content for when a new audio/video element is created, so that the chrome code doesn't have to listen for any element being created, and still be able to register the new elements with the chrome code.

Comment 1

[Justin Dolske [:Dolske]]

Yeah, this is basically what I thinking in bug 449358 comment 16, and what we ended up doing for the revised plugin-crashed UI (bug 538910).

The media-element-created event and hooking up the media event listeners should be fairly simple, but I suspect it might be a little tricky to deal with the other two bindings in videocontrols.xml (as well as other bindings implicitly pulled in by the UI elements). I'm also a bit wary of introducing attack surface by having chrome-privileged code involved with the already-complex media API.

But even if those issues are insurmountable, another option might be to have a simplified set of chrome-driven video controls for when JS is disabled. EG, just a simple play/pause button. That might even be preferable, as I don't think it's worth spending a lot of time on this for the small number of users with JS disabled. [OTOH, if this is driven by the desire to disable XBL-in-content, the cost/benefit analysis may have a different outcome.]

Comment 2

[Jared Wein [:jaws] (please needinfo? me)]

This is basically bug 449358, just a matter of how it is implemented.