Ubiquity conflicts with Greasemonkey

[esquifit]

I have recently found a collision between Ubiquity and Greasemonkey,
see [1]. The root of problem is that the Ubiquity script is executed
from a file: url instead of from a chrome: url, in this case:

file:<profile_folder>/extensions/ubiqu...@labs.mozilla.com/modules/
sandboxfactory.js#http://gist.github.com/98514.txt

Is there a design or technical reason for that, or could this
conceivably be changed to a chrome url?

[1] http://groups.google.com/group/greasemonkey-dev/browse_thread/thread/6a6c4e7a0d5fabef

[satyr]

Hm, I can't seem to reproduce it. This snippet worked fine for me.

function cmd_testUserScriptCommand(){
var mi = (Utils.currentChromeWindow.document
.querySelector('#userscript-commands-sb > menupopup > menuitem'));
mi && mi._commandFunc();
}

[esquifit]

Hi satyr,
thanks for taking the time to look over this. Your snippet and my
script both work fine with most GM scripts. The problem arises when
the GM menu command invoked from Ubiquity uses some GM_* API function.
In order to reproduce it with your snippet, you have to create a
one-line Greasemonkey script like

GM_registerMenuCommand('foo', function(){ GM_setValue('bar', 42) });

and ensure you place the script *first* in the script list (this is
because your snippet executes the first menu command it encounters; if
you have more than one, you have to place the GM script above in the
list to ensure the menu command get registered first as well.)

If you do that, you'll see in the error console:

Error: Greasemonkey access violation: unsafeWindow cannot call GM_setValue.

As I said in the GM thread, I modified the GM extension to show more
in depth information about the error. What I'm getting in this case
is:

Error:
Greasemonkey access violation: unsafeWindow cannot call GM_setValue from
file:///<profile>/extensions/ubiq...@labs.mozilla.com/modules/sandboxfactory.js#ubiquity://command-editor-code.
----------
Error:
Stack trace:

* file://<profile>/extensions/%7Be4a8a97b-f2ed-450b-b12d-ee082ba24781%7D/components/greasemonkey.js
* chrome://greasemonkey/content/miscapis.js
* chrome://greasemonkey/content/utils.js
* file:///<profile>/extensions/%7Be4a8a97b-f2ed-450b-b12d-ee082ba24781%7D/components/greasemonkey.js
*
* file:///<profile>/extensions/ubiq...@labs.mozilla.com/modules/sandboxfactory.js#ubiquity://command-editor-code

Greasemonkey then sees that the first call comes from a file: url
which doesn't belong to Greasemonkey, and disallows execution. I've
already talked the GM guys about this, but I am curious about why
Ubiquity scripts are "file:" urls and not "chrome:"

[satyr]

> If you do that, you'll see in the error console:
>
> Error: Greasemonkey access violation: unsafeWindow cannot call GM_setValue.

I see. I guess you'd have to work around it somehow, like:

function cmd_manageUserScriptCommand(){
var $s = $('<script>');
$s[0].innerHTML = <![CDATA[(function({Utils}){
var mi = Utils.currentChromeWindow.document.querySelector(
'#userscript-commands-sb > menupopup > menuitem');
mi && mi._commandFunc();
})(Components.utils.import('resource://ubiquity/modules/utils.js', null))]]>;
$s.appendTo('body').remove();
}

Ubiquity scripts are indeed "unsafe," so we can't really complain =p

> I am curious about why
> Ubiquity scripts are "file:" urls and not "chrome:"

From line 89-91 of sandboxfactory.js:

// We need to prefix any source code URI's with a known
// "protected" file URI so that XPConnect wrappers are implicitly
// made for them.

[esquifit]

Yes, this would work. The problem with this approach is that it
assumes that javascript is enabled in the page, which in my case is
not true. Fortunately I've found a workaround, see [1].

Thanks again for the pointing to the Ubiquity code of
sandboxfactory.js. Honestly, I still don't quite understand the
reason, but I'll try harder :-)

[1] http://groups.google.com/group/greasemonkey-dev/msg/4e57bda147f8b23c

[esquifit]

Sorry, I meant

http://groups.google.com/group/greasemonkey-dev/msg/fa55b0829bce8edd

On Tue, Dec 29, 2009 at 4:18 PM, esquifit <esqu...@googlemail.com> wrote:
> Yes, this would work.  The problem with this approach is that it
> assumes that javascript is enabled in the page, which in my case is
> not true.  Fortunately I've found a workaround, see [1].
>

> [snip]
>
> [1] http://groups.google.com/group/greasemonkey-dev/msg/4e57bda147f8b23c

[satyr]

> Yes, this would work.  The problem with this approach is that it
> assumes that javascript is enabled in the page, which in my case is
> not true.

You sure? The above code uses the frame where our jQuery resides,
which is at <chrome://ubiquity/content/hiddenframe.html>.

[esquifit]

You're absolutely right, sorry for answering without having properly
understood and tested first.
This definitively works too. Thank you very much!

PS: I had to replace "$" with "jQuery"; maybe in 0.1.9 the short form
"$" is not defined. Never mind.