12749 - Unknown File Type error opening multiple file: directories

Status: VERIFIED WORKSFORME

(SeaMonkey :: UI Design, defect, P3)

Description

[Sean Richardson]

Summary:

In Mozilla M9 on Windows NT, file: URLs that do not end in filenames
result in "Unknown File Type" error messages with no filetype given.
Example: file:///C|/Mozilla/Users50/mozProfile/

Occurs in:

Mozilla M9, build 1999082412, on Windown NT.
MOzilla M7 on Windows NT.
Does not occur in Communicator 4.61

How to replicate:

1. Start Mozilla.
2. On the File menu, click on Open Location or File...
3. In the dialog box that comes up, click on [Choose File]
4. Navigate to any html file on a local drive.
5. Click on [Ok], the file will display.
6. Click in the Location Bar. Hit the END key.
	Hit the backspace key enough times to clear the filename. Hit enter.
7. The "Unknown File Type" error box will appear.
	The file displayed in step 5 will still be visible after cancelling
	the error. At this point the session can continue.

It does not matter whether you leave or trim the final "/" character,
the same error will occur.

Expected:

A directory listing (so long as there is no index.html or equivalent).
If the same file is accessed from a webserver, and the filename is trimmed,
the directory is listed.

Actual Behaviour:

The "Unknown File Type" error box will appear, instead of the
directory listing.

Comment 1

[Sean Richardson]

Attachment: Example of "Unknown File Type" dialog for this bug

Comment 2

[Sean Richardson]

With build 1999-10-18-08-M11 (and possibly earlier) on Windows NT,
this error does not appear.

It is clear where this is going now: directory listing code is starting
to take shape.

It looks like this was never a Necko problem; suggest resolving WONTFIX.

Comment 3

[Gagan]

Chris you working on file directory listings?

Comment 4

[leger]

If only file URLS, sorry PDT-.

Comment 5

[leger]

Resetting QA contact from leger.

Comment 6

[Chris Waterson]

Hmm. This WORKSFORME. Guessing random sunspots fixed it.

Comment 7

[Sean Richardson]

Clarifying my 10/19/99 comment: I am certain that this was happening because
the new tree-based directory listings were just beginning to be integrated
into Mozilla, and the old-style directory listings were no longer available.
This must have been a temporary bug.

Comment 8

[Sean Richardson]

REOPENing rather than filing a new bug as this is almost certainly has the same
cause as well as the same symptom, just with a new trigger.

Overview:
It appears that the directory listing code does not fix this bug, rather it
displays a directory list before the code that displays the "Unknown File Type"
dialog is triggered. But if the twisty beside more that one directory is
clicked in quick succession to display the directory listing in the tree,
only one directory list is done; for each additional directory list requested
while the first is not yet finished, the "Unknown File Type" dialog is
displayed.

Steps to Reproduce:
1. Type "file:///c|/" into the Location bar.
2. Scroll, if necessary to a point in the listing where at least 3
   directory names are visible close together (it may not look possible,
   due to another bug affecting the scrollbar slider display, but it is
   possible to scroll)
3. Click on three right-pointing twisties beside directory names in
   very quick succession (it also helps if the first clicked has a long
   listing)
4. Wait a bit: even for listing directories on a local drive, this is slow.

Actual Results:
The first directory list will appear in the tree; for each additional listing
requested while the first request was not finished, an "Unknown File Type"
dialog will appear in the top left corner of the desktop.

Expected Results:
A. No immediate "Unknown File Type" dialogs instead of directory listings, ever
   - if the directory cannot be listed now, perhaps it can in a few seconds.
B. The directory listings will appear in the tree in succession, taking
   however long that takes, unless it is looking like it will take forever,
   in which case some sort of alert should appear.

Tested With:
1999-12-09-08-M12 nightly binary on Windows NT 4.0sp3
( [PP] or all Platforms? Unknown )

Additional Information:
This bug rediscovered while testing whether bug 20014 "opening multiple FTP
directories simultaneously causes app lock" affects file: directory listings
too (it doesn't - this bug happens instead).

Changing status from WORKSFORME to REOPENED
M12 is not going to be the correct milestone anymore, is it?

Changing Summary from:
"[DOGFOOD] Unknown File Type error for file: URLs not ending in filename"
to "Unknown File Type error opening multiple file: directories"

Comment 9

[leger]

Bulk move of all Necko (to be deleted component) bugs to new Networking

component.

Comment 10

[Chris Waterson]

radha: the bug goes something like this. If you 1) use the "file:" browser, 2)
click on a file that will lead to a file with an unknown content type, then 3)
cancel the "download", the cancelled file will be added into the session
history, and is accessable via forward and back buttons. Seems like any unknown
file download that gets cancelled should -not- be added to session history.

Comment 11

[Jim Roskind]

Removing PDT annotation now that dogfood nomination has been removed.

Comment 12

[Claudius Gayle]

with 2000042109 builds the bug is just as waterson describes in his last comments: use file:///C| to navigate to something that 
typically prompts the unknown content dialog (a .exe file for example) click cancel, then back (dialog appears), cancel, forward 
(dialog appears).

with the 2000042512 builds however, the browser locks up when you click on an .exe file in this way. That may be due to some 
other instabilities as those builds are very shaky.

Comment 13

[don]

Move to M20 target milestone.

Comment 14

[Radha on family leave (not reading bugmail)]

I can't reproduce this any more. The second set of instructions seem to work 
fine too. 

Comment 15

[Tom Everingham]

verified - worksforme too

Comment 16

[benc]

XP-apss, this should be a testcase

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/726876a78584
[fenix] For https://github.com/mozilla-mobile/fenix/issues/5499 - Unify CFR drawables and dimens (https://github.com/mozilla-mobile/fenix/pull/12749)