Closed Bug 83489 Opened 20 years ago Closed 20 years ago

URL bar becomes inactive sometimes


(SeaMonkey :: Location Bar, defect)

Windows NT
Not set


(Not tracked)



(Reporter: harishd, Assigned: alecf)



(Keywords: regression, smoketest, top100, Whiteboard: critical for 0.9.2, ready to checkin)


(2 files)

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 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
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
Keywords: nsbeta1
Whiteboard: fix in hand, need r=, sr=, a=
Target Milestone: --- → mozilla0.9.2
Keywords: nsBranch
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 

*** 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.
Depends on: 87243
Workaround: delete session history
Bug clears itself 
alecf, What about dougt's comments?  Are they valid?  Otherwise I'm ready to
approve this.
Whiteboard: fix in hand, need r=, sr=, a= → fix in hand, need r=, sr=, a= critical for 0.9.2
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 "" 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. ***
Attached patch new fixSplinter Review
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. ***
Keywords: top100
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.
Keywords: mostfreq
Whiteboard: fix in hand, need r=, sr=, a= critical for 0.9.2 → fix in hand, need a= critical for 0.9.2
a=chofmann branch and trunk
Whiteboard: fix in hand, need a= critical for 0.9.2 → critical for 0.9.2, ready to checkin
*** Bug 87672 has been marked as a duplicate of this bug. ***
alright, this damn thing is finally checked in!
Closed: 20 years ago
Resolution: --- → FIXED
*** 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.
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

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?).

Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.