InformAction Forums

Occasionally (but frequently enough to prompt this post) I get the following situation. I open a page, find it's not fully working, click Temporarily allow all this page and then use Ctrl + R to refresh the page (which sometimes but not always seems necessary - I've never really understood the inconsistency). If I remember I sometimes first copy any text if I've entered so far, as it can gets deleted after the refresh. So far that's all routine.

But in rare cases the page still doesn't work. I have to close and re-open it from scratch instead.

--
Terry, East Grinstead, UK

Overall, please read the sticky post, Why must I "Temporarily allow all this page" REPEATEDLY?, to understand why repeated temp-allows may be necessary.

The intermittent auto-reload is a separate issue.

terrypin wrote:Occasionally (but frequently enough to prompt this post) I get the following situation. I open a page, find it's not fully working, click Temporarily allow all this page and then use Ctrl + R to refresh the page (which sometimes but not always seems necessary - I've never really understood the inconsistency).

As for reloads, please open NoScript menu > Options > General tab. Check "Automatically reload affected pages when permissions change" > OK.
This should force reloads every time *script* permissions are changed.

However, if you temp-allow something in the Blocked Objects sub-menu, or by clicking on a placeholder icon (red NoScript logo), as for example, a Flash video at YouTube, the page will *not* reload. It doesn't need to. It shouldn't reload, because each time you reload *the exact same video", at YT or elsewhere, it may have a slightly different "signature" (some random numbers that vary with date, time, etc.). Reloading changes this signature, and you'd have to temp-allow again - forever.

However, latest development build provides an enhancement that tracks the same object despite reloads, making repeated allows of the same video on repeated reloads unnecessary. From the development changelog:

+ Improved active content identity tracking, to avoid redundant blocking steps across reloads

Presumably, this feature will be included in the next stable release, as no problems with it seem to have cropped up yet. But you can use the development build -- the support team and many users do, and if it causes trouble, just report the problem here. If necessary, uninstall it, and reinstall the stable release until the issue is resolved.

Cheers,
- Tom

Thanks Tom, appreciate the fast and detailed reply, very helpful.

I do have Automatically reload affected pages when permissions change enabled, which is why I'm puzzled about those few occasions when it didn't work. If/when I get another I'll try to report it in more detail.

Meanwhile I think on balance I'll pass on the development build and wait for the next release.

--
Terry, East Grinstead, UK

terrypin wrote:... I do have Automatically reload affected pages when permissions change enabled, which is why I'm puzzled about those few occasions when it didn't work. If/when I get another I'll try to report it in more detail.

Just provide the URL(s) of the sites where it happens, and the exact steps to reproduce the issue: what you did and didn't allow, or click, etc.
Also, what is not checked on NS Options > Embeddings tab.
So long as we can achieve the identical result, resolution should be easy.

Meanwhile I think on balance I'll pass on the development build and wait for the next release.

No need!

changelog

v 2.3.8 <snip>
+ Improved active content identity tracking, to avoid redundant blocking steps across reloads

I promised more details the next time this occurred.

An email link took me to this page
http://www.viator.com/error.jspa?code=VTC125

That displayed this error:


I clicked Temporarily allow all this page.

But the page did not refresh automatically.

Nor did it do so after I used Ctrl + R to restore the page manually. It remained permanently. Also, the NoScript icon menu still displayed the 'Temporarily allow...' option, whereas I would expect it to be greyed out now.

The only way I could view the page was to disable NoScript, restart FF, and click the email link again.

As requested, here are my settings under the Embedded tab. These must be the defaults as I've never opened this before.




--
Terry, East Grinstead, UK

> An email link took me to this page

Actually it did not .

Take a look at the actual email link.
Most likely it shows, http://www.viator.com/.

What happened is that when you landed at viator.com, it saw you had JavaScript disabled, so redirected you do:

http://www.viator.com/error.jspa?code=VTC125

Now, in a perfect world, what should happen is from that page, once you have allowed JavaScript, it should redirect back to www.viator.com, & all would be fine.

The http://www.viator.com/error.jspa?code=VTC125 page only exists to display the "enable Javascript in your browser settings" message.

Since that page does nothing automatically, since it is at that point not actively detecting if you have JavaScript enabled or not, the warning will remain - forever. Regardless of any settings, regardless of any browser, regardless of NoScript, opening http://www.viator.com/error.jspa?code=VTC125 will always say that you should "enable Javascript".

In any case, after you have allowed viator.com, if you pop up a level, to http://www.viator.com/, at that point, all should be fine.


(Some sites, Verizon comes to mind, also sets cookies to track whether JavaScript is enabled or not, so even after you have Allowed the required domain, it reads the cookie & still tells you you don't have JavaScript enabled. <Verizon used to be like that, not sure if it still is?>)

Thanks to therube for doing the investigation before I became available.

If this is a site you use with any regularity, you could add it to your whitelist.

If not, do this: When you get "stuck" on the "Javascript disabled" page, do the temp-allows, then just go to the Address Bar, and from just truncate (delete) everything after ".com". Click "enter".

Works for me.

I agree with therube that this is sloppy, lazy coding. Lots of that out there.
Cheers.

p. s. You do know that it's dangerous to click on links in e-mails, right? Yesterday, I received an e-mail from a trusted friend, containing only a link to what looked like pics of a conference. It redirected a couple of times, landing on a scamware site. Same thing happened a month or two ago with another trusted friend.

I trust my friends, but I can't trust their machines. I advised both to do a thorough scan for malware, with professional assistance as necessary. Clearly, their machines were being used to send spam to everyone in their address book, without them knowing it. Check out the linked destination first. (Right-click on the link, click "copy link location", then paste it in at, say, mywot.com, or other site rating agencies.)

Scientific curiosity prompted me to see where they went, so I could confirm and warn the senders. My machine is tightly locked down against this type of stuff, as it has to be to do support here.

Thanks both, much appreciated. As I suspected, there's more to this stuff than is immediately obvious

Re email links, yes, I am pretty careful but the bad guys are getting smarter. This particular Viator email (an invitation to comment on a holiday excursion I took last week) was obviously OK and I was expecting it.

--
Terry, East Grinstead, UK

terrypin wrote:Re email links, yes, I am pretty careful but the bad guys are getting smarter. This particular Viator email (an invitation to comment on a holiday excursion I took last week) was obviously OK and I was expecting it.

Good, then that one is OK. In both of the cases I described, the e-mails, although from friends, were unexpected with regard to their contents: In each case, nothing more than a single link to a site i'd never heard of.

And you're quite welcome.
Cheers,
Tom and therube, USA