Ocornu Webmonkey

Comments and changes to this ticket

• You flagged this item as spam.
  

  Erik Vold March 22nd, 2010 @ 03:14 PM

  I've made a simple test case here which works in GM and produces the following error in WM:

  Error: Webmonkey access violation: file:///C:/github/webmonkey/src/modules/script/xhr.jsm cannot call GM_getValue().
  Source File: file:///C:/Documents%20and%20Settings/erikvold/Application%20Data/Mozilla/Firefox/Profiles/elr5khso.erikvold/userscripts/wm_ticket_19_test_case/wm_ticket_19_test_case.user.js
  Line: 22

• You flagged this item as spam.
  

  Erik Vold March 22nd, 2010 @ 03:14 PM

  • Tag changed from “#bug” to “#annoyance, #bug, :big”
  • Assigned user set to “Olivier Cornu”

• You flagged this item as spam.
  

  Erik Vold March 22nd, 2010 @ 03:15 PM

  • Assigned user cleared.
• 

  Olivier Cornu March 22nd, 2010 @ 03:44 PM

  • Assigned user set to “Olivier Cornu”

  Interesting. I don't recall changing many things in the xhr code, i'm curious to see where this comes from…

  Edit:
  Alright, it's not the xhr code: it's probably the apiLeakCheck code.
  I wish i could see the stack filenames (line 177) -- can't test it now.

• You flagged this item as spam.
  

  Erik Vold March 22nd, 2010 @ 04:09 PM

  Well the errors above are generated when the GM_getValue() function does the api check, and the api check function does appear to be slightly different..

  • For GM: /components/greasemonkey.js line 43
  • For WM: /modules/script/api.jsm line 177

  A difference appears to be between using the following for Greasemonkey:

  stack.filename != gmSvcFilename
  

  And the following for Webmonkey:

  stack.filename != FILE && this._files.indexOf(stack.filename) == -1
  

  I'm not sure if that makes any difference yet though..

• You flagged this item as spam.
  

  Erik Vold March 22nd, 2010 @ 04:11 PM

  bah I can't seem to edit my previous comment.. -1 point for lighthouse.. I meant apiLeakCheck* where I said "api check function"..

• You flagged this item as spam.
  

  Erik Vold March 23rd, 2010 @ 06:45 AM

  Well I was able to identify the problem..

  GM /components/greasemonkey.js line 48 is stack.filename != gmSvcFilename where gmSvcFilename is file:///C:/github/greasemonkey/components/greasemonkey.js for my test and stack,filename is chrome://greasemonkey/content/xmlhttprequester.js so line 48 fails, but line 49 stack.filename.substr(0, 6) != "chrome" is true in that case.

  WM /modules/script/api.jsm line 180 is stack.filename != FILE where FILE is file:///C:/github/webmonkey/src/modules/script/api.jsm and stack.filename is file:///C:/github/webmonkey/src/modules/script/xhr.jsm when the error is thrown.

• You flagged this item as spam.
  

  Erik Vold March 23rd, 2010 @ 07:24 AM

  One solution would be to export Components.stack.filename from xhr.jsm in some variable which is added to the if check started on line 177. The xhr.jsm is only used in api.jsm.

• 

  Olivier Cornu March 23rd, 2010 @ 11:41 AM

  Alright, good catch. :-)

  In GM, every sub-script is loaded inside the GM service XPCOM thanks to mozIJSSubScriptLoader, thus appearing with a chrome:// URI in the call-stack. Whereas in WM, the script engine is divided in JS modules, which appear under their own file:// URI.
  Injection logic is also different: GM concatenates all userscript files (including its dependencies) in a string that is passed to evalInSandbox(), whereas WM uses a new evalInSandbox syntax that is called for each userscript file in turn. It makes for simpler and more accurate error-reporting code, and allows Firebug debugging of userscripts and their dependencies.
  Altogether, it makes for a slightly different approach to apiLeakCheck(). Of course it does not change its purpose: we must still make sure that calls to privileged GM API do not include a un-privileged URI in their stack. Privileged URI are either chrome, current userscript files, or the api.jsm file where all GM API functions are located.

  One solution would be to export Components.stack.filename from xhr.jsm in some variable which is added to the if check started on line 177.

  Yes, some trick like this is needed.
  An alternative would be to put xhr code into api.jsm, as it's only used there anyway. This way we'd stick to the current philosophy: api.jsm includes all API functions as well as API objects.

  bah I can't seem to edit my previous comment.. -1 point for lighthouse..

  Really? I could edit mine without problems yesterday…
  Perhaps there's an "edit timeout"?

• You flagged this item as spam.
  

  Erik Vold March 23rd, 2010 @ 12:17 PM

  An alternative would be to put xhr code into api.jsm, as it's only used there anyway. This way we'd stick to the current philosophy: api.jsm includes all API functions as well as API objects.

  I like this idea, the api.jsm file is a place that makes sense for this code imo.

  bah I can't seem to edit my previous comment.. -1 point for lighthouse..

  Really? I could edit mine without problems yesterday… Perhaps there's an "edit timeout"?

  I don't see an 'edit' link anywhere..

• 

  Olivier Cornu March 23rd, 2010 @ 12:27 PM

  I like this idea, the api.jsm file is a place that makes sense for this code imo.

  Yes.
  By the way, the xhr code could use some cleaning too. :-)

  I don't see an 'edit' link anywhere..

  I see one on your post! Perhaps i'm the only one (admin) who can edit stuff?

• 

  Olivier Cornu March 23rd, 2010 @ 05:54 PM

  • State changed from “new” to “resolved”

  (from [058a6a1ca3a3ef34c66e5503dfcb36a90dd04f8e]) Fixes API access violation on XHR [#19 state:resolved]

  All API related code moves into api.jsm.
  http://github.com/ocornu/webmonkey/commit/058a6a1ca3a3ef34c66e5503d...