Show script source messes up character encoding

[JasonBarnabe]

GM 2.0b2, Firefox 30 on Ubuntu.

https://greasyfork.org/scripts/2665-贴吧模组屏蔽/code.user.js with Greasemonkey disabled:

// ==UserScript==
// @name        贴吧模组屏蔽

With Greasemonkey enabled, after pressing Show script source:

// ==UserScript==
// @name        贴�模组�蔽

[wenketel]

character encoding ？

[janekptacijarabaci]

The URL of a web page vs. the local file URL.

However, this did not help:

https://github.com/greasemonkey/greasemonkey/blob/master/modules/remoteScript.js#L432

  var tab = aTabBrowser.loadOneTab(
      ioService.newFileURI(this._scriptFile).spec,
      {'inBackground': false});

  var tab = aTabBrowser.loadOneTab(
      ioService.newFileURI(this._scriptFile).spec,
      {'inBackground': false, 'charset': 'UTF-8'});

(all scripts must be encoded with UTF-8)

But this works:

about:config

from:

intl.charset.detector = ""

to:

intl.charset.detector = "universal_charset_detector"

http://www-archive.mozilla.org/projects/intl/chardet.html
Not build by default yet. Waiting for super review.

You are currently viewing a snapshot of www.mozilla.org taken on April 21, 2008
I don't really understand why it still doesn't work.

[arantius]

So:

$ curl -I https://greasyfork.org/scripts/2665-%E8%B4%B4%E5%90%A7%E6%A8%A1%E7%BB%84%E5%B1%8F%E8%94%BD/code.user.js
HTTP/1.1 200 OK
Content-Type: text/javascript; charset=utf-8
...

When the file comes from the server, it gets a header saying that it's UTF-8. When we navigate the browser to the stored file, it has no such header. IOW right click and save the link given in the original description, disable GM (if necessary) and open it in Firefox. You'll get the same thing.

In this case at least, Firefox guesses wrong about the encoding. It would be nice to be able to force it to use UTF-8, because in other places, that is already the only encoding that Greasemonkey supports for scripts. @janekptacijarabaci obviously tried to do that but it didn't work?

[janekptacijarabaci]

Yes, it does not work, and I don't know why.
https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/Method/loadOneTab

[Ventero]

I've looked through the code that's executed when loadOneTab is called and it looks like the relevant part where the charset should be set is in browser#loadURIWithFlags. The reason why this doesn't work is that the assignment to docShell.parentCharset throws an exception:

[Exception... "Cannot modify properties of a WrappedNative"  nsresult: "0x80570034 (NS_ERROR_XPC_CANT_MODIFY_PROP_ON_WN)"  location: "JS frame :: debugger eval code :: <TOP_LEVEL> :: line 1"  data: no]

The try/catch around that part suggests that this might be expected behavior, but I couldn't find any tests for this, and hg blame wasn't very helpful either.

When unwrapping the docShell with XPCNativeWrapper.unwrap first, setting the charset works as expected.

Edit: Not sure why I thought unwrapping helped, as the interface doesn't even contain parentCharset anymore. Either way, I guess this is another upstream bug.

[Ventero]

Reported upstream as https://bugzilla.mozilla.org/show_bug.cgi?id=1046335