Does NoScript block JScript in local files

[Cheech]

I have software that has locally installed Help files which are not working, and the vendor claims there are no known problems. I've looked through the Help sub directory attempting to find the main Help page but can not seem to find an obvious one (like Index.htm, ...). and there are also quite a few sub directories under the Help sub-directory with a couple hundred files.

What I noticed is that there are a number of Jscript files in the main help sub directory so I'm wondering if NoScript is somehow interfering with them especially if one of them gets called first.. The indication is that when I click on the Help menu item in the application the browser does not start at all, or if the browser is already running nothing happens. I've tried disabling NoScript but that doesn't help either. If I click on an .htm file it opens in Firefox so the .htm and .html file associations are OK. The one thing that may not be correct is that the file association for .js and .jse is to MIcrosoft Windows Based Script Host. Shouldn't that be associated to a Firefox JScript engine? One other piece of information is that the Help files appear to be written using RoboHelp.

Any suggestions?


Thank you,

Cheech

Windows/XP/XP3, Firefox 3.0.11, NoScript 1.9.5

[therube]

(I assume these help files are <would be> opening in FF?)

Do you have file:// Allowed?
If not, give it a shot.

The file associations should not matter.

[Cheech]

Yes they should be opening in FF, but I'm sure the vendor would prefer that I use IE. As I stated if I navigate to the folder and click on one of the .htm files it does open in FF which is why I'm suspecting that they invoke a .js file.

Do you have file:// Allowed?

If what you mean by the above is under the heading "Temporarily allow top-level sites by default" the radio button for "Full Addresses (http:// ....) is enabled. However, there was a check box setting under Contextual Messages label "Full Addresses ...." that was not checked. I enabled it and did not fix the problem either. I found one more that I though would possibly fix it. The setting was under "Advanced>>>Trusted>>>Additional permissions for trusted site>>Allow local links" but that had no effect either.


I don't see any option with the word "file://" so if none of these were what you were referring to then please let me exactly where the setting is located.

Thanks

[therube]

No, if you were opening a local file, file:// should appear in the NoScript menu.



Drag & drop an html file into FF or File | Open File... either way you should then have the option to Allow file://.

If the html files you've loaded require JavaScript, they will not work fully unless file:// is allowed.

What software application is this?

How do you open the application? Is it a stand-alone application or is it browser based (runs in your browser)?

[Cheech]

If I navigate from Open Files to one of the .htm files in the Help directory the NoScript context menu shows "Forbid files://"
so that should mean that files are allowed. I don't know what kind of files is being invoked by the Help menu item. The application is local and it's Help system is comprised of locally stored .htm and .JS file. The apps tech person downloaded FF on to his system and the Help worked fine. That narrows it down a bit but still leaves lots of possibilities.

I have a lot of addons in FF so I guess the next thing is for me to try a vanilla version of FF on my system and if it works that would pretty much eliminate any OS problem. The thing that is troublesome is if FF is not running at the time I click on the Help it doesn't start FF.

[GµårÐïåñ]

Do you have a sample url? If they are delivered via file:// then it will be blocked unless its allowed. However, some local help systems deliver through a local mini-webserver and come out http://machinename:port/... so if the machine name is xyz and the port is 1234, it could show up as http://xyz:123/document and that means you have to allow xyz and sometimes they use the keyword localhost and others 127.0.0.1 local loop, so whichever the case, if that is not allowed, then you are blocked.

[JD]

I have a similar problem regarding local files with javascript:

I've use a local file which contains javascript as my firefox-home-page and told noscript to allow "file://".

This always worked but lately Noscript drops the permission for "file://" from time to time.
(I've upgraded Firefox and Noscript several times, now running running latest Firefox 3.5 and Noscript 1.9.3.3).

I confirmed this by going to Noscipt-Options and checking if "file://" is contained in the whitelist.
As described above "file://" vanishes from the whitelist from time to time.

thanks,
JD

[Giorgio Maone]

(I've upgraded Firefox and Noscript several times, now running running latest Firefox 3.5 and Noscript 1.9.3.3).

Latest NoScript is 1.9.5, and you'd better report after trying latest development build (currently 1.9.5.6).

[orangesoda]

I"m not brave enough to try the development build but

I can report the same thing (disappearing permission) as reported above. I'll grant full permission to http://localhost:8080, which works fine for a while. This is permanent permission, not temporary. Every so often though, I'll restart and the permission is gone. I've never seen it go away in the middle of a session, though -- only after restarting the browser, and not every time. FWIW, hope that helps. This is with NoScript 1.9.5.

[Brad]

I'm also experiencing erratic allowing/blocking of javascript in local files that I've previously allowed (version 1.9.5/ Ubuntu).

I have a scheduled task in javascript in a local file. I enable file:// but six hours later (2am the next day) when it executes, it is often (~50% of the time) blocked. Earlier versions did not have this problem.

I also recall that Firefox has custom handling for script in local files. It checks daily whether to grant permission. You can set it to 'always allow', so it stops asking the user, but perhaps the checking process is somehow tripping up Noscript.

These issues aside, thanks for this great product.

[SeanM]

I have a similar problem regarding local files with javascript:

I've use a local file which contains javascript as my firefox-home-page and told noscript to allow "file://".

This always worked but lately Noscript drops the permission for "file://" from time to time.
(I've upgraded Firefox and Noscript several times, now running running latest Firefox 3.5 and Noscript 1.9.3.3).

I confirmed this by going to Noscipt-Options and checking if "file://" is contained in the whitelist.
As described above "file://" vanishes from the whitelist from time to time.

thanks,
JD

I am running Firefox 3.5.1, NoScript 1.9.6.9. I have the exact same problem. A local file, with javascript, as a home page (and as an error trap page). NoScript presents the "Allow File://", I enter "allow", and the rule is accepted, until Firefox restarts. At that point, the "File://" is NOT in the whitelist, and the procedure must be repeated.

Further, attempts to manually enter "File://" in the whitelist panel turns off the "Allow" button when the "//" is entered after "File:".

I also have a few apps that load local "help" files, which experience a similar problem, although the local "help" problem is intermittent. The "Home Page" problem is persistent and reproduceable.

NOTE: Edited on 25.07.2009 @ 14:10 EDT: Installed NS 1.9.7; problem persists.

[SeanM]

I have also been following a similar thread ("RESOLVED: FILE:// problems ....").

I have just upgraded to 1.9.7.9, and the "FILE://" problem still exists. One small change to the earlier post: adding "FILE://" to the whitelist is now possible (earlier, the "Allow" button was dimmed).

Unfortunately, whether manual addition to the whitelist, or right-click'ing "Allow FILE://" to add is performed, the addition to the whitelist does not persist across re-starts.

[Giorgio Maone]

Not reproducible. Could you export your configuration to let me analyze it and in the meanwhile use NoScript Options|Reset?

[SeanM]

Not reproducible. Could you export your configuration to let me analyze it and in the meanwhile use NoScript Options|Reset?

Prior to upgrading to 1.9.7.9, I had tried the NoScript Options|Reset, without success. After performing the NoScript Options|Reset on 1.9.7.9, all is functioning correctly.

Are you still interested in the upload of my configuration(s) ?

EDIT: After writing the above, I found that the Firefox extension "Fire.FM" was still disabled. Upon enabling "Fire.FM" the problem still exists. If "file://" is in the whitelist, the enabling of "Fire.FM" & restart of Firefox drops "file://" from the whitelist.

Do you wish me to screen-shot the above ? If so, should I post the screen-shots here, or E-Mail ?

Thanks in advance.

Sean

[therube]

Just some code fragments & just to point out.
This is probably more prevalent then one might imagine?

fmPlayerInitializer.js:

Code: Select all

const NOSCRIPT_UUID = "{73a6fe31-595d-460b-a920-fcc0f8843232}";

// NoScript revert timeout
const NOSCRIPT_TIMEOUT = 10000;

if (this._isExtensionInstalled(NOSCRIPT_UUID)) {
          this._overrideNoscript(flashURL);

   * Temporarily adds the URL of the Fire.fm flash player to the whitelist of
   * Noscript to allow it to load.
   * @param aFlashURL The URL of the flash player.

  _overrideNoscript : function(aFlashURL) {
    this._logger.trace("overrideNoscript");

    try {
      // the extension could be disabled.
      if (Cc["@maone.net/noscript-service;1"]) {

   * Reverts the changes that were made in the _overrideNoscript method to
   * return the NoScript rules to their original state.
   * @param aFlashURL The URL of the Fire.fm flash player.
   */
  _revertNoscript : function(aFlashURL) {
    this._logger.trace("_revertNoscript");

AMO: Fire.fm 1.2.4