Bug report from Mathieu ARNOLD <email@example.com>: I put file:/c:/ into the location toolbar of viewer.exe I clicked on Program Files so, the location became : file://c:/Program Files then i clicked on directx and the location became : file://c:/directx which doesn't exist... so the displayed page remained the same. then i passed over 'Up to higher level directory' and the status bar displayed file:/// which doesn't exist at all, so, i clicked on it, and it crashed...
Adding original reporter to the CC list
Severity: normal → major
Priority: P2 → P1
Summary: Problems with file:/// url navigation and generated directory → ss:Crash with file:/// url navigation and generated directory
Putting on ss: radar.
confirmed that file:// or file://c:/ causes a crash on win95 xpviewer 11/23a build.
Summary: ss:Crash with file:/// url navigation and generated directory → problems with file:/// url navigation and generated directory
No longer crashing with 11/24 build on win95 xpviewer, but still some problems with file navigation. Taking off stop ship list and changing summary. The problems are still as angus noted. Gags, are you the person for this or someone else?
There are other bugs too that relate to the way the url is displayed in the location bar. Investigating...
file://C:/ URL works for HTML files (I have created a HTML file and I was able to open with viewer.exe). It seems to have problems opening .txt files. I was able to traverse the directories on the C: drive also. I will keep trying to narrow down. thanks, raman
I put file:/c:/ into the location toolbar of viewer.exe >I clicked on Program Files >so, the location became : file://c:/Program Files >then i clicked on directx >and the location became : file://c:/directx which doesn't exist... >so the displayed page remained the same. The above still seems to happen. In 4.x, the URL was being escaped (adding %..) and in 5.0 we don't seem to do that. That could be the cause of the problem. thanks, raman
*** Bug 1915 has been marked as a duplicate of this bug. ***
Setting all current Open Critical and Major to M3
I thought raman is no longer working on netlib - giving back to gags.
setting paulmac as QA contact for all gagan's bugs (sorry for the spam)
Fixed with N2.
Netlib rewrite should take care of this
Per DP's suggestion marking these till M8. Though Necko lands with M7, we will be able to verify it for M8.
Necko landing in M8, moving to M9
Necko landing in M8, moving to M9
Changing all Networking Library/Browser bugs to Networking-Core component for Browser. Occasionally, Bugzilla will burp and cause Verified bugs to reopen when I do this in a bulk change. If this happens, I will fix. ;-)
Check with Necko please.
Summary: problems with file:/// url navigation and generated directory → NECKO: problems with file:/// url navigation and generated directory
this is a dup of another bug warren has *** This bug has been marked as a duplicate of 6936 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 20 years ago
Resolution: --- → DUPLICATE
Bulk move of all Networking-Core (to be deleted component) bugs to new Networking component.
Component: Networking → Networking: File
Summary: NECKO: problems with file:/// url navigation and generated directory → file:/// url navigation and generated directory
You need to log in before you can comment on or make changes to this bug.