A Curious Case of a Firefox Flaw

The Fix: find . -type f -exec sed -i "s#/static/#static/#" {} \;

Back story: I had downloaded the archive of Perl's documentation in HTML format. The files were like:

$ dir -dF1 perldoc-html/*

In the (Windows) directory c:\User\fubar\Downloads\docs.

I generally use Firefox, and the index.html file was bookmarked, which, in the local file HTML format, is:


Woked just fine. Until I updated from "Perl 5 version 22.0 documentation" to "Perl 5 version 26.1 documentation".

What broke was that how style sheets loaded. Viewing the page source, the CSS link reveals the problem:

<link href="/static/css-20100830.css" rel="stylesheet" type="text/css">

And in the view source page, clicking on the CSS link resulted in... nothing. No 404 as I expected. No attempt even to open it.

In the view page source source, the link for the CSS was:

<a href="view-source:file:///static/css-20100830.css">static/css-20100830.css</a>

Which looks kinda funny - more about that later.

The simple fix is to edit the file to remove the /. I did so and confirmed correct loading. But since there are nine hundred and fifty one (951) HTML files, that simple fix is actually a near impossible fix. (Certainly so trying to manually change them all; almost certainly so creating a SED/AWK/Perl/Shell script to modify them all.)

But back to Firefox. I loaded a file access monitor and confirmed that Firefox is not even looking for the file!

Remember that "looks kinda funny" link I mentioned? file:///static/css-20100830.css It is ill-formatted.

(For a test, manually enter it in Firefox. Firefox goes off into some kind of la-la land. I am using version 58.0b10, and the developers made it do a nice little feedback thing of a "jiggy dot" moving back and forth in the page tab, and it just goes "jiggy-jiggy-jiggy" back and forth. Thanks guys, waste even more of my CPU cycles on silly, useless, visual feedback.)

The Firefox Jiggy DotThe Firefox Jiggy Dot

Next, I loaded Microsoft Edge. It actually tried to load the CSS file. Here's the file monitor:

6:49:53.6529191 PM, MicrosoftEdgeCP.exe, CreateFile, C:\static\css-20100830.css, PATH NOT FOUND

Same with IE and Chrome:

6:52:20.7162305 PM, IEXPLORE.EXE, CreateFile, C:\static\css-20100830.css, PATH NOT FOUND
7:02:28.7049941 PM, chrome.exe, CreateFile, C:\static\css-20100830.css, PATH NOT FOUND
If you are not familiar with the Windows API, "CreateFile" here is not trying to create the file, it is using it to "Read Atttibutes".

The first next thing I did was to create a "shortcut" to the the perldoc static directory as C:\static. Wrong, does not work.

Next I made a real directory C:\static and copied the Perl files into it.

Edge and IE correctly loads all files and work just fine.

Chrome, though, is broken still, but in a stupid way. It loads the CSS files, but it will not load any images or the Javascript file. Even when it is told to, it still doesn't.

Chrome File Images Don't LoadChrome File Images Don't Load

This is like, so... ughing stupid. But wait! This is only the case for only disallowing images except on a per website setting, and Chrome's "allow website" input just doesn't for work file///. (Same with Javascript.)

Oh, and Firefox. Note above the correctly formated local file URL begins with file:///C:/, and the /static/css-20100830.css like was file:///static/css-20100830.css. Let's fix it:


Pasting it in, and with the file existing, Firefox loads it, as expected.


  1. It is too bad that the Perldoc HTML archive uses absolute paths for it's CSS links, and there are 951 * 2 in the files. Too many to change easily.
  2. The kludge fix to copy Perldoc's static directory to root works for Edge and IE, so I can now nicely read the Perl documentation.
  3. Firefox version 58 (at least) has a flaw that incorrectly translates local file links beginning with a /, making them without the C:/.
  4. Chrome version 63 (at least) can be considered to have a flaw in that it cannot be made to load images/Javascript for local files via it's per website settings - one has to allow them globally.

Chrome then can work. But I do not run web browsers with global image and Javascript loading - first for bandwidth, second for security. (More on that later.)


I can place the Perldoc documentation in the httpd server's document root folder and view them via http://localhost/perldoc-html/ - but I'd still have to put the static directory in root! The Perldoc documentation files are formated to be all placed in a root directory. Which is too bad, and not right.

(I have a nice collection of many offline documentation in HTML files - PHP, Bash, Git, HTML, etc. - in a documentation folder, and do not want them in the httpd server's document root - which for me is for developing websites and web applications only.)

Code Index: