Closed Bug 133611 Opened 23 years ago Closed 23 years ago

opening any html file with more than 32 char. will display its folder content

Categories

(Core Graveyard :: File Handling, defect)

PowerPC
macOS
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 95481

People

(Reporter: com, Assigned: ccarlen)

Details

Attachments

(1 file)

Create any file, even empty and give to the file any name using more than 32 characters ("1234567890123456789012345678.html" for example) then drag the file over Mozilla icon : amazingly Mozilla will display a sort of Mac OS X Finder list view, showing the whole content of the folder where the file is located. Mozilla is assuming that the file isn't a file but a folder, the folder where the file is located. The paths displayed in the status bar while moving the mouse cursor over the files or folders names shown in the window, is confirming that confusion.
Works on build 2002032503 for Win98
Valerio: This bug would probably be only reproduced on mac
The bug can be reproduced on any of my macs running Mac OS X 10.1.3, using 0.9.9 or the nightly build from the 19th of march. I will right now make and post a screenshot.
Comments : First, Mozilla isn't displaying the full name of my file, but a truncated name. Performing a click over "AppleScript" and "AppleWorks" folders displayed their content. When the mouse cursor is over any element, the path of the element is displayed in the status bar. I took the screenshot when the cursor was over "Clock". Now look at what path is displayed in the status bar : Mozilla is considering that my html file with long name is a folder where each element is located. (note : some people unfamiliar with Mac OS X won't understand why "Clock.app/" is written in the path and not only "Clock" : this is normal Mac OS X is hidding the .app extension by default and apps under Mac OS X are packages, folders with a content hidden by default). I can add that clicking over any column header will sort the content following the selected header ("name" and "Last Modified" will sort normally but not "Size", sorting incorrectly the files...).
Conrad--can you confirm? if so, can you fix easily?
Confirming. I'll take it. I think I know what's happening.
Assignee: law → ccarlen
I think this was caused by my fix for bug 87831. In that bug, the app would just crash on startup if the name of the drive contained a non-ASCII character on a US system. The patch for that got around that problem by using an HFS+ routine to get the full path of the file. When doing that, the resulting path will contain nodes with > 31 chars. Notice that the URL bar when reproducing this bug has the full, long path name of the file. Problem is, such a path cannot be digested by InitWithPath() which will ultimately have to be called to turn the URL back into a file. Because of what happens to long file names using HFS on OS X, we can't mix HFS and HFS+ calls, it has to be one or the other. But, if we don't use HFS+ calls to produce the path under OS X, we suffer the problem of bug 87831. In summary: (1) It's a lesser of 2 evils. Between this and 87831, this is lesser IMO. (2) The way we represent local files all over the place as URLs (full paths) sucks. (3) Once the file system is fully HFS+ (bug 95481), we won't have this manifestation of the long file name problem. Unless anybody disagrees with (1), I'm going to make it a dup of bug 95481. CC'ing some other Mac people for opinion. *** This bug has been marked as a duplicate of 95481 ***
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
marking verified as a duplicate. if you decide to reopen this bug, please clarify why. search string for bugspam removal: SalviaGuaranitica
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: