New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Script event listeners won't run in FF28 if site JavaScript is disabled. #1882

Closed
trespassersW opened this Issue Feb 28, 2014 · 14 comments

Comments

Projects
None yet
5 participants
@trespassersW
Copy link

trespassersW commented Feb 28, 2014

Firefox/28.0b6 Greasemonkey 1.15
Actually, script's initialization code runs normally but all event hooks are banned.
More details in USO forum discussion; Unit Test.

@janekptacijarabaci

This comment has been minimized.

Copy link
Contributor

janekptacijarabaci commented Feb 28, 2014

See #1867 (duplicate)

@trespassersW

This comment has been minimized.

Copy link

trespassersW commented Mar 21, 2014

The problem seems disappeared in FF29b.

@arantius arantius modified the milestone: 1.17 Mar 21, 2014

@arantius

This comment has been minimized.

Copy link
Collaborator

arantius commented Mar 21, 2014

Confirmed, the linked test WFM in Firefox 29 (Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 Built from https://hg.mozilla.org/releases/mozilla-beta/rev/904eb7fb178c ).

@trespassersW

This comment has been minimized.

Copy link

trespassersW commented Mar 22, 2014

.. The problem seems disappeared in FF29 ..
I was wrong. GM scripts don't work in FF29b if JS disabled.

@alice0775

This comment has been minimized.

@trespassersW

This comment has been minimized.

Copy link

trespassersW commented Mar 25, 2014

@erosman

This comment has been minimized.

Copy link

erosman commented Mar 27, 2014

Something has happened ...

For the last couple of days, all of my scripts that had the issue in FF28.0 + GM 1.15 (Win7) ie using setTimeout, addEventListener etc with JavaScript disabled, are working again and I haven't done anything
No FF upgrade
No GM upgrade
No script change
NoScript 2.6.8.19 was updated March 24, 2014

Is it possible that the issue is related to NoScript?
Has anyone else had the same experience?!

@arantius arantius modified the milestones: 1.16, 1.17 Mar 28, 2014

@arantius

This comment has been minimized.

Copy link
Collaborator

arantius commented Mar 28, 2014

I'm quite sure that commit a0d93c5 fixes this. Please visit https://addons.mozilla.org/en-US/firefox/addon/greasemonkey/versions/?page=1#version-1.16beta2 and try out version 1.16beta2 if you are seeing this issue, and let me know whether it helps.

@arantius

This comment has been minimized.

Copy link
Collaborator

arantius commented Mar 28, 2014

Oh and, there's some discussion at http://bugzil.la/986886 about whether this should possibly also apply to non-privileged (@grant none) scripts or not. Please let me know if you observe different behavior between privileged and non-privileged scripts.

@trespassersW

This comment has been minimized.

Copy link

trespassersW commented Mar 28, 2014

Fx28, clean profile, GM 1.16beta, javascript.enable=false :
// @grant GM_something
userscripts are working normally
// @grant none
event handlers aren't working

@trespassersW

This comment has been minimized.

Copy link

trespassersW commented Mar 28, 2014

and yet another curious fact:
in NoScript 2.6.8.19 under Fx28+GM1.15, GM scripts keep working regardless of site's enable/disable JS setting and @grant.

@arantius

This comment has been minimized.

Copy link
Collaborator

arantius commented Apr 7, 2014

I've still got some details to figure out to make sure this works everywhere as expected, but: the short version is that it is intended that in the @grant none case, the user script performs just like any content script running on that page. For a bunch of reasons. Not working when javascript is disabled may be a natural consequence of that.

@arantius

This comment has been minimized.

Copy link
Collaborator

arantius commented Apr 8, 2014

See commit a0d93c5 which is probably the fix for this. Note at http://bugzil.la/986886#c4 :

... now that we've fixed various bugs, don't run when JS is disabled for content.

Also watch #1904; I've run some tests that affect both bugs and I've recorded the results there. But I fear that the upshot is that Firefox is changing underneath us, and we have no choice to break backwards compatibility. Note that the only "everything works" lines there are for javascript-enabled and non-privileged scripts.

If we add expanded principals to @grant none scripts, then various things will break. Which leaves only a judgment call: is breaking when javascript is disabled, or always breaking when those features are used worse? I don't think we can get both.

@arantius

This comment has been minimized.

Copy link
Collaborator

arantius commented Apr 8, 2014

Continuing the test from #1904:

Firefox Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 (beta), "Built from https://hg.mozilla.org/releases/mozilla-beta/rev/072687c58007".
Greasemonkey as of 6ebb131 .


As is, JS enabled: everything works.
As is, JS disabled: nothing works.

Then I patched GM so non-privileged scripts get expanded principals as well:

Patched, JS enabled: Everything but obj.cb() from the content scope works.
Patched, JS disabled: Only the event listener set up in the script works.


Before the patch, things make a lot of sense. For a non-privileged script, everything behaves as expected. Disabling javascript disables javascript, no surprise. Adding expanded principals in makes the behavior complex and more difficult to predict/understand. I think JS disabled is a niche-enough use case that I have to pick scripts running as expected in all (other) cases as the feature to support.

@arantius arantius closed this Apr 8, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment