The title of this issue is misleading. When I read it I thought you meant the file is being encoded twice with the same type of encoding.

Anyway, once the file has been Base64 encoded, the URI encoding is probably unnecessary.

I'm -1 for changing GM_getResourceURL at this point, because we don't have evidence that it won't affect existing user scripts, and there is a note in the docs for this api, which says:

Note: This can be used anywhere a data: URI will work (E.G. or <script>). This does not include or .

It's GM_getResourceURL btw, not GM_getResourceURI, no big deal though.

I see three options:

1. wontfix
2. create a new GM_ method to do the same as GM_getResourceURL but without the call to encodeURIComponent
3. create a new GM_ method which returns a ref to an object that represents the resource, and which has methods on it to getText, getResourceURL, getResource (same as getResourceIURL but w/out encodeURIComponent), size, and other properties/methods that may seem fit later so that we don't need to create new GM_ methods for resources in the future.

I'm +1 for 1, 0 for 2, and 0 for 3.

we don't have evidence that it won't affect existing user scripts

Using standard Base64 in URL requires encoding of '+' and '/' characters into special percent-encoded hexadecimal sequences ('+' = '%2B' and '/' = '%2F'), which makes the string unnecessarily longer.

There are two factors that lead up to this submission:

1. The documentation did not explicitly state that GM_getResourceURL was going to return a base64 string that was going to be URI encoded.
2. Firefox will accept URI encoded data for images, but evidently not sound files (in this case: wavs in embeds), as it tries to process the percent-encoded hex sequence as raw data.

Because both of these don't blend well with each other, this produces a sole instance where it is required to decode a resource. My suggestion is as follows:

• Correct the documentation and make note of this incident in it.
• Forward this issue to the Firefox team as this seems to be a problem with Firefox's implementation of data URIs.

Docs updated. http://wiki.greasespot.net/GM_getResourceURL#Returns

Otherwise, no change, for backwards compatibility. And although I can't find a reference that definitively says this is right, I can't find one that says it's wrong either, and it feels right to me. (You've gotta escape special characters -- it's just not clear if + and / are "special" in this context or not.)