Unknown File Type error opening multiple file: directories

VERIFIED WORKSFORME

Status

SeaMonkey
UI Design
P3
normal
VERIFIED WORKSFORME
19 years ago
14 years ago

People

(Reporter: Sean Richardson, Assigned: Radha on family leave (not reading bugmail))

Tracking

({testcase})

Trunk
x86
All
testcase

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

19 years ago
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.
(Reporter)

Comment 1

19 years ago
Created attachment 1441 [details]
Example of "Unknown File Type" dialog for this bug

Updated

19 years ago
Assignee: don → gagan
Component: Browser-General → Necko
(Reporter)

Comment 2

19 years ago
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.

Updated

19 years ago
Assignee: gagan → waterson

Comment 3

19 years ago
Chris you working on file directory listings?

Updated

19 years ago
Status: NEW → ASSIGNED
Summary: Unknown File Type error for file: URLs not ending in filename → [DOGFOOD] Unknown File Type error for file: URLs not ending in filename
Target Milestone: M12

Updated

19 years ago
Whiteboard: [PDT-]

Comment 4

19 years ago
If only file URLS, sorry PDT-.

Comment 5

19 years ago
Resetting QA contact from leger.

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → WORKSFORME

Comment 6

19 years ago
Hmm. This WORKSFORME. Guessing random sunspots fixed it.
(Reporter)

Comment 7

19 years ago
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.
(Reporter)

Updated

19 years ago
Summary: [DOGFOOD] Unknown File Type error for file: URLs not ending in filename → Unknown File Type error opening multiple file: directories
(Reporter)

Comment 8

19 years ago
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"
(Reporter)

Updated

19 years ago
Status: RESOLVED → REOPENED

Updated

19 years ago
Resolution: WORKSFORME → ---
Target Milestone: M12 → M13

Comment 9

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

component.

Updated

19 years ago
Assignee: waterson → radha
Status: REOPENED → NEW
Component: Networking → History
OS: Windows NT → All
Target Milestone: M13

Comment 10

19 years ago
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.
Status: NEW → ASSIGNED
Target Milestone: M15

Comment 11

19 years ago
Removing PDT annotation now that dogfood nomination has been removed.
Whiteboard: [PDT-]
Target Milestone: M15 → M16

Comment 12

18 years ago
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.

Updated

18 years ago
Target Milestone: M16 → M17

Comment 13

18 years ago
Move to M20 target milestone.
Target Milestone: M17 → M21
I can't reproduce this any more. The second set of instructions seem to work 
fine too. 
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago18 years ago
Resolution: --- → WORKSFORME

Comment 15

18 years ago
verified - worksforme too
Status: RESOLVED → VERIFIED

Comment 16

16 years ago
XP-apss, this should be a testcase
Component: History: Session → XP Apps
Keywords: testcase
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.