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

daniels1989 opened this Issue Nov 5, 2015 · 12 comments


None yet

5 participants


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:

@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

This is not the bug of GM (AFAIK).

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


The following works:

<source src="" type="audio/mpeg"></source>
<source src="" type="audio/ogg"></source>

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.


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

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="" type="audio/ogg">
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.

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

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



For example:

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


Thanks for confirming @Ventero !


Oh, so it has to be reversed... (yes, also - 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

That was fast. Thanks everyone. ^^

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