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

Status: VERIFIED DUPLICATE of bug 95481

(Core Graveyard :: File Handling, defect)

Description

[bruno lapeyre]

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.

Comment 1

[Valerio Capello]

Works on build 2002032503 for Win98

Comment 2

[Vadim Berezniker]

Valerio: This bug would probably be only reproduced on mac

Comment 3

[bruno lapeyre]

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.

Comment 4

[bruno lapeyre]

Attachment: png showing the amazing bug - 1024X768

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...).

Comment 5

[Kathleen :Brade]

Conrad--can you confirm?  if so, can you fix easily?

Comment 6

[Conrad Carlen (not reading bugmail)]

Confirming. I'll take it. I think I know what's happening.

Comment 7

[Conrad Carlen (not reading bugmail)]

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 ***

Comment 8

[sairuh (rarely reading bugmail)]

marking verified as a duplicate.

if you decide to reopen this bug, please clarify why.

search string for bugspam removal: SalviaGuaranitica