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

VERIFIED WORKSFORME

Status

--
critical
VERIFIED WORKSFORME
16 years ago
10 years ago

People

(Reporter: Webmaster, Assigned: hewitt)

Tracking

({hang})

Trunk
x86
Windows XP

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

16 years ago
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:///

Updated

16 years ago
Keywords: hang
looks releated to bug 134793.

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

-> darin (or possible URL Bar ?)
Assignee: asa → darin
Status: UNCONFIRMED → NEW
Component: Browser-General → Networking: HTTP
Ever confirmed: true
QA Contact: asa → httpqa
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

16 years ago

*** This bug has been marked as a duplicate of 163405 ***
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE
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
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
*** Bug 163405 has been marked as a duplicate of this bug. ***

Comment 6

16 years ago
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...
Assignee: darin → hewitt
Status: REOPENED → NEW
Component: Networking: HTTP → URL Bar
QA Contact: httpqa → claudius
*** Bug 192115 has been marked as a duplicate of this bug. ***
*** Bug 195072 has been marked as a duplicate of this bug. ***

Comment 9

16 years ago
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

16 years ago
In my case (Mozilla 1.3b Gecko/20030218, Linux i686) "//" changes to "file:///".
But "://" completely freezes X.
Different troubles?
*** Bug 133700 has been marked as a duplicate of this bug. ***

Comment 12

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

Comment 13

15 years ago
*** Bug 216369 has been marked as a duplicate of this bug. ***
*** Bug 219911 has been marked as a duplicate of this bug. ***

Comment 15

15 years ago
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
*** Bug 237281 has been marked as a duplicate of this bug. ***
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.
Status: NEW → RESOLVED
Last Resolved: 16 years ago15 years ago
Resolution: --- → WORKSFORME

Comment 18

15 years ago
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 (/).

Status: RESOLVED → VERIFIED

Comment 19

15 years ago
*** Bug 237449 has been marked as a duplicate of this bug. ***
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.