Type in a url in the url bar and hit enter. Result: nothing happens..

any messages on the console? I sometimes accidentally put myself in offline yesterday, maybe its related.

or could be a dupe of bug 82297

Alec: I don't hit this problem all the time...it happens now and then. And, btw, I was online:)

Happens after theme change, see 82297.

This happens to me a lot. It seems to have gotten worse over the last couple of weeks. What happens is that after a while mozilla enters a state where if you type something into the url-bar, Mozilla does something and then it redraws the page as you were viewing before typing into the url-bar. Links and bookmarks still work Ok. The only way out of it is to restart mozilla. WinNT, Build 2001061204 (same thing with all builds I've tried over the last few weeks.)

This bug is serious in 2001062104 build in my PC. It just work once (the first URL I type) then stop working. Restart, work once again, then stop working.

Outputs to console on hitting enter: 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] Using build 2001062104

hrm.. that latest exception looks like doug's work :)

it would be nice to know what url was passed to newURI.

I have noticed that as of todays latest build (June 22, 2001) if you type in a URL not already in the location bar and hit enter, nothing happens. However, if you type in a URL that is already there it autocompletes and enter does its thing. This is on Linux with the Modern theme (if that makes any difference).

what does the URL string that you type in look like?

Doug - I'm now having it happen to me, with a local file url like c:\alecf\foo.html I've got a fix, attaching it now

this is an RTM stopper, marking 0.9.2 and nominating nsbeta1

r=dougt

What about the newURI on line 141? Adding a try/catch around that newURI will fix the problems discussed in 87250. The catch should append |urlToAdd| to "http://".

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

I've also seen this typing in full http:// urls as well. It's not just file names.

There's a recent regression that makes this happen more often: bug 87243.

Workaround: delete session history Bug clears itself

alecf, What about dougt's comments? Are they valid? Otherwise I'm ready to approve this.

One of the cases that'll cause newURI to fail, are URL's like telnet:// or rtsp://, which prepending http:// doesn't really help. Also, prepending http:// on extractScheme failure causes URLs like: "bug 87243" (bookmark keyword) to be saved as http://bug 87243 which then don't work when you select them in URL bar history. Prepending http:// does fix bug 87250, which deals with "www.google.com:80" type URL's not working. I'd suspect that if it can't make a URI out of it at line 141, then it'd be best to just string compare it down around line 167. My simple patch in bug 87243 just returns on error on the newURI on 141, and skips the URL on error on the newURI on line 167. It would cause odd things like telnet://, rtsp:// or bookmark keywords to not go into the history at all, which probably is not the desired effect, but might be a short term fix to make the nightly builds (and the branch) usable again. 87243 is a smoketest blocker, and is headed for mostfreq quickly.

adding keywords for fun

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

ok, the latest patch handles one other case - where the user actually enters a "bad" url on the url bar (as opposed to the previous fix, which only fixed the case where the user had a "bad" url in their urlbar history) in any case, what this now does is handle BOTH cases, and if either case happens, then we do a raw string compare.. I fiddled a bit with the if() statements and reindented some of this function because it was getting really confusing, so I have attached a diff -bw - don't worry about the funny formatting, just pay attention to the logic.

r=dougt for patch 39916

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

This latest patch fixes all the problems for me. I don't know if it's something on my end, but I had to apply it by hand, patch didn't like it. Adding mostfreq based on dups of 87243 and 87250. It still mis-adds http:// to things like bookmark keywords, but that should be another bug.

r/sr=blizzard

a=chofmann branch and trunk

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

alright, this damn thing is finally checked in!

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

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

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

Regression. I am seeing this in 2001062504.

Clear your history session. It works for me

This isn't working for me either in 2001062504 on Windows 2000. I cleared my history totally and even quit and restart, and typing anything in the URL bar and hitting enter still doesn't do anything.

I did Clear History and Clear Location Bar and now it is working.

Yeah, now it works. I hadn't cleared my location bar history, but clearing that made it work.

for goodness sakes, I JUST checked in the fix. give the builds a chance to pick it up! The first build that will show the fix will be 2001-06-26-??

So, the patch isn't neccesary at all? Build from the 23th showed this bug and i just deleted session history and it was fixed. So if this patch also requires you to delete it (alec, is it needed in the patch?) then this patch is useless. WFM

no, the patch is what I checked in. with the patch, there is no need to delete your session history - that was just a workaround that someone presented here, until we finished the patch.

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

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

I'm still seeing problems today with a 2001062704 build on Windows ME. I was at slashdot, typed in a new URL and hit enter and it just reloaded slashdot with the new URL still showing in the textbox. Afterwards the URL bar would not accept input on any of the open windows.

I tried this with yesterday's build on my WinME machine, and it worked. I don't know if I did anything else to make it start working again. It's possible I cleared my history.

I also cleared my history (speaking of which, why is it that you can only clear the history from the preferences panel and not directly in the History window???). Unfortunately I don't know what sequence of events I did to make the URL bar stop responding since I was multitasking at the time it happened.

Okay, I found a sequence that seems to cause this more frequently than other situations... 1) No Mozilla windows open 2) Receive mail in Outlook containing a link 3) Click on link 4) Two Mozilla windows open up (?!?!?) 5) The first Mozilla window loads the link but the URL bar is blank 6) The blank bar is then unresponsive. 7) The second Mozilla window that opened does not open any page, but the URL bar is generally working This doesn't happen all the time, but it seems to happen quite often on my machine. Btw, this just happened with the 2001062804 build that I just installed.

Yep, see my comments on 2001-06-24 12:44 on bug 59078. Should this be opened as another bug that depends on 59078?

> why is it that you can only clear the history from the preferences panel and not directly in the History window??? I suggest "C-c" for that, when the location entry widget is active, so that it acts like "xconsole", clearing history the way "xconsole" clears. Incremental search by regexp would be nice to have there also.

The bug in the history list is current a 0.9.2 RTM stopper and a regression also

all these other problems being described here are DIFFERENT BUGS. come on people, read the description - "URL bar bcomes inactive sometimes" - if it's reloading the current url, it's not inactive is it? if it opens two windows, that's not a url bar problem is it? The only other SLIGHTLY mentioned bug is the bug where clicking on a link outside of mozilla does break the urlbar in one of the windows it opens... however there is a DIFFERENT bug on that. please stop adding comments about that here and don't morph bugs.

After installing 0.92 to my 0.91 directory under win98 SE, the URL Box has become completly useless. The only way for me to open an URL is to use Bookmarks, the LocationBar History, History or "Open Web Location" (aka Ctrl+Shift+L). Although the URL of an opened page is displayed correctly in an active URL Box, as soon as you start to add/delete characters in that Box it goes inactive. Even uninstalling mozilla and reinstalling 0.91 couldnt solve this prob (related to regestry entries || my profile?).

VERIFIED Fixed