[Fixed] [Click2Allow] Not working properly in FF Nightly

[anotheroneofthese]

First of all happy new year and thanks for the continued development of NSS,

using any Firefox Nightly version (only tested till v35 so I'm assuming here, with E10s disabled), I'm unable to allow an a video element by left-clicking on it, the page refreshes but the object stays blocked just the same way. Coincidentally, right-clicking on the NSS toolbar icon -> Blocked Objects -> Temporarily allow <name>.webm works just fine. And if this wasn't weird enough, any normal/release/public/deploy version of the Firefox does not carry this issue, and left clicking on the element allows it just fine, for instance FF 40 Nightly presents the issue and FF 40 Release does not (again E10s disabled on everything).
I'm not sure whats going on here, I've tried clean installs of both branches and different version with default settings on both and only NSS as an extension with even the same settings shared between NSS installs, currently I'm using this on the regular release of FF 42:

Code: Select all

user_pref("noscript.ABE.migration", 1);
user_pref("noscript.ABE.notify", false);
user_pref("noscript.ABE.wanIpAsLocal", false);
user_pref("noscript.autoReload", false);
user_pref("noscript.clearClick.prompt", false);
user_pref("noscript.confirmUnblock", false);
user_pref("noscript.firstRunRedirection", false);
user_pref("noscript.forbidFrames", true);
user_pref("noscript.forbidIFrames", true);
user_pref("noscript.forbidMetaRefresh", true);
user_pref("noscript.forbidMetaRefresh.notify", false);
user_pref("noscript.gtemp", "");
user_pref("noscript.hoverUI", false);
user_pref("noscript.notify", false);
user_pref("noscript.notify.bottom", false);
user_pref("noscript.options.tabSelectedIndexes", "5,5,0");
user_pref("noscript.showAbout", false);
user_pref("noscript.showAllowPage", false);
user_pref("noscript.showDistrust", false);
user_pref("noscript.showGlobal", false);
user_pref("noscript.showRecentlyBlocked", false);
user_pref("noscript.showTempToPerm", false);
user_pref("noscript.showUntrusted", false);
user_pref("noscript.showVolatilePrivatePermissionsToggle", false);
user_pref("noscript.subscription.lastCheck", -80960170);
user_pref("noscript.temp", "");
user_pref("noscript.version", "2.9");
user_pref("noscript.visibleUIChecked", true);
user_pref("noscript.xss.notify", false);

and while this works fine, it does not on FF Nightly 46 (with E10s disabled) (or any other previous version for that matter).

As an example follow this example video url, with the above settings, left-clicking on it allows and plays the video on regular FF, on FF Nightly it refreshes the page and stays the same (using the blocked objects sub-menu to allow it works).

Not sure what else to say other than I am unsure of what is going on.

Hope this is an easy fix, thanks.

[barbaz]

First step is to compare in detail a Nightly & the corresponding Release version, see if Nightly enables other things or if other prefs, defaults, and/or built-in settings differ.

[anotheroneofthese]

Already did that (well sorta, I didn't compare source code since I'm not that familiar with the FF or NSS codebase to do so), using/sharing the same profile/settings between both FF builds yelds the same results: works on release, not on nightly. I've tested this so for far on the past 8 or so versions, exactly the same.
The thing that strikes out the most is that the menu entry does whats it's suposed to do, it's just the "left-click on object to allow" that fails (without any erros/warnings on console btw).
Is it possible that the nightly builds add some overlay above the NSS blocked object and the left-click is processed by that (inspect element shows nothing)? But then again, this issue was present on FF Nightly 38, while the latest FF release version (42, or the ones before) does not present this issue.

I really don't know what the cause is (either on FF or NSS), but after I tried using/testing the Nightly branch this issue keeps me from using/testing it more often (please note that all this was tested/done with E10s disabled).

I hope this can be fixed, but for now I will keep using the release version of FF, thanks again.

[barbaz]

What you describe doesn't sound like an overlay.. I'm thinking more along the lines of Nightly might be killing an event listener or something like that. If you post a link to a specific official Nightly build where you see the issue, I will look into this as soon as I get the chance. The more recent the linked build is the better, but please pick one that's already gone all the way through to release so that we have Developer edition / Aurora channel & Beta channel versions available as well in case it's helpful for comparison.

offtopic: Can you please abbreviate NoScript as NS instead of NSS to reduce confusion? When I read "NSS" I first think NSS.
Thanks

[Thrawn]

offtopic: Can you please abbreviate NoScript as NS instead of NSS to reduce confusion?

Probably a reference to 'NoScript Security Suite'...which is still the official name on AMO, although for practical purposes we all refer to it as NoScript.

[therube]

this example video url

I'm seeing HTML5, are you seeing different (like Flash)?

How is that being blocked?
What is blocking it?
What gives you a placeholder?

with E10s disabled

OK, so that is required, otherwise you don't get any placeholder.


So is this any different from what happens at, where was it ? Yahoo perhaps, where particular settings caused looping (of the click-to-play object) & you had to use the Blocked Objects menu to get things working?


Unchecking 'Forbid Other Plugins' gets it working.
But that bypasses the placeholder altogether.


(I seem to have lost the ability to open NoScript | Options... ? Doing nothing special. Today's Nightly. Perhaps it was changing focus away from FF & back that allowed it to work again?)


FF 43 Release looks to work as expected.
So... is it Nightly or something with NoScript, or both?

[anotheroneofthese]

I'm seeing HTML5, are you seeing different (like Flash)?

It's a regular WebM video so yes I'm seing just the video, no flash or any other plugin (the VM I'm currently using doesn't even have .net nor flash nor silverlight installed, the issue is presented on a regular Win8.1 machine too with said plugins installed)

How is that being blocked?
What is blocking it?
What gives you a placeholder?

It's only being blocked by NoScript, no other plugins are installed on the browser, and by blocked I mean it's not displayed/loaded by default and there is the need to click to allow it's download/play. I'm almost sure that you get the same deal if you click on that link using NoScript default settings, since that domain is not on the default whitelist and the option to "Block AUDIO / VIDEO" of NoScript is default on.

So is this any different from what happens at, where was it ? Yahoo perhaps, where particular settings caused looping (of the click-to-play object) & you had to use the Blocked Objects menu to get things working?

I'm not familiar with that issue at all, but please take note that in this case there is no web page surrounding the video object, nor is there any whitelisted/permited scripts to block/interact with the video object. I'm sure that this is an issue with either NoScript or Nightly (or both, maybe some incompatibility).

Unchecking 'Forbid Other Plugins' gets it working.

It does indeed "fix" the issue. Reloading the page with that option ticked out loads and auto-plays the video. Tickying the box again and reloading the page presents the issue again. Is Nightly/NoScript interpreting a WebM video as "another plugin"? If I load an MP4 video I get the same issue so I don't think that is it.

So... is it Nightly or something with NoScript, or both?

Only with some debugging will we know, and I'm not sure I want to "fight that battle", for now I'm gonna continue with the regulart release of Firefox.

Thanks again.

[anotheroneofthese]

An update to the issue: after updating to Firefox v45.0 (normal release channel, from v44.0.2 I think), the issue is now also present on the regular version of Firefox, even on a clean profile with just NoScript installed (as mentioned on the OP).

Hope this can be fixed soon.

[Mike A.]

An update to the issue: after updating to Firefox v45.0 (normal release channel, from v44.0.2 I think), the issue is now also present on the regular version of Firefox, even on a clean profile with just NoScript installed (as mentioned on the OP).

I can confirm this issue is affecting FF 45.0 and NS 2.9.0.4, glad I found this thread!

Hope this can be fixed soon.

Agreed, please fix!

Thanks!

[barbaz]

FWIW there is another thread on this as well: viewtopic.php?f=7&t=21683

[anotheroneofthese]

FWIW there is another thread on this as well: viewtopic.php?f=7&t=21683

I believe it might be more helpful to mention this thread on the other one, since they are discussing website & flash being a problem starter when I've already covered in the OP that that is not the case.

The though work now is doing the bisect between the versions to track the bug down, and as mentioned in the OP this has been happening in FF Nightly since at least v35 (maybe even earlier) with nothing more than a simple WebM/MP4 video.

I really hope Giorgio Maone has some time (and patience) to work on this soon. BTW, thanks for the continuous support of NoScript, Giorgio.

[Tree]

I just wanted to say thanks anotheroneofthese for discovering and reporting this. I am coming over from the other thread and had to register to do so and keep up with this.

Thanks to the Noscript team also for all of the help and program.

[anotheroneofthese]

Another update (an even weirder one):
NoScript does not work on Nightly v48, as soon as it is installed and restarted the extension pops up a warning that it was badly installed and refuses to work, not even the configuration/settings window saves/loads settings (it still opens though). Maybe this has something to do with WebExtensions (other plugins work fine though)?
NoScript works just fine on Nightly v47 and does not present the issue mentioned in OP (clicking to unlock an element work fine/like-it-used-to), haven't tested any Nightly version prior to v47 but I might to see which changes/bug fixes might be involved.

If I/we can track down the changes/bug-fixes made in Nightly maybe this could become easier for Giorgio to solve on "weird"/bugged versions of Firefox.

[therube]

NoScript does not work on Nightly v48

viewtopic.php?p=81684#p81684

https://noscript.net/getit#devel

[anotheroneofthese]

NoScript works just fine on Nightly v47 and does not present the issue mentioned in OP (clicking to unlock an element work fine/like-it-used-to), haven't tested any Nightly version prior to v47 but I might to see which changes/bug fixes might be involved.

After trying to get NoScript + Nightly v47 to work (fine/like-it-should) on a second machine, and being unable to do so I think I've uncovered a whole can of worms that not even I can think of.

Right now I've tracked down two issues, on default settings after a new profile is created NoScript presents the issue like stated in the OP, but some setting in the prefs.js can make it work, since if I copy just this file to the new machine/profile NoScript presents no issues/bugs whatsoever.
I haven't yet discovered which settings does this, but I can already tell that I also need to have

Code: Select all

user_pref("browser.tabs.remote.autostart.2", false);

in there otherwise NoScript doesn't behave correctly, like it is allowing everything by default but the settings indicate that nothing is being allowed and changing them has no effect.

I will update this post once I'm able to find the "holy" settings... wish me luck.


EDIT:

So I've finally tracked down the setting to make NoScript work again (without presenting the bug mentioned in the OP) in, at least, Firefox Nightly v47.0a1:

Code: Select all

user_pref("extensions.interposition.enabled", false);

And just like the other setting mentioned above (which seems to disable the force-enable E10s, which was why NoScript was behaving weirdly, E10s was being force re-enable on each start without that setting) this one is also related to E10s, at least that's what I can gather from some bug reports about AdBlock Plus being broken back in 2014 when the shim this setting disables was introduced/enabled by default.
Guess this was what was being enabled in all those previous version of Nightly since v35.


So just to reiterate, NoScript (v2.9.0.4 & v2.9.0.5) will not present the bug mentioned in the OP if, on a clean profile or your current profile, prefs.js you add

Code: Select all

user_pref("browser.tabs.remote.autostart.2", false);
user_pref("extensions.interposition.enabled", false);

at least on Firefox Nightly v47.0a1.

I'll probably test the most recent version of both Nightly and the normal release of Firefox to see if with these settings on a clean profile NoScript behaves correctly.


EDIT 2:

And we've got a winner! The most recent versions of both Firefox and Firefox Nightly (v45 & v48.0a1 respectively) work just fine with the settings mentioned above and NoScript!

I'm not sure what changes disabling that shim has on other addons (other than maybe a slight performance hit, can't notice any BTW) but, at least, knowing the cause might make it easier for Giorgio to fix it, so that not so savvy people can still get NoScript to work on newer Firefox versions. Not to mention that I/we can continue to use NoScript like I/we used to .