1727012 - Saving a webpage breaks CSS references in some cases

Status: RESOLVED INCOMPLETE

(Firefox :: File Handling, defect)

Description

[SingsBass]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.131 Safari/537.36

Steps to reproduce:

(Observed in Windows 7 and Windows 8.1)

I have actually seen the effects of this bug for a long, long time (over many, many versions), but the stars aligned tonight [smile]. I managed to isolate it down to something very reproducible and straightforward to describe, with a corresponding example.

Go to the following URL:

https://circuitdigest.com/electronic-circuits/soft-start-circuit-for-power-supply

When it has finished rendering, click on File -> Save Page As, and save the page to a local folder. I suggest using a very short folder name directly off the root of a data drive, for reasons that will soon become self-evident.

Now, in Firefox, try to open the page you just saved (preferably, while disconnected from the Internet, to ensure that the local elements are used - as opposed to possible 'live' streams from the Internet). Notice how the local page does not render properly.

In the folder where you just saved, there should be a subfolder called "Soft Start Circuit for Power Supply_files". Look inside that subfolder and locate the CSS files.
Pay close attention to the one named:

"css__O-vC7rzbt04ipYTvKKTNEuPbCrTFcthax3rk3FnlOyA__nXrGOicIDH.css"

In reality, it should actually have been named:

"css__O-vC7rzbt04ipYTvKKTNEuPbCrTFcthax3rk3FnlOyA__nXrGOicIDH8-_ixs9goY05AnIkWxm1ZsdsGZWn5Yfk0__Si4nJgwqcukDsAs0UYzgS7s-fYCWJKHDSMD2ZJhG910.css"

But Firefox erroneously truncated the name when it saved the page. We can confirm that by examining the contents of the parent HTM file. The corresponding HTM file references the long version - which, of course, is not found (given the truncation), so the rendering breaks.

I hate to use the "C" word [grin], but as a point of comparison, if I use Chrome to save the page, the filenames are not truncated - the long names are preserved. This is a significant point, as it also exposes a secondary problem with Firefox.

It seems that Firefox's reading routines also choke on long filenames. If I save the page with Chrome (thereby creating the proper file names), I can also open the page (offline) properly in Chrome. But if I try to open that same structure (the one saved from Chrome, with the proper long filenames), Firefox still does not render the page properly.

To be thorough, I did all 4 combinations of tests, using Firefox and Chrome. Here are the results:

Save in Chrome; Open in Chrome - works
Save in Firefox; Open in Chrome - fails
Save in Chrome; Open in Firefox - fails
Save in Firefox; Open in Firefox - fails

Actual results:

Firefox truncated the names of certain files (including the main CSS file), so subsequent offline rendering of the locally-stored webpage fails. Some long JavaScript file names are also truncated.

Firefox also fails to read long filenames properly, resulting in failed offline rendering. (Note that Chrome is able to render the very same offline structure properly, on the very same computer systems - confirming that other elements such as the underlying files, system config, etc., are not at fault.)

Expected results:

Firefox should employ more advanced file access calls to handle long filenames.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Firefox::File Handling' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Andrei Purice]

Can you test the issue while in Safe Mode? You can find helpful info here : https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode .
Also a fresh new profile could help. You can find more about creating a new profile here : https://support.mozilla.org/en-US/kb/troubleshoot-and-diagnose-firefox-problems#w_6-create-a-new-firefox-profile .
If possible, you can test this issue on the nightly build as well. Download the build from : https://www.mozilla.org/en-US/firefox/nightly/all/ .

Comment 3

[SingsBass]

Andrei,

Thank you for your follow-up.

I should have provided a little more background. I am a developer by trade (though, in a totally different sector - I program firmware for micro-controllers), so I tend to apply basic troubleshooting steps long before I seek help or report bugs [smile].

To that end, I had already set up a clean virtual machine, with a fresh copy of Firefox (v91.0.1). So, the profile was actually fresh when I did my final tests, just prior to posting the bug. I didn't download/install any add-ons, so everything was pretty "vanilla".

However, I know how much I hate it when my end users think they know better than me [grin], so I went ahead and conducted all of your requested tests, regardless of some of them seeming redundant (but you would have no way to know that) ...

Safe Mode - same results

New Profile - same results

Nightly Build (firefox-93.0a1.en-US.win64.installer) - same results

I even went so far as to try Safe Mode in the Nightly Build - same results. I didn't create a new profile in the nightly build, because I noted that it had already created a fresh/separate profile from the "normal" Firefox (91), so that seemed pointless.

I am curious - since you asked for these additional tests, am I to take it that you have not been able to recreate the behviour at your end? If that is the case, then I am really stumped. The issue is so consistent for me (and I have observed it for several years, actually). I just tested again, on a totally different machine (which happens to be running Firefox 86), and it happens there too. But I know it has happened in much earlier versions as well - I just didn't have it pinpointed back then.

Looking forward to further feedback.

Thanks,
Brant

Comment 4

[:Gijs (he/him)]

(In reply to SingsBass from comment #0)

Pay close attention to the one named:

"css__O-vC7rzbt04ipYTvKKTNEuPbCrTFcthax3rk3FnlOyA__nXrGOicIDH.css"

In reality, it should actually have been named:

"css__O-vC7rzbt04ipYTvKKTNEuPbCrTFcthax3rk3FnlOyA__nXrGOicIDH8-_ixs9goY05AnIkWxm1ZsdsGZWn5Yfk0__Si4nJgwqcukDsAs0UYzgS7s-fYCWJKHDSMD2ZJhG910.css"

I can reproduce this part (though the exact file name varies; I expect the website probably combines/compiles these in a way that make the exact names change).

I don't think preserving exact filenames should be a goal (it's frequently not really meaningful, e.g. when web URLs do not have file extensions, which you would normally want to have, esp. on Windows and macOS systems) -- but obviously the references from the main HTML doc and the files we actually write should match, whatever filenames we use, so that's definitely a bug!

On closer inspection, when I save that page I hit bug 1445211 or bug 1668530 (ie the download fails with default settings, in both private windows and regular windows), and the result of retrying doesn't seem to have altered protocol-relative URLs. That is, the webpage sources the stylesheets with something like:

href="//circuitdigest.com/electronic-circuits/blah/some/more/stuff.css"

but the saved copy gets loaded from a file:/// URL because it's now on a local disk, and obviously the resulting file:///circuitdigest.com/electronic-circuits/blah/some/more/stuff.css result is a nonsense and fails to load.

I don't know if we're just not adjusting any paths when retrying, or if 'save page as' is struggling specifically with protocol-relative hrefs somehow - that would need some testing with a page that doesn't get any of its subresources blocked.

It seems that Firefox's reading routines also choke on long filenames. If I save the page with Chrome (thereby creating the proper file names), I can also open the page (offline) properly in Chrome. But if I try to open that same structure (the one saved from Chrome, with the proper long filenames), Firefox still does not render the page properly.

However, I cannot reproduce this issue (ie saving the page with Chrome under a different name, and then loading that page in Firefox, works properly). Can you provide more details about what you mean by "does not render the page properly", and clarify why/whether you think this is directly related to the same issue with CSS files that occurs when writing/saving the page from within Firefox?

Comment 5

[SingsBass]

( In reply to :Gijs from comment #4 )

I can reproduce this part (though the exact file name varies; I expect the website probably combines/compiles these in a way that make the exact names change).

I concur regarding the "exact" filename - it likely changes from session to session.

I don't think preserving exact filenames should be a goal (it's frequently not really meaningful, e.g. when web URLs do not have file extensions, which you would normally want to have, esp. on Windows and macOS systems) -- but obviously the references from the main HTML doc and the files we actually write should match, whatever filenames we use, so that's definitely a bug!

I also agree that preserving the exact filenames doesn't necessarily need to be the goal. Perhaps I am cynical (and I certainly don't mean any offense [smile]), but I sense a potential trap here if that thought is left hanging as-is. There may be a temptation to solve part of the problem by simply checking the name length (or, more to the point, the length of the saving path/file combined), and shorten it as may be required.

At first blush, testing on such a solution may generate some positive results. However, even if the underlying bug (of matching the written file and the references in the main HTML doc) were fixed, simply reducing the path/name length would still fall short of the mark in terms of a full and proper solution - IMHO.

Specifically, where the target file structure is complex/deep, even a 'short' name may still result in a long reference.

So, even if the saved names end up being different from what the protocol stream provides, I think the bug should be fixed in a way which plays well with "long file names" (as they are known in the Windows environment).

On closer inspection, when I save that page I hit bug 1445211 or bug 1668530

Interesting that you ran into those. I did not, of course, as I purposely simplified my testing environment down to a clean VM with either the latest stable Firefox release, or the nightly build. So I didn't have any blocker add-ons involved in those scenarios.

... Can you provide more details about what you mean by "does not render the page properly" ...

I was extremely intrigued by your results of using Chrome and Firefox. I must have been going cross-eyed from testing at the time. I have re-run the tests, and it would appear that - even in a deep/long structure - I can successfully read back web pages from a local disc, if they have been saved by Chrome.

So, with a bit of a red face, I must retract the final statement in my original posting. Saving in Chrome and then reading in Firefox does appear to work. (This proves, once again, that it is good to have new eyes look at something ... or, walk away from it for a while, so that your own eyes are fresh again [shrug/smile].)

With your insight regarding the HREF issue (i.e., when Firefox saves, it still references cloud/server based resources ... instead of adjusting to the local path), I peeked Chrome's HTML file for that specific issue - and, indeed, Chrome does make the adjustments.

So I guess this boils down to two (related) issues - namely, Firefox truncates the local filename and (as you determined) it does not make the appropriate HREF adjustments to point to the saved resources on the local disk.

From a layman's standpoint, I am not sure that the other two bugs you referenced are relevant here (?), since the issue I reported occurs without any blockers installed. But, I will certainly defer to your experience on that aspect of things, since I am certainly no expert.

If you require any further info, please do not hesitate to let me know. As always, I will do my best to provide answers.

Comment 6

[:Gijs (he/him)]

Thanks for the extensive replies!

Hm, so the confusing thing is in a minimal testcase, protocol-relative links appear to be processed correctly, ie I start with a webpage like this:

<link type="text/css" rel="stylesheet" href="//localhost/path/to/testcases/protocol-relative-paths/test.css">
<p>This text should be green</p>

and it gets saved like this:

<html><head>
<meta http-equiv="content-type" content="text/html; charset=windows-1252"><link type="text/css" rel="stylesheet" href="protocol-relative-paths_files/test.css">
</head><body><p>This text should be green</p>
</body></html>

which is fine (and the CSS file also gets saved correctly). If I make the filename longer, I can reproduce the exact filename getting truncated - but the reference gets updated accordingly and the page renders correctly still.

My guess right now is still that it is failing because of the mixed content blocking in the original testcase:

(In reply to SingsBass from comment #5)

From a layman's standpoint, I am not sure that the other two bugs you referenced are relevant here (?), since the issue I reported occurs without any blockers installed.

"Mixed content blocking" is something Firefox has built-in, not something you need to install. It is about secure websites (on https) referencing content that is not secured (on http, without the s), which gets automatically blocked. bug 1668530 is the relevant ticket for that issue. So when I try to follow the steps in comment 0, after OK'ing the destination of saving the file, the download initially fails. I can restart it from the download panel, and then it succeeds the second time (but I'm not convinced the same processing happens, which would explain why links are broken).

It sounds like this isn't happening for you - can you perhaps attach a screencast of the exact steps you take when you use "File > Save page as..." on this webpage? I assume I'm doing something different but I don't know what.

Comment 7

[SingsBass]

Attachment: Screencast of SaveAs in Firefox Nightly 95 (2021-10-17)

Screencast uploaded to demonstrate the SaveAs steps. There seems to be a difference in behaviour between my environment, and some of the developer environments.

Comment 8

[SingsBass]

Sorry to be so long returning to this. My life tugged me away from computer work for awhile.

With regards to "extensive replies", I always figure it is easier for you to ignore information you don't need, than to make assumptions in a vacuum. In other aspects of life, less is more - but in troubleshooting, the more the merrier [LOL].

I am now somewhat baffled. I can no longer recreate my own issue! [shaking my head]

Mind you, I may have broken a cardinal rule - I changed something (with the best of intentions), before running my tests. As I had done before, I downloaded the latest nightly build and installed it, before attempting to capture a screencast. My thinking was that it would always be better to be working on 'current' code, rather than troubleshooting code that is aging more and more.

When I followed my own steps in the Nightly 95 (Oct 17th), the saving of the page worked fine. Luckily, I still had Firefox 91 (non-nightly) installed, and I knew the page had failed in it previously. So, I went back and re-ran the tests in v91, and to my shock, the page saved just fine in that environment too.

Ideally, one would not expect the nightly installation to contaminate or interfere with the 'normal' Firefox installation, so I am going to assume (for the moment) that didn't happen. I am going to do some more digging, but I suspect that the source on the web may have been updated. At least, that is the best explanation that comes to mind in the first few seconds.

Now, with regards to the screencast ...

Were you wanting the video, because you are pursuing the difference the behaviour of the actual saving - i.e., you get an initial failure and have to restart, whereas I don't? If that is the case, then the MP4 file that I just uploaded will hopefully be useful to you. However, if it was for the purposes of troubleshooting the actual SaveAs problem, then at the moment, it won't help - since as of right now I cannot recreate the problem [shrug].

By the way - In the video, you may notice what appears to be some "re-clicking" activity, on the bookmark, and on the download icon (after the page has saved; towards the end of the video). The screen capture software seemed to cause short mouse clicks to be missed ... and I guess my normal finger speed was a little too quick for the system. So, in both cases, I had to go back and make a more deliberate click.

Also, the video capture software did not capture the appearance of the download window (at the very end of the video) [shrug]. But, the window did open, and it showed the file folder icon, not the restart icon (further confirming that the download was indeed successful on my first try).

Lastly ... I am not comfortable closing the bug just yet. I was very careful before I ever submitted the initial problem report, so I don't think the issue has magically disappeared on its own [smile]. I want to do some more digging, and hopefully find another example that triggers the problem (again).

Comment 9

[:Gijs (he/him)]

(In reply to SingsBass from comment #8)

Sorry to be so long returning to this. My life tugged me away from computer work for awhile.

No worries, I appear to have been much longer - apologies.

I am now somewhat baffled. I can no longer recreate my own issue! [shaking my head]

Mind you, I may have broken a cardinal rule - I changed something (with the best of intentions), before running my tests. As I had done before, I downloaded the latest nightly build and installed it, before attempting to capture a screencast. My thinking was that it would always be better to be working on 'current' code, rather than troubleshooting code that is aging more and more.

Your thinking is entirely correct. And you are also correct that the nightly build shouldn't affect your "regular" release version of Firefox on the same machine.

I am going to do some more digging, but I suspect that the source on the web may have been updated. At least, that is the best explanation that comes to mind in the first few seconds.

Yes, I agree it's likely that the site was updated.

Now, with regards to the screencast ...

Were you wanting the video, because you are pursuing the difference the behaviour of the actual saving - i.e., you get an initial failure and have to restart, whereas I don't?

Yep.

If that is the case, then the MP4 file that I just uploaded will hopefully be useful to you.

Thanks. The site now works for me without resources being blocked, too, so like you said perhaps the site changed, or perhaps it's luck of the draw which ads load and break things...

Lastly ... I am not comfortable closing the bug just yet. I was very careful before I ever submitted the initial problem report, so I don't think the issue has magically disappeared on its own [smile]. I want to do some more digging, and hopefully find another example that triggers the problem (again).

Did you end up finding another example? Unfortunately, without a broken example it is hard to know what exactly is going wrong where, and how to fix it. We can also close this and then reopen it at a later date, if the issue reappears for you on a different site. It's less about "we don't think this issue is real" (we do!), more that "we don't know how to reproduce and thus fix the issue, so engineers can't work on it".

Comment 10

[:Gijs (he/him)]

Given it's been two months, I'm tentatively closing this - but we can always reopen!