185663 - Browser freezes if I browse to // from the url bar

Status: VERIFIED WORKSFORME

(SeaMonkey :: Location Bar, defect)

Description

[Timothy]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3a) Gecko/20021212
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3a) Gecko/20021212

My browser freezes when I let it browse to  //  .
It will not respond to any interaction like mouse clicks or keyboard shortcuts,
but still keeps itself visible in a way that the program is "working", and not
crashing. In the meanwhile it starts eating memory and CPU usage until the whole
system crashes, but that only happens after about 1 minute if the browser isn’t
shut down with task manager.

Reproducible: Always

Steps to Reproduce:
1. Type  //  as location url
2. Hit enter

Actual Results:  
The browser froze, and didnt respond to any input.
In the meanwhile it started to eat all the internall memory and CPU usage,
Causing a full OS crash

Expected Results:  
Change the  //  url into  http:///

Comment 1

[Matthias Versen [:Matti]]

looks releated to bug 134793.

mozilla must not convert to http:// but it should not hang.

-> darin (or possible URL Bar ?)

Comment 2

[Matthias Versen [:Matti]]

assertion loop :
###!!! ASSERTION: You can't |write| into an |nsWritingIterator| with no space!:
'size_forward() > 0', file ../../dist/include/string\nsStringIterator.h, line 36
4
###!!! ASSERTION: |copy_string| will never terminate: 'count_copied > 0', file .
./../dist/include/string\nsAlgorithm.h, line 91
###!!! ASSERTION: You can't |write| into an |nsWritingIterator| with no space!:
'size_forward() > 0', file ../../dist/include/string\nsStringIterator.h, line 36
4
###!!! ASSERTION: |copy_string| will never terminate: 'count_copied > 0', file .
./../dist/include/string\nsAlgorithm.h, line 91
###!!! ASSERTION: You can't |write| into an |nsWritingIterator| with no space!:
'size_forward() > 0', file ../../dist/include/string\nsStringIterator.h, line 36

Comment 3

[Nicholas Allen]

*** This bug has been marked as a duplicate of 163405 ***

Comment 4

[Matthias Versen [:Matti]]

reopening because this bug should be a) in networking until darin decides this
should go to URL bar and b) this bug conatins more information

Comment 5

[Matthias Versen [:Matti]]

*** Bug 163405 has been marked as a duplicate of this bug. ***

Comment 6

[benc]

Two points:

1- My personal preference is that duplicates should go to the first reporter. It
is sort of a way for giving them "credit", because that bug remains open.
However, sometimes bugs do not get enough analysis, or someone comes along with
a better description and the community find the later duplicate more useful. So
be it.

2- The litmus test for "URL bar" vs. "Necko" bugs is this:

Put the questionable input into a html document as an HREF. Click on it. If it
works fine in a link, Necko is not at fault.

So in this case, if you look at the URL field of the previous bug, and click on
the link (viewsource says " <a href="//">", you find that Necko returns an error.

So this should go to URL bar. (Lets not reverse the duplicate again, things are
fine the way they are now.)

BTW, "//" messes up Phoenix 0.4, Win 98 as well...

Comment 7

[Matthias Versen [:Matti]]

*** Bug 192115 has been marked as a duplicate of this bug. ***

Comment 8

[Matthias Versen [:Matti]]

*** Bug 195072 has been marked as a duplicate of this bug. ***

Comment 9

[Ed Lana]

On the Mac OSX 10.2 Mozilla 1.3a 20021129
// in the URL bar is automatically changed to file:/// and a file list is
displayed.  The system does not hang.

I have also experienced the // hang on Win98 with Mozilla 1.2.1 and 1.3
Gecko/20030310

Comment 10

[Alexey Lokhin]

In my case (Mozilla 1.3b Gecko/20030218, Linux i686) "//" changes to "file:///".
But "://" completely freezes X.
Different troubles?

Comment 11

[Matthias Versen [:Matti]]

*** Bug 133700 has been marked as a duplicate of this bug. ***

Comment 12

[Benedikt Kantus]

*** Bug 207739 has been marked as a duplicate of this bug. ***

Comment 13

[Oleg Sidletskiy]

*** Bug 216369 has been marked as a duplicate of this bug. ***

Comment 14

[Matthias Versen [:Matti]]

*** Bug 219911 has been marked as a duplicate of this bug. ***

Comment 15

[Will Levine]

This seems to be resolved in nightlies.  I now get the message "The URL is not
valid and cannot be loaded" message instead of a hang.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:) Gecko/20040227

Comment 16

[Henrik Skupin [:whimboo][⌚️UTC+1]]

*** Bug 237281 has been marked as a duplicate of this bug. ***

Comment 17

[Henrik Skupin [:whimboo][⌚️UTC+1]]

WFM Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040310

Marking as WORKSFORME. Reporter if you always see this problem feel free to
reopen the bug.

Comment 18

[alanjstr]

Currently tries to take me to http:///

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040229
Firefox/0.8.0+ (djeter)

Results in 

The address (URL) is not a valid format and cannot be read. A typical address
will start with "http://", followed by an address, (e.g. www.netscape.com),
followed by a path to the content (or just "/"). A common cause for the problem
is using backslashes(\) instead of forward slashes (/).

Comment 19

[WD]

*** Bug 237449 has been marked as a duplicate of this bug. ***