"Magic button" Failure? about gm_config HOT 4 CLOSED

Just a note... this seems to work okay in squeeky clean profiles from:

Mozilla/5.0 (X11; Linux x86_64; rv:20.0) Gecko/20100101 Firefox/20.0

Mozilla/5.0 (X11; Linux x86_64; rv:21.0) Gecko/20100101 Firefox/21.0b4

Some underlying questions still remain though... whether or not to use this alternate method instead of setTimeout and eval... and/or limit the value to Function Objects.

This is going to be interesting trying to pin down which Add-on is causing this in my running profile. :S

So the underlying questions are:

• What ramifications can you see to using the parens instead of eval and setTimeout?
• Should there be a restriction on GMCs setTimeout if kept?

from gm_config.

What ramifications can you see to using the parens instead of eval and setTimeout?

We only used the setTimeout to avoid triggering GM's security violations. GM does a stack check when using GM_* functions and the onclick event listener is triggered from content scope even though it's set in sandbox scope. The ramifications of using parens instead are that you won't be able to access any GM_* functions in the callback function.

Should there be a restriction on GMCs setTimeout if kept?

...
    'magic': {
        'label': 'Magic Button',
        'type': 'button',
        'click': function() { alert('hey!'); }
    },
...

Maybe we could even add a "hover"?

from gm_config.

GM does a stack check when using GM_* functions

Yah I remember this part...

and the onclick event listener is triggered from content scope even though it's set in sandbox scope.

and sounds familiar but...

and the onclick event listener is triggered from content scope even though it's set in sandbox scope.

... if I add a GM_log to the GMC Unit Test function:

...
    'magic': {
        'label': 'Magic Button',
        'type': 'button',
        'script': function() {
          alert('hey!');
          GM_log('hey');
          GM_addStyle('body { background-color: #f00; }'); 
        }
    },
...

and change to line above in GMC to:

...
if (typeof scr == 'function') scr();
...

... it does actually output to the error console with JavaScript disabled via NoScript:

...
sizzlemctwizzle/The GM_config Unit Test: 
hey
...

after I fix the @include patterns since IANA keeps changing their URI (http://example.iana.org/ currently for me) rewrite to:

...
// @include  /^https?:\/\/.*?.iana.org\/?.*/
// @include  http://*.iana.org/*
// @include  https://*.iana.org/*
...

Did something change that we all (or just me) missed?

EDIT: I did change the GMC line back to its original, enabled site JavaScript, and it still works in the body of the IANA document not the iframe with GM_addStyle... so I don't think I'm grasping what advantage this has other than GM/FF backwards compatibility. How far back do you want to support? I am slowly upping my minversion on most of my scripts since upstream Moz is finally catching up with ECMAScript 6 proposed standards (and almost nearly all ECMAScript 5).

EDIT: // @grant none of course prevents any GM_ functions as expected and throws the exceptions.

Maybe we could even add a "hover"?

IDK I'm still new to this part. Although not sure what a hover (mouseover eventlistener I assume) would achieve. I'll defer to your expertise on this decision since you have been working with GMC longer than I have.

from gm_config.

The workaround I was providing seems to no longer be an issue in new versions of Firefox, so to hell with it, we're going to use direct invocation. I'm not the one who originally added this feature and if it had been me, I would have never allowed eval. It's unsafe and unnecessary, backwards compatibility be damned. If anyone wants that they can always use that other fork of GM_config.

from gm_config.