Closed Bug 24431 Opened 25 years ago Closed 21 years ago

file: hosts that are DOS drives, move to path ("Drive promotion", Win only)

Categories

(Core :: Networking: File, defect, P3)

x86
Windows NT
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: rickg, Assigned: gagan)

References

()

Details

(Keywords: testcase, Whiteboard: [PDT-] rubberstamp)

Set breakpoints in the htmlparser\nsParser.cpp file, in the OnDataAvailable(),
OnStartXXX() and OnStopXXX() methods. Then enter this URL, and you'll see that
the parser is never called.
Target Milestone: M14
I fixed the case where we only have 2 slashes in the file: URL -- the c| ends up 
becoming the host name. Andreas should think about that one. Here's what I 
added:

Index: nsStdURL.cpp
===================================================================
RCS file: /cvsroot/mozilla/netwerk/base/src/nsStdURL.cpp,v
retrieving revision 1.38
diff -c -r1.38 nsStdURL.cpp
*** nsStdURL.cpp	2000/01/24 23:18:44	1.38
--- nsStdURL.cpp	2000/01/28 07:35:45
***************
*** 1313,1318 ****
--- 1313,1328 ----
          if (path.CharAt(0) == '/')
              path.Cut(0, 1);
      }
+     else if (mHost) {
+         // Deal with the case where the user type file://C|/ (2 slashes 
instead of 3).
+         // In this case, the C| ends up as the host name (ugh).
+         nsCAutoString host(mHost);
+         PRInt32 len = host.Length();
+         if (len == 2 && host.CharAt(1) == '|') {
+             host.SetCharAt(':', 1);
+             path.Insert(host, 0);
+         }
+     }
      path.ReplaceChar('/', '\\');
  #elif defined(XP_MAC)
  	// For now we'll just convert the /'s into :'s to make it look like a 
Mac path

However, there are 2 more problems here:

1. the directory listing comes up blank (I think there's a bug on that elsewhere 
-- Jud can you verify?)

2. the error propagated from nsStdURL::GetFile goes all the way up to 
nsWebShell::LoadURL, then to nsBrowserInstance::LoadUrl and then disappears into  
xpconnect. However when it comes out the other end of the js interpreter in 
nsJSEventListener::HandleEvent, the error is gone. I suspect that the js code is 
dropping the error somewhere along the way. Here's the stack where this happens:

nsStdURL::GetFile(nsStdURL * const 0x02abb640, nsIFile * * 0x02ab94fc) line 1310
nsFileChannel::Init(const char * 0x00380704, nsIURI * 0x02abb640, nsILoadGroup * 
0x02432930, nsIInterfaceRequestor * 0x024311cc, unsigned int 0x00000000, nsIURI 
* 0x00000000, unsigned int 0x00000000, unsigned int 0x00000000) line 84 + 53 
bytes
nsFileProtocolHandler::NewChannel(nsFileProtocolHandler * const 0x00c8a1c0, 
const char * 0x00380704, nsIURI * 0x02abb640, nsILoadGroup * 0x02432930, 
nsIInterfaceRequestor * 0x024311cc, unsigned int 0x00000000, nsIURI * 
0x00000000, unsigned int 0x00000000, unsigned int 0x00000000, nsIChannel * * 
0x0012d208) line 144 + 40 bytes
nsIOService::NewChannelFromURI(nsIOService * const 0x00c86cd0, const char * 
0x00380704, nsIURI * 0x02abb640, nsILoadGroup * 0x02432930, 
nsIInterfaceRequestor * 0x024311cc, unsigned int 0x00000000, nsIURI * 
0x00000000, unsigned int 0x00000000, unsigned int 0x00000000, nsIChannel * * 
0x0012d208) line 276 + 59 bytes
nsDocLoaderImpl::LoadDocument(nsDocLoaderImpl * const 0x02432990, nsIURI * 
0x02abb640, const char * 0x00380704, nsISupports * 0x02431260, nsIInputStream * 
0x00000000, nsISupports * 0x00000000, unsigned int 0x00000000, const unsigned 
int 0x00000000, const unsigned short * 0x00000000) line 362 + 105 bytes
nsWebShell::DoLoadURL(nsIURI * 0x02abb640, const char * 0x00380704, 
nsIInputStream * 0x00000000, unsigned int 0x00000000, const unsigned int 
0x00000000, const unsigned short * 0x00000000, int 0x00000001) line 1722 + 101 
bytes
nsWebShell::LoadURI(nsWebShell * const 0x02431260, nsIURI * 0x02abb640, const 
char * 0x00380704, nsIInputStream * 0x00000000, int 0x00000001, unsigned int 
0x00000000, const unsigned int 0x00000000, nsISupports * 0x00000000, const 
unsigned short * 0x00000000) line 1996 + 40 bytes
nsWebShell::LoadURL(nsWebShell * const 0x02431260, const unsigned short * 
0x02abb030, const char * 0x00380704, nsIInputStream * 0x00000000, int 
0x00000001, unsigned int 0x00000000, const unsigned int 0x00000000, nsISupports 
* 0x00000000, const unsigned short * 0x00000000) line 2227 + 52 bytes
nsWebShell::LoadURL(nsWebShell * const 0x02431260, const unsigned short * 
0x02abb030, nsIInputStream * 0x00000000, int 0x00000001, unsigned int 
0x00000000, const unsigned int 0x00000000, nsISupports * 0x00000000, const 
unsigned short * 0x00000000) line 1525
nsBrowserInstance::LoadUrl(nsBrowserInstance * const 0x026e95e0, const unsigned 
short * 0x02abb030) line 962 + 37 bytes
XPTC_InvokeByIndex(nsISupports * 0x026e95e0, unsigned int 0x00000007, unsigned 
int 0x00000001, nsXPTCVariant * 0x0012dc4c) line 139
nsXPCWrappedNativeClass::CallWrappedMethod(JSContext * 0x01e78a00, 
nsXPCWrappedNative * 0x026ea800, const XPCNativeMemberDescriptor * 0x026eaca4, 
nsXPCWrappedNativeClass::CallMode CALL_METHOD, unsigned int 0x00000001, long * 
0x024bcf90, long * 0x0012de08) line 898 + 43 bytes
WrappedNative_CallMethod(JSContext * 0x01e78a00, JSObject * 0x00d94738, unsigned 
int 0x00000001, long * 0x024bcf90, long * 0x0012de08) line 200 + 34 bytes
js_Invoke(JSContext * 0x01e78a00, unsigned int 0x00000001, unsigned int 
0x00000000) line 666 + 26 bytes
js_Interpret(JSContext * 0x01e78a00, long * 0x0012e684) line 2262 + 15 bytes
js_Invoke(JSContext * 0x01e78a00, unsigned int 0x00000000, unsigned int 
0x00000000) line 682 + 13 bytes
js_Interpret(JSContext * 0x01e78a00, long * 0x0012eebc) line 2262 + 15 bytes
js_Invoke(JSContext * 0x01e78a00, unsigned int 0x00000001, unsigned int 
0x00000002) line 682 + 13 bytes
js_InternalInvoke(JSContext * 0x01e78a00, JSObject * 0x024716c8, long 
0x024716e8, unsigned int 0x00000000, unsigned int 0x00000001, long * 0x0012f044, 
long * 0x0012eff0) line 759 + 19 bytes
JS_CallFunctionValue(JSContext * 0x01e78a00, JSObject * 0x024716c8, long 
0x024716e8, unsigned int 0x00000001, long * 0x0012f044, long * 0x0012eff0) line 
2771 + 31 bytes
nsJSContext::CallEventHandler(nsJSContext * const 0x01e78b90, void * 0x024716c8, 
void * 0x024716e8, unsigned int 0x00000001, void * 0x0012f044, int * 0x0012f040) 
line 562 + 33 bytes
nsJSEventListener::HandleEvent(nsIDOMEvent * 0x02abace4) line 128 + 57 bytes
nsEventListenerManager::HandleEventSubType(nsListenerStruct * 0x022549b0, 
nsIDOMEvent * 0x02abace4, unsigned int 0x00000002) line 680 + 19 bytes
nsEventListenerManager::HandleEvent(nsIPresContext * 0x01e7be60, nsEvent * 
0x0012f4f0, nsIDOMEvent * * 0x0012f438, unsigned int 0x00000007, nsEventStatus * 
0x0012f534) line 1032 + 25 bytes
nsGenericElement::HandleDOMEvent(nsIPresContext * 0x01e7be60, nsEvent * 
0x0012f4f0, nsIDOMEvent * * 0x0012f438, unsigned int 0x00000001, nsEventStatus * 
0x0012f534) line 809
nsHTMLInputElement::HandleDOMEvent(nsHTMLInputElement * const 0x02254e10, 
nsIPresContext * 0x01e7be60, nsEvent * 0x0012f4f0, nsIDOMEvent * * 0x00000000, 
unsigned int 0x00000001, nsEventStatus * 0x0012f534) line 739 + 31 bytes
nsEnderEventListener::KeyUp(nsIDOMEvent * 0x02abad44) line 3390 + 62 bytes
nsEventListenerManager::HandleEvent(nsIPresContext * 0x02a0dbe0, nsEvent * 
0x0012f9fc, nsIDOMEvent * * 0x0012f784, unsigned int 0x00000002, nsEventStatus * 
0x0012f968) line 993 + 17 bytes
nsDocument::HandleDOMEvent(nsDocument * const 0x02a0f450, nsIPresContext * 
0x02a0dbe0, nsEvent * 0x0012f9fc, nsIDOMEvent * * 0x0012f784, unsigned int 
0x00000002, nsEventStatus * 0x0012f968) line 2423
nsHTMLHtmlElement::HandleDOMEvent(nsHTMLHtmlElement * const 0x02a0f27c, 
nsIPresContext * 0x02a0dbe0, nsEvent * 0x0012f9fc, nsIDOMEvent * * 0x0012f784, 
unsigned int 0x00000002, nsEventStatus * 0x0012f968) line 192 + 41 bytes
nsGenericElement::HandleDOMEvent(nsIPresContext * 0x02a0dbe0, nsEvent * 
0x0012f9fc, nsIDOMEvent * * 0x0012f784, unsigned int 0x00000002, nsEventStatus * 
0x0012f968) line 811 + 39 bytes
nsHTMLBodyElement::HandleDOMEvent(nsHTMLBodyElement * const 0x02a0de7c, 
nsIPresContext * 0x02a0dbe0, nsEvent * 0x0012f9fc, nsIDOMEvent * * 0x0012f784, 
unsigned int 0x00000002, nsEventStatus * 0x0012f968) line 715
nsGenericDOMDataNode::HandleDOMEvent(nsIPresContext * 0x02a0dbe0, nsEvent * 
0x0012f9fc, nsIDOMEvent * * 0x0012f784, unsigned int 0x00000001, nsEventStatus * 
0x0012f968) line 799 + 39 bytes
nsTextNode::HandleDOMEvent(nsTextNode * const 0x02a8974c, nsIPresContext * 
0x02a0dbe0, nsEvent * 0x0012f9fc, nsIDOMEvent * * 0x00000000, unsigned int 
0x00000001, nsEventStatus * 0x0012f968) line 234
PresShell::HandleEvent(PresShell * const 0x02a6de74, nsIView * 0x02a836c0, 
nsGUIEvent * 0x0012f9fc, nsEventStatus * 0x0012f968) line 2831 + 39 bytes
nsView::HandleEvent(nsView * const 0x02a836c0, nsGUIEvent * 0x0012f9fc, unsigned 
int 0x00000008, nsEventStatus * 0x0012f968, int & 0x00000000) line 797
nsView::HandleEvent(nsView * const 0x02a83e10, nsGUIEvent * 0x0012f9fc, unsigned 
int 0x00000008, nsEventStatus * 0x0012f968, int & 0x00000000) line 782
nsView::HandleEvent(nsView * const 0x02a6c460, nsGUIEvent * 0x0012f9fc, unsigned 
int 0x0000001c, nsEventStatus * 0x0012f968, int & 0x00000000) line 782
nsViewManager::DispatchEvent(nsViewManager * const 0x02a6cb30, nsGUIEvent * 
0x0012f9fc, nsEventStatus * 0x0012f968) line 1705
HandleEvent(nsGUIEvent * 0x0012f9fc) line 69
nsWindow::DispatchEvent(nsWindow * const 0x02a83ce4, nsGUIEvent * 0x0012f9fc, 
nsEventStatus & nsEventStatus_eIgnore) line 507 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012f9fc) line 528
nsWindow::DispatchKeyEvent(unsigned int 0x00000084, unsigned short 0x000d, 
unsigned int 0x0000000d) line 2294 + 15 bytes
nsWindow::OnKeyUp(unsigned int 0x0000000d, unsigned int 0x0000c01c) line 2454
nsWindow::ProcessMessage(unsigned int 0x00000101, unsigned int 0x0000000d, long 
0xc01c0001, long * 0x0012fda0) line 2700 + 34 bytes
nsWindow::WindowProc(HWND__ * 0x04f00a62, unsigned int 0x00000101, unsigned int 
0x0000000d, long 0xc01c0001) line 693 + 27 bytes
USER32! 77e71820()


Although the original problem has now gone away, you can simulate the error by 
forcing an error code to be returned from nsStdURL::GetFile in the debugger, or 
by trying other bogus file: URLs, like 'file://' (no 'C|/').

Updatng the URL above.
Passing this along to Jud to investigate
Cc'ing Matt to help us sort out any js problems
Cc'ing Travis to help with webshell problems (dropped error dialog, etc.)

Assignee: warren → valeski
dir listing failure = 25303
Hi warren!

I thought about that file:// case ... that's why there is the nsNoAuthURLParser 
...

Keywords: beta1
Putting on PDT+ radar for beta1.
Whiteboard: [PDT+]
This one should be gone, can you verify Judson?
This is now a dupe of 13607. We need to spit back drive volumes in a tree if 
nothing is specified. I may be missing something here. If so, straighten me out.

*** This bug has been marked as a duplicate of 13607 ***
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
verified dupe of 13607
Status: RESOLVED → VERIFIED
REOPENING:
The original problem should be qa'd.

The remaning problem after this fix is 13607.

works for me NS6.1 Win32.
testcase:
type: file://c|/ into URL field
see: file:///c|/ displayed correctly.
Status: VERIFIED → REOPENED
Keywords: nsbeta1testcase, verifyme
Resolution: DUPLICATE → ---
Summary: Parser is never called on this (badly formed) dir URL → localize hostless file URL's (file://c|/ -> file:///c|/)
-> file
Component: Networking → Networking: File
is this working on the 0.9.4 branch?
removing pdt+ and adding nsbranch+
Keywords: nsbranch+
Whiteboard: [PDT+]
-> gagan for triage.
Assignee: valeski → gagan
Status: REOPENED → NEW
this works for me.  benc do you still see any problems here?
I'm not sure the behavior is ideal...
PDT- given that it is hard to reproduce.
Whiteboard: [PDT-]
I'll check on Windows NT, but after triaging the rest of the component this
week, I have heard signs that this might be needed because some authoring
packages create these bogus file URL formats in Win32 environments.

So, unless there is some other behavioral concern, I expect to make this WFM soon.
QA Contact: tever → benc
Mozilla 0.9.4

Win98:

file://c:/ -> file:///c:/
file://c|/ -> file:///c|/

These tree displays seem to work fine.

RESOLVED:
I'm marking this WFM for Windows.

I have decided that this behavior is potentially user-friendly on Windows, and 
even if we add host checking, these aren't valid host strings, so we should do 
this BEFORE a file URL hostcheck, and everything will be fine.

In Mac and Linux:
file://c:/ -> file:///[c:]/
file://c|/ -> file:///c%7C/

Are discussed in bug 102724 and bug 70841.
Status: NEW → RESOLVED
Closed: 25 years ago23 years ago
Keywords: verifyme
Resolution: --- → WORKSFORME
Summary: localize hostless file URL's (file://c|/ -> file:///c|/) → file: hosts that are DOS drives, move to path (Win only)
+verifyme:

anyone w/ windows: can you try the two file URL's and see if you "C" drive shows
up correctly?

If so, please verify (and make my boss happy!)
Keywords: verifyme
Whiteboard: [PDT-] → [PDT-] rubberstamp
My windows build (win95) is back up! Verifying! Works fine. A drive as host
moves into the path.
Status: RESOLVED → VERIFIED
Keywords: verifyme
REOPEN: I read this bug wrong, it was actually fixed, not WFM.
This is for all the contributors that care about the difference...
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---
RESOLVED/fixed.
I'm also somewhat embarrassed too..
Status: REOPENED → RESOLVED
Closed: 23 years ago21 years ago
Resolution: --- → FIXED
VERIFIED/fixed:
it's amazing what you will do while playing the simms on your day off...
This behavior needed a name to, for documetnation, so I'm using the term I've
used elsewhere. Nobody had complained thus far.
Status: RESOLVED → VERIFIED
Summary: file: hosts that are DOS drives, move to path (Win only) → file: hosts that are DOS drives, move to path ("Drive promotion", Win only)
You need to log in before you can comment on or make changes to this bug.