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

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

i will take a look at this.

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

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

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.

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.

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

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

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.

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

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

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

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

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

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

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

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

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?

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

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

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.

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

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

adding keywords for fun

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

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