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

[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

[janekptacijarabaci]

This is not the bug of GM (AFAIK).

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

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]

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">

[janekptacijarabaci]

(AFAIK) See https://hg.mozilla.org/mozilla-central/rev/f4fa8c49ebc6

See also https://bugzilla.mozilla.org/show_bug.cgi?id=1161831

[arantius]

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

[the8472]

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

[janekptacijarabaci]

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]

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]

Thanks for confirming @Ventero !

[janekptacijarabaci]

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://...)

[daniels1989]

That was fast. Thanks everyone. ^^