Audio loaded through @resource no longer playing. FF42/GM3.5 #2326

Closed
daniels1989 opened this Issue Nov 5, 2015 · 12 comments

Projects

None yet

5 participants

@daniels1989

I load a small audio file through @resource/GM_getResourceURL, and while it returns a GM string and inserts it correctly into each source element, it wont actually play the files anymore. Loading images still works as normal.

Firefox 42
Greasemonkey 3.5

Small test script with two audio files and an image: https://dl.dropboxusercontent.com/u/936879/test.user.js

@daniels1989 daniels1989 changed the title from Audio loaded through @resource no longer playing. to Audio loaded through @resource no longer playing. FF42/GM3.5 Nov 5, 2015
@janekptacijarabaci
Contributor

This is not the bug of GM (AFAIK).

  1. "<sound>" => "<source>"

error_002

The following works:

<source src="https://dl.dropboxusercontent.com/u/936879/test.mp3" type="audio/mpeg"></source>
<source src="https://dl.dropboxusercontent.com/u/936879/test.ogg" type="audio/ogg"></source>
@daniels1989

woops, that was an error in the test script. changed it to . Now it wont even show the controls though. Like, it briefly shows and then fades out.

@janekptacijarabaci
Contributor

Like, it briefly shows and then fades out.

Ad 2)
Throws an error in the Browser Console...

I suppose that's associated.

This gives the same result:

<audio controls>
<source src="" type="audio/mpeg"/>
<source src="" type="audio/ogg"/>
</audio>
@daniels1989

So it's acting like GM strings aren't valid anymore for audio/source tags. Because this doesnt work in FF42/GM3.5, whereas it does work in FF41/GM3.5 (just tested that)

<source src="greasemonkey-script:7ca92a11-b6cc-45a9-b728-23bdf2c28c68/b" type="audio/ogg">

Using the full url obviously works in both firefox versions.

<source src="https://dl.dropboxusercontent.com/u/936879/test.ogg" type="audio/ogg">
@arantius
Collaborator
arantius commented Nov 8, 2015

This is a bug, but as you've reported it happens when changing FF version and keeping GM stable, it's probably not ours. https://bugzilla.mozilla.org/show_bug.cgi?id=1222761

@arantius arantius added this to the Tracking Upstream milestone Nov 8, 2015
@the8472
Contributor
the8472 commented Nov 8, 2015

There seem to be a few new flags in nsIProtocolHandler I wonder if they would make a difference.

@janekptacijarabaci
Contributor

Ad https://bugzilla.mozilla.org/show_bug.cgi?id=1222761#c4

For example: https://github.com/janekptacijarabaci/greasemonkey/tree/_testBranch_scriptProtocol

channel.originalURI.spec = file://...mp3(ogg)
channel.loadFlags |= Ci.nsIChannel.LOAD_REPLACE

Unfortunately, I see no difference.

@Ventero Ventero added a commit to Ventero/greasemonkey that referenced this issue Nov 10, 2015
@Ventero Ventero Set originalURI for greasemonkey-script: protocol channels.
Fixes #2326.
690364b
@Ventero
Contributor
Ventero commented Nov 10, 2015

As comments 1 and 4 on the upstream bug report reference, the actual issue is that we don't set the originalURI on the channel, which means the protocol handler actually treats it as a file URI channel.

Setting the originalURI to the URI the channel was requested for seems to indeed fix the problem (Ventero@690364b).

URI_SAFE_TO_LOAD_IN_SECURE_CONTEXT is only relevant for loading http (or other insecure) content in a secure (i.e. https) environment.

@arantius
Collaborator

Thanks for confirming @Ventero !

@janekptacijarabaci
Contributor

Oh, so it has to be reversed... (yes, also https://bugzilla.mozilla.org/show_bug.cgi?id=1222761#c1 - why I hadn't noticed it before...) :-) originalURI = (file://... => greasemonkey-script://...)

@arantius arantius modified the milestone: 3.6, Tracking Upstream Nov 11, 2015
@arantius arantius closed this in 0c8e9c7 Nov 11, 2015
@daniels1989

That was fast. Thanks everyone. ^^

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment