23175 - Crash when resolving "relative current directory" URL

Status: VERIFIED WONTFIX

(Core :: Networking, defect, P3)

Description

[Mats Palmgren (inactive)]

DESCRIPTION:
Crash when resolving "relative current directory" URL

STEPS TO REPRODUCE:
1. Start mozilla
2. enter file:x.html <RETURN> in URL bar

ACTUAL RESULTS:
t@1 (l@1) terminated by signal BUS (invalid address alignment)
(dbx) where
current thread: t@1
=>[1] Length__C18nsSimpleCharString(0x3033a, 0x72151c, 0xee37b8c0, 0x0, 0x5,
0xef400fc8), at 0xef415298
  [2] GetLeaf__C18nsSimpleCharStringc(0xee2937b0, 0x2f, 0x0, 0x5, 0x81010100,
0xff00), at 0xef412834
  [3] GetLeafName__C10nsFileSpec(0xee2937b0, 0xee37b8c0, 0x5, 0xef436828, 0x3ac,
0x721601), at 0xef412ae8
  [4] Read__22nsDirectoryIndexStreamPcUiPUi(0x721500, 0x724000, 0x800,
0xee2938a4, 0x35, 0xee2937b0), at 0xee35158c
  [5] 0xef41f250(0x721500, 0x724000, 0x0, 0x800, 0xee2938a4, 0x0), at 0xef41f24f
  [6]
WriteSegments__Q26nsPipe18nsPipeOutputStreamPFPvPcUiUiPUi_UiPvUiPUi(0x71b494,
0xef41f234, 0x721500, 0x800, 0xee293adc, 0xef41ee38), at 0xef41ef98
  [7] WriteFrom__Q26nsPipe18nsPipeOutputStreamP14nsIInputStreamUiPUi(0x71b494,
0x721500, 0x800, 0xee293adc, 0xef41f260, 0x30e600), at 0xef41f29c
  [8] Process__15nsFileTransport(0x681f00, 0x0, 0x5cc00, 0xef409544, 0x0,
0x57e00), at 0xee347d20
  [9] Run__15nsFileTransport(0x681f00, 0xee3479f8, 0x0, 0x0, 0x0, 0x0), at
0xee347a04
  [10] Run__20nsThreadPoolRunnable(0x9e480, 0xef431fa0, 0x9e480, 0xee293da0,
0xee293da0, 0x0), at 0xef431fe0
  [11] Main__8nsThreadPv(0x9e4a0, 0xef430d24, 0x0, 0x0, 0x0, 0x0), at 0xef430d40
  [12] 0xef357d60(0x50c, 0xee293e38, 0x0, 0x0, 0x0, 0x0), at 0xef357d5f
(dbx) quit

DOES NOT WORK CORRECTLY ON:
Mozilla nightly build 2000010211 on Sun/Solaris 2.6/sparc.

ADDITIONAL PLATFORMS TESTED ON:
Does not crash: Mozilla nightly build 2000010308 on Windows NT 4.0 sp6

Comment 1

[Sean Richardson]

There is currently discussion in bug 22251, "Relative URLs with scheme (e.g.,
http:page.html) not loading - treated as absolute", P2, M14,
about how to handle this sort of URL with a scheme but otherwise meant to
be relative. See the 1999-12-24 comment by [e-mail]:
code to properly handle this is not in yet.

Changing Component from "Browser-General" to "Networking"

Comment 2

[Warren Harris]

Probably a dup.

Comment 3

[Warren Harris]

Fixed with andreas' recent changes.

Comment 4

[Andreas Otte]

reopened because of backout

Comment 5

[Andreas Otte]

This will not make it into M13

Comment 6

[leger]

Clearing FIXED resolution due to reopen.

Comment 7

[leger]

Adding "crash" keyword to all known open crasher bugs.

Comment 8

[leger]

Putting on on PDT+ radar for beta1.

Comment 9

[Warren Harris]

Andreas, Is this fixed now?

Comment 10

[Andreas Otte]

I can't verify on solaris, but it is gone on linux, so I'm marking this
resolved.

Comment 11

[Chris McAfee]

Solaris did nothing with file:x.html
Linux prepends "file:///", which to me says
it's looking for /x.html, which is NOT a relative
file name.  This looks like it is not fixed,
please correct me or give a better description
of what the bug is and how we can verify it.  -mcafee

Comment 12

[Andreas Otte]

There is nothing like a relative URL in the URLbar. Those URLs are always
absolute. I think what linux trys to do here is correct, in correcting a failure
in submitting a valid url. What I don't understand is why solaris does nothing.
There is no platform specific code that could prevent that from happening.

file:x.html embedded in an html document is another thing, which is dealt with
in bug 22251

So I think this one is fixed, if solaris really does something different that
should be another bug.

Comment 13

[Mats Palmgren (inactive)]

Windows build behaves as Solaris - nothing happens.
My impression was when I reported this bug that file:x.html should be resolved
to file:///startup-directory/x.html (kind of like when giving a relative
filename on the command line) but maybe that is wrong.

Comment 14

[Andreas Otte]

What do you mean by "does nothing"? It should always add /// in this case
regardless of the platform. Of course the file can only be found if there is one
to find in the root directory with that name.

There certainly is a problem with windows or mac because the drivename is
missing. So adding the current drive/path might be a nice feature.

Comment 15

[Tom Everingham]

cc'ng mcafee

Comment 16

[Andreas Otte]

I just checked NS 4.61 on linux. file:x.html does not work at all, everytime I
get a box that communicator is unable to find the directory or file, even if
such a file exists in the root directory or the directory where communicator was
launched.

So I think mozilla is already doing a equal if not better job as NS 4.x at least
on linux.

Comment 17

[Warren Harris]

If 4.x doesn't do this, then I *don't* want to add it to mozilla, no matter what 
the html/url spec says. It's a pointless ambiguity in the spec, and can serve no 
useful purpose.

Let's mark this WONTFIX.

Comment 18

[Chris McAfee]

I never use this form of URL, probably
because it doesn't work.  I vote for won't fix as well.

Comment 19

[Andreas Otte]

I would mark this fixed. It does not crash anymore and such a url in the urlbar
makes no sense, this are always absolute urls and file:x.html is not.

Comment 20

[Chris McAfee]

Marking won't fix per warren's comments.
We can't be fixing things that aren't bugs,
file:foo is not a valid URL according to the
thread in this bug.  Please reopen if you disagree
with this resolution.

Comment 21

[Tom Everingham]

ok .. The crash (original problem) isn't happening on Chris's solaris so I am 
going to mark the bug verified.  The relative file handling is another issue but 
seems to have been resolved here too.