InformAction Forums

Posted: **Fri Jul 20, 2018 10:09 am**

Session Restore - Icon Incorrect, JavaScript Allowed

On starting up from Session Restore, Icon displays incorrectly AND JavaScript may be (incorrectly) Allowed.

Set youtube.com to Default
Set FF to restore session on browser startup

Load:
URL: https://www.youtube.com/watch?v=4QAsOziiUzE
URL: https://bugzilla.mozilla.org/show_bug.cgi?id=1415644

Set focus to mozilla.org
Quit

Open FF

Result:
mozilla.org shows as partially allowed, with a 4, domains show, mozilla.org & google-analytics.com, both at defaults

-------

Set focus to youtube.com
Quit

Open FF

Result:
youtube.com shows as partially allowed, with a 2, domains show, youtube.com, gstatic.com, & ytimg.com, youtube.com is Default, the other two are Trusted

AT LEAST ONE TIME, JavaScript was allowed, must have been allowed, as the page displayed normally & the video automatically played.
(Otherwise the page, with youtube.com at Default, JavaScript blocked, is "broken" [as expected], not displaying any pictures... I have not been able to duplicate the JavaScript Allowed issue, or if you want to look at it as JavaScript was not being blocked, but it has happened.)

FF 61, NoScript 10.1.8.9rc1

Oh, in each case, refresh the page & the icon displays correctly.
In the instance, with youtube, where JavaScript (must have been) allowed, I didn't think to refresh the page to see what would happen, but I'll suspect that on refresh, the page would have come up blocked (Default, as set in settings).

Posted: **Fri Jul 20, 2018 12:56 pm**

It sound like this bug not having been actually fixed for good.

Posted: **Sun Jul 22, 2018 5:19 pm**

v 10.1.8.9rc3
=============================================================
x More reliable handling of edge cases on startup (thanks
therube for reporting)
x Fixed dynamic script injection failing sometimes with
"No matching message handler" error (thanks skriptimaahinen
for reporting)

Posted: **Mon Jul 23, 2018 10:13 am**

Session Restore - Icon Incorrect

Most cases look to be OK, but...

URL: https://github.com/mozilla/policy-templ ... /README.md

Load URL
Temporarily Allow github.com (actually, this step is not even needed)
Quit

Start FF from Session Restore

Result:

Icon shows github.com as Temporarily Allowed, 1
Dropdown shows github.com as Default

Posted: **Mon Jul 23, 2018 10:20 am**

URL: https://www.loomio.org/

Offhand, I don't know if this is 10.1.8.9rc3 specific or not, but loomio.org shows as partially allowed - regardless of all else?

Cannot duplicate in a new Profile.

Is there not some easy way to compare Prefs between Profiles - for extensions, these days?
(I have had the sneaky feeling, for a long time, that "updates" of webextensions simply do not work, correctly.)

And also cannot duplicate the .github issue in a new Profile.
While my Profiles often times are "mules", in this case, my existing Profile I don't think has had much going on in there except for installing various NoScript (it's the only extension in there) & loading websites?

Posted: **Mon Jul 23, 2018 10:36 am**

Existing on the right, new Profile on the Left.
uuid ?
And the second time I've seen § is the space of an hour, https://www.voidtools.com/forum/viewtop ... f=2&t=6985.

So nothing of consequence, that I see, shows there, yet the Profiles definitely act differently.

Posted: **Mon Jul 23, 2018 10:47 am**

HA!

It's the Bookmarks Toolbar.
If you display the Bookmarks Toolbar, you can see the behavior.

(Actually I have both the Menu Bar & Bookmarks Toolbar displaying.
And it is not the first time that I have run into a situation where having the Bookmarks Toolbar display affecting things [in the other case, it was video resolutions displayed, or not, on Youtube].)

Posted: **Mon Jul 23, 2018 2:13 pm**

therube wrote:URL: https://www.loomio.org/

Offhand, I don't know if this is 10.1.8.9rc3 specific or not, but loomio.org shows as partially allowed - regardless of all else?

This is a really interesting case. It uses Service Workers, which are so heavily cached that once you allow it (even temporarily) it completely bypasses the webRequest API: therefore revoking the permissions doesn't take effect until the service gets deregistered (which might never happen).
I'll surely look for a work-around and probably open a bug to have this sorted out: I feel requests handled by service workers should not bypass webRequest, but Mozilla developers might think otherwise.

Posted: **Mon Jul 23, 2018 9:59 pm**

Giorgio Maone wrote:
therube wrote:URL: https://www.loomio.org/

Offhand, I don't know if this is 10.1.8.9rc3 specific or not, but loomio.org shows as partially allowed - regardless of all else?
This is a really interesting case. It uses Service Workers, which are so heavily cached that once you allow it (even temporarily) it completely bypasses the webRequest API: therefore revoking the permissions doesn't take effect until the service gets deregistered (which might never happen).
I'll surely look for a work-around

Temporary work-around (which I'll likely base mine on): use this bookmarklet to deregister service workers on the site:

Code: Select all

javascript:(async () => { for (let r of await navigator.serviceWorker.getRegistrations()) r.unregister()})()

Posted: **Mon Jul 23, 2018 10:12 pm**

Giorgio Maone wrote:
Giorgio Maone wrote:
therube wrote:URL: https://www.loomio.org/

Offhand, I don't know if this is 10.1.8.9rc3 specific or not, but loomio.org shows as partially allowed - regardless of all else?
This is a really interesting case. It uses Service Workers, which are so heavily cached that once you allow it (even temporarily) it completely bypasses the webRequest API: therefore revoking the permissions doesn't take effect until the service gets deregistered (which might never happen).
I'll surely look for a work-around
Temporary work-around (which I'll likely base mine on): use this bookmarklet to deregister service workers on the site:
Code: Select all
javascript:(async () => { for (let r of await navigator.serviceWorker.getRegistrations()) r.unregister()})()

[EDIT]
Force refresh (ctrl+F5) will work too, and probably easier to implement.

Posted: **Tue Jul 24, 2018 9:37 pm**

Please check latest development build, thanks.

Code: Select all

v 10.1.8.9rc4
=============================================================
x Work-around for serviceWorker loads bypassing webRequest
  (thanks therube for reporting)
x More flexible CSS layout for preset buttons (thanks fatboy)
x Improved edge case script disablement detection

Posted: **Wed Jul 25, 2018 1:43 am**

Looks better

.

Posted: **Tue Aug 28, 2018 10:36 am**

Looks like the fix for serviceworkers is removed from 10.1.9rc1, so what is the plan now?

Did you file a bug for this and if so, how did they answer?

Posted: **Tue Aug 28, 2018 10:10 pm**

skriptimaahinen wrote:Looks like the fix for serviceworkers is removed from 10.1.9rc1, so what is the plan now?[/url]

This one.

Did you file a bug for this and if so, how did they answer?

Not yet, since I've got a good work-around and tons of other stuff in the pipeline.

InformAction Forums

Session Restore - Icon Incorrect, JavaScript Allowed

Session Restore - Icon Incorrect, JavaScript Allowed

Re: Session Restore - Icon Incorrect, JavaScript Allowed

Re: Session Restore - Icon Incorrect, JavaScript Allowed

Re: Session Restore - Icon Incorrect, JavaScript Allowed

Re: Session Restore - Icon Incorrect, JavaScript Allowed

Re: Session Restore - Icon Incorrect, JavaScript Allowed

Re: Session Restore - Icon Incorrect, JavaScript Allowed

Re: Session Restore - Icon Incorrect, JavaScript Allowed

Re: Session Restore - Icon Incorrect, JavaScript Allowed

Re: Session Restore - Icon Incorrect, JavaScript Allowed

Re: Session Restore - Icon Incorrect, JavaScript Allowed

Re: Session Restore - Icon Incorrect, JavaScript Allowed

Re: Session Restore - Icon Incorrect, JavaScript Allowed

Re: Session Restore - Icon Incorrect, JavaScript Allowed