Closed Bug 214166 Opened 22 years ago Closed 22 years ago

Windows "binds" Google.html to Google_files when saving complete web pages

Categories

(Core Graveyard :: File Handling, defect)

x86
Windows XP
defect
Not set
minor

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: mozilla, Assigned: darin.moz)

References

()

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030401 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030401 When a page is saved as a complete web page (File|Save Page As|Web Page, complete) a file called Google.html (for example) is created together with a directory called Google_files, containing the images, etc. from Google.html. The file and directory are "bound" together by the Connected Files "feature" of Windows. When attempting to delete either one of them in the operating system, the other one is deleted as well! The only way I know to "unbind" them is to try renaming one of them, which results in Windows giving a strange "Rename warning" dialog. Reproducible: Always Steps to Reproduce: 1. Visit www.google.com 2. Right click on the page (not on an image, though) and choose Save Page As. 3. Select "Web Page, complete", and save it. 4. In explorer, find the files "Google.html" and "Google_files". Actual Results: 5. Try to rename either one--a "Rename warning" will appear. 6. Try to delete either one--they both vanish. Unintended deletion of files is dangerous and Expected Results: This is a Microsoft "feature", so Mozilla can only work around it. Calling the folder containing the files Google_images would prevent Windows from binding them. I suspect calling it Google_files was intentional for Mozilla, but an option to name it something else would help. Mozilla should probably default to Google_images. It took a some work to find out what was causing this problem, as there is no information on it in Windows help. Users who do not specifically know about Connected Files (I was one of them until I decided to research this issue) will be confused by the file system behaviour. Information about Connected Files: http://support.microsoft.com/?kbid=252721
Google_images would be a bad idea, since you aside from images also can have external .js and .css files. What's wrong with following the Windows standard? Although this Windows feature is a little of a hack in my opionion, I think it is better to act like IE does, so that users don't get confused, and experience different behaviour between browsers.
->Networking:File
Assignee: general → darin
Component: Browser-General → Networking: File
QA Contact: general → benc
1) Networking:File is not the right component. The right component for things related to saving files is "File Handling". 2) The name was indeed chosen on purpose -- that's IE's behavior also when saving complete web pages. Marking invalid, therefore.
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → INVALID
Very well, since the Browser component page says specifically that file/save bugs belong in Networking: File, I've opened bug 214197 to have that page corrected.
Actually saving to disk is a Networking:File issue, probably. Deciding where to save is not, however. Just like deciding what page to go to when a link is clicked is not a Networking:HTTP issue.
Well, obviously the Component page needs to be clarified to split those hairs better.
Component: Networking: File → File Handling
QA Contact: benc → petersen
Thanks for the prompt review. The bug has been marked invalid with the reason: "that's what IE does". IMHO that's not an adequate excuse for Mozilla's behaviour--Mozilla is supposed to be a *better* browser, not an IE clone! I would have liked the bug to stay open for a little longer, even just as an RFE, so others can think about it. Other possible resolutions would have been: 1. Noting somewhere in the Mozilla documentation that this is how Windows 2K/XP behaves, and that Mozilla chooses to follow the MSIE standard. As I said, I was very surprised to find this behaviour, and it took a lot of work to find out the why of it. 2. Adding a non-default option to prefs.js to change "_files" to "xxx"... (which I will look into myself, anyway). Please consider re-opening the bug, demoted to low-priority RFE if you like.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.