Closed
Bug 12749
Opened 25 years ago
Closed 24 years ago
Unknown File Type error opening multiple file: directories
Categories
(SeaMonkey :: UI Design, defect, P3)
Tracking
(Not tracked)
VERIFIED
WORKSFORME
People
(Reporter: sidr, Assigned: radha)
References
()
Details
(Keywords: testcase)
Attachments
(1 file)
1.76 KB,
image/gif
|
Details |
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•25 years ago
|
||
Updated•25 years ago
|
Assignee: don → gagan
Component: Browser-General → Necko
Reporter | ||
Comment 2•25 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•25 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•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
Comment 6•25 years ago
|
||
Hmm. This WORKSFORME. Guessing random sunspots fixed it.
Reporter | ||
Comment 7•25 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•25 years ago
|
URL: file:///c|/
Summary: [DOGFOOD] Unknown File Type error for file: URLs not ending in filename → Unknown File Type error opening multiple file: directories
Reporter | ||
Comment 8•25 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•25 years ago
|
Status: RESOLVED → REOPENED
Updated•25 years ago
|
Resolution: WORKSFORME → ---
Target Milestone: M12 → M13
Bulk move of all Necko (to be deleted component) bugs to new Networking component.
Updated•25 years ago
|
Assignee: waterson → radha
Status: REOPENED → NEW
Component: Networking → History
OS: Windows NT → All
Target Milestone: M13
Comment 10•25 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.
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M15
Comment 11•25 years ago
|
||
Removing PDT annotation now that dogfood nomination has been removed.
Whiteboard: [PDT-]
Assignee | ||
Updated•24 years ago
|
Target Milestone: M15 → M16
Comment 12•24 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•24 years ago
|
Target Milestone: M16 → M17
Assignee | ||
Comment 14•24 years ago
|
||
I can't reproduce this any more. The second set of instructions seem to work fine too.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → WORKSFORME
Comment 16•22 years ago
|
||
XP-apss, this should be a testcase
Component: History: Session → XP Apps
Keywords: testcase
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
Comment hidden (collapsed) |
You need to log in
before you can comment on or make changes to this bug.
Description
•