87243 - URL bar doesn't work - sessionHistoryUI.js :: addToUrlbarHistory :: line 157

Status: VERIFIED DUPLICATE of bug 83489

(Core :: DOM: Navigation, defect, P1)

Description

[Chris Hiner]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.1+) Gecko/20010621
BuildID:    cvs from 20010621 9:13PM

If you type a url that you havn't been to before into the location bar and press
enter or the go button, nothing happens.

Reproducible: Always
Steps to Reproduce:
1.  Type www.example.com into location
2.   press enter or the go button.

Actual Results:  Nothing, except a javascript error:
Error: uncaught exception: [Exception... "Component returned failure code:
0x804b0012 [nsIIOService.newURI]" nsresult: "0x804b0012 (<unknown>)" location:
"JS frame :: chrome://navigator/content/sessionHistoryUI.js ::
addToUrlbarHistory :: line 157" data: no]

Expected Results:  Go to url.
Guessing ->session history

Comment 1

[Chris Hiner]

Looks like it was caused by the landing of bug 73845.  Doesn't seem to like:
157                              var rdfUri = ioService.newURI(rdfValue, null);

Comment 2

[Doug Turner (:dougt)]

i will take a look at this.

Comment 3

[Doug Turner (:dougt)]

I don't know why or how this worked on my branch. I just checked in a fix.  

Checking in sessionHistoryUI.js;
/cvsroot/mozilla/xpfe/browser/resources/content/sessionHistoryUI.js,v  <--  
sessionHistoryUI.js
new revision: 1.23; previous revision: 1.22
done

Comment 4

[Jacob Kjome]

bug 87280 seems like a dup of this.  However, the behavior is still being 
noticed in today's builds where the fix should already have been applied.  

A workaround was noted in that bug:  Delete Session History, then everything 
works.

Is that workaround really necessary?  Can this be considered fixed when it 
necessitates deleting our precious session history?

Jake

Comment 5

[Chris Hiner]

Yes, this was still broken for me with a fresh cvs build this afternoon.  Using
the workaround from bug 87280
 (clearing session/location bar history) fixed it for me.

Comment 6

[Claudius Gayle]

VERIFIED Fixed with 2001062211 builds on all platforms. I should note that
www.example.com doesn't load for me in any browser - so that's maybe not the best way
to test.

Comment 7

[basic]

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

Comment 8

[Jacob Kjome]

Claudius,

the www.example.com situation is covered by bug 86133 where you get no DNS 
notification error.  It looks like the same behavior as this bug since nothing 
happens in both cases, but it is different behavior.

jake

Comment 9

[Chris Hiner]

I gave example.com as a url because noone would have had a reason to have tried
going there.  It kicked up the JS error without making the throbber move.  I get
a nice error from my proxy server when it can't connect, and I forgot that not
everyone has that luxury.

Comment 10

[Thomas Swan]

Not fixed

Still showing in win32-installer.exe build 2001062218 (latest-0.9.2) and
preceding nightly latest.

Comment 11

[Thomas Swan]

Never mind... didn't clear URL history... (my error)

Comment 12

[R.K.Aa.]

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

Comment 13

[Miloslaw Smyk]

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

Comment 14

[Miloslaw Smyk]

Yup, not fixed - I'm experiencing it with 2001062306 under Linux/i386. Reopening.

Comment 15

[Francisco León]

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

Comment 16

[Francisco León]

Workaround for this
Copy the url to the clipboard and then paste it into the browser window
That will keep me until this is fixed
Going into File|Open web location really takes too much time

Comment 17

[Francisco León]

You may find this important
Clearing my session history worked on my same build 2001062306
Can this be considered a fix? Well, asumming that this is the start build of
anyone then they wont notice this, so i could take it as fixed

Comment 18

[Miloslaw Smyk]

Ok, seems one has to clear URL history first.

However, will it fix itself automatically after a while for people who won't
clear the history?

Comment 19

[Francisco León]

Well, with the default settings the history saves 50 pages, and lasts for 9
days, so multiply 9x50 and the worst case scenario would be to have wait 450
days until the bug washes out
So of course we cannot relay on that. History must be cleared manually

Comment 20

[Jacob Kjome]

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

Comment 21

[Chris Hiner]

I did some digging, and I think know what's causing this.
If your history has any urls like telnet://something, or rtsp://something, then
the current code fails when it passes it to newURI.
I propose these 2 changes to
/mozilla/xpfe/browser/resources/content/sessionHistoryUI.js:
Orig:
141  var uriToAdd = ioService.newURI(urlToAdd, null);
167  var rdfUri = ioService.newURI(rdfValue, null);
New:
141  try {
          var uriToAdd  = ioService.newURI(urlToAdd, null); 
       } catch(e) {
         return;
       }                                                                        
167        try {
               var rdfUri = ioService.newURI(rdfValue, null);
             } catch(e) {
               continue;
             }                                                                  

I restored my old history, and this fixed the problem.
It also makes it more robust in terms of handling weird things in the history
and url bars.

Comment 22

[Kirill Yushkov]

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

Comment 23

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

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

Comment 24

[Aaron Kaluszka]

adding keywords for fun

Comment 25

[Alec Flett]

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

Comment 26

[Claudius Gayle]

VERIFIED Dupe. If you'll read my last comments you'll see that I did
NOT use www.example dotcom to test b/c as I said it did not resolve in
any browser for me at the time