Closed Bug 90337 Opened 23 years ago Closed 21 years ago

URL bar not responsive to the "Enter/Return" key (xbl bindings not loaded in time).

Categories

(SeaMonkey :: Location Bar, defect, P3)

Product:
SeaMonkey
Component:
Location Bar
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.4beta

People

(Reporter: harishd, Assigned: emaijala+moz)

References

(Blocks 1 open bug)

Details

(Keywords: relnote, testcase, Whiteboard: [driver:asa] [adt2])

Attachments

(8 files, 1 obsolete file)

wallpaper a QI that doesn't succeed as it should
754 bytes, patch
alecf
: superreview+
Details | Diff | Splinter Review
localstore.rdf file that will trigger this bug for you
40.21 KB, application/octet-stream
Details
Broken history.dat file
300 bytes, application/octet-stream
Details
patch
2.03 KB, patch
hewitt
: review+
bugzilla
: superreview+
roc
: approval+
Details | Diff | Splinter Review
history.dat (the file that causes bug#90337)
427 bytes, application/octet-stream
Details
Diff for the paranoid
7.07 KB, text/plain
Details
Fix the .value problem
864 bytes, patch
emaijala+moz
: review+
jag+mozilla
: superreview+
Details | Diff | Splinter Review
Synchronous load of chrome uris
2.93 KB, patch
hyatt
: review+
bzbarsky
: superreview+
Details | Diff | Splinter Review 
Type a url in the url bar and press "Enter".

Actual Result: Nothing happens.

Used Branch build ( debug ) 07/10/01.
Severity: normal → critical
Wfm, Win2k, Build 2001062815
It's 100% reproducible on my linux branch build.
OS: Windows NT → Linux
Also true if you enter a URL and klick on the "GO" button. (Build 2001062508 Linux)
I'm seeing this on my 2001-08-02 linux trunk build, but not in the 0.9.3 branch.
 Was there a fix that just didn't make it onto the trunk?

Seeing this on solaris, too.
spam. Built from CVS, checkout finish: Mon Aug 6 11:00:08 MET DST 2001
I also see this from an Aug-6 CVS build. The Enter key occasionally works but
rarely. The Go button always works. This is on Linux.
WFM now with a brand new CVS build on Linux.
nav triage team:

Anyone have a 100% reproducible test case? I know it's intermittent, but
obviously, once we can reproduce it, we can then squash this bug. ;-)
OS: Linux → All
Keywords: nsbeta1+
Priority: -- → P2
Target Milestone: --- → mozilla1.0.1
nav triage team:

Marking p2, nsbeta1+, and mozilla1.0.1. Until we can get a developer reproducing
this bug with a debug build, we won't be able to get this fixed.
Well, I'm not a Mozilla developer but I can reliably reproduce this problem on a
20010824 CVS build. My previous version, a few days ago, worked fine.

I did some testing and here are some scenerios that I can reproduct reliably.
Each numbered sequence is a new scenerio. Note that in my current build the
auto-completion of URLs is not working. I would guess this is somehow related
but I can't say how.


1. double-click on URL bar (entire existing URL is selected)
2. type new URL (replaces old URL)
3. hit ENTER (no result)
4. double-click on URL bar again (existing URL selected)
5. type anything and then a dot, e.g., "www." (as soon as . is entered mozilla
tries to hit the site "www.")
*NOTES: the double-clicking aspect of this doesn't seem to make a difference


1. enter an URL in the URL bar
2. hit ENTER (no result)
3. quickly delete the entire URL, i.e., hold down the back space key (the cursor
dissapears after deleting the URL)


1. enter an URL in the URL bar
2. hit ENTER (no result)
3. slowly delete the URL up until, but not including, the first dot (mozilla
tries tries to hit the URL up to the first dot, e.g., "www.")


1. enter an URL that you have recently hit (or tried to hit)
2. hit ENTER (no result)
*NOTES: This is somehow related the cache I think. I tested this with
'www.zdnet.com' which I haven't hit in a few days and it would not load. Between
when I last hit the site and now I have completely shutdown and rebuilt Mozilla,
therefore it is not an internal memory issue.


1. enter an URL that you have never hit before
2. hit ENTER (it loads that page correctly)
I'm not certain, but I think the problem appears only when the URL that you type
isn't already present in the list that appears when you click the drop-down
button at the right of the URL bar.  (I apologize for using the incorrect terms
for these things.)

For example, I click the drop-down button, and I see a number of URLs that I've
visited.  One of them is `http://slashdot.org'.  If I then double-click the URL
bar, and type `slashdot.org', and hit Enter, Mozilla dutifully fetches the page.
 If, on the other hand, I type `ebay.com', and hit Enter, Mozilla just sits
there.  `ebay.com' doesn't appear in the drop-down list.

This is on 2001082808 Linux, but I've also seen this on 0.9.3 Linux.  I've never
seen the problem on Windows.
*** Bug 98300 has been marked as a duplicate of this bug. ***
I debugged this a bit, and it seems like there is an item hanging around that is
not a nsIRDFLiteral.
And the last item in my localstore.rdf under
<RDF:Seq about="nc:urlbar-history">
is
<RDF:li resource="rdf:#$2O5.h1"/>
all others look like
<RDF:li>http://www.mozillazine.org/</RDF:li>

I'll attach a patch that wallpapers this by doing the QI in a try catch block.

Hopefully someone can really debug this, I am so not rdf at all.

Axel
Comment on attachment 48879 [details] [diff] [review]
wallpaper a QI that doesn't succeed as it should

sr=alecf
Attachment #48879 - Flags: superreview+
reassign url bar bugs to new owner..
Assignee: alecf → blakeross
Target Milestone: mozilla1.0.1 → ---
I checked in the workaround. I can't reproduce this problem, it may have gone
away.  Going to close this as fixed for now, reopen if it's still happening. 
Thanks Axel for looking into it.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
*** Bug 99790 has been marked as a duplicate of this bug. ***
This bug still exists for me, at www.calottery.com, after the page loads the URL
bar no longer works.
BuildID: 2001101103
OS: Win2k SP2
Hardware: PC → All
*** Bug 106226 has been marked as a duplicate of this bug. ***
WTF? Resolved fixed, followed by two dupes and a confirmation of it still not
working?

This is 100% reproducible (ie it has never worked) on Mac OSX (10.0.4), Mozilla
build 2001101509.

reopening
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
*** Bug 106016 has been marked as a duplicate of this bug. ***
*** Bug 106644 has been marked as a duplicate of this bug. ***
Propose Severity=Major rather than Critical.
*** Bug 106666 has been marked as a duplicate of this bug. ***
*** Bug 105931 has been marked as a duplicate of this bug. ***
reassigning to default owner.
Assignee: blakeross → hewitt
Status: REOPENED → NEW
*** Bug 107450 has been marked as a duplicate of this bug. ***
I've never been able to reproduce this on any platform, so I'm going to have to
future it until somebody can come up with a way to reproduce.
Status: NEW → ASSIGNED
Target Milestone: --- → Future
Attachment #56321 - Attachment mime type: text/plain → application/octet-stream
This problem occurs on my OS X build.  I can enter URLs using 'Open Web
Location', but when typing them directly into the URL bar, neither enter nor
return works.
*** Bug 107498 has been marked as a duplicate of this bug. ***
*** Bug 113148 has been marked as a duplicate of this bug. ***
*** Bug 116576 has been marked as a duplicate of this bug. ***
Bug found in Mozilla 0.9.7 Linux Talkback-enabled as well.
*** Bug 116907 has been marked as a duplicate of this bug. ***
*** Bug 116718 has been marked as a duplicate of this bug. ***
This problem occurs on my MAc OS 8.6 too (Mozilla 0,97).  I can enter URLs using 
'Open Web
Location', but when typing them directly into the URL bar, neither enter nor
return works.

joe, enough people are seeing this that i don't think it should be futured,
especially given that there is a patch.

requesting re-triage.
Target Milestone: Future → ---
Blocks: 115520
Target Milestone: --- → mozilla0.9.8
*** Bug 117778 has been marked as a duplicate of this bug. ***
*** Bug 117961 has been marked as a duplicate of this bug. ***
*** Bug 118108 has been marked as a duplicate of this bug. ***
*** Bug 116550 has been marked as a duplicate of this bug. ***
This bug seems to have gone away with the recent mach-o builds. The only 
version (out of many...) I have seen it on is the Carbon build on Mac OSX, 
which was why I reopened this bug.
I just can't reproduce this, even with the localstore.rdf that claudius posted.
 I hate to be the 50th person to mark this WORKSFORME, but I think it really
DOES work ;) Fingers crossed.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → WORKSFORME
Build 2001122106, MacOSX.  This bug is still here, but... if you move the cursor
left by one character (ie, hit the left arrow key) when hitting enter/return
fails, and then hit enter/return AGAIN, things work as expected.
*** Bug 120059 has been marked as a duplicate of this bug. ***
Please reopen this bug. I am seeing this for the first time in Linux trunk build
2002-01-14-21. The reporter of bug 120059 is seeing this with the very same
build. A build from just a few days ago worked fine.
Additional info. Drop down list does not open (autocomplete list of URLS) when
you type into URL bar. Pressing Enter does nothing. Build 2002011506 - Linux
I see this in relatively recent Linux CVS.  Reopening.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
I believe that bug 120059 is not a duplicate of this bug, bug 120059 *just*
appeared in recent builds, and is consistently reproducable on linux.  This bug
has been around for a while, and does not appear to be consistently
reproducable.  I'm going to reopen 120059 and would suggest that people don't
hijack this bug to mean 120059, since it looks like there's a separate problem
lurking here (which i have not experienced, by the way).
I can't reproduce this, so I am going to need more info.  If you see this
happen, could you please check the Javascript console and paste any relevant
errors you see in there to this bug.
Status: REOPENED → ASSIGNED
Target Milestone: mozilla0.9.8 → mozilla0.9.9
I can reproduce this 100% of the time with the 0.9.7 Linux RPM.  It's the first
time I've seen the bug.

If you want to let me know how to start the js console, I'll do it again and
post the results.

Please mail me directly if you'd like me to do that.

Dave
Here is what JavaScript Console says:

Error: [Exception... "Component returned failure code: 0x804e03f7
[nsIRDFService.GetDataSource]"  nsresult: "0x804e03f7 (<unknown>)"  location:
"JS frame ::
chrome://navigator/content/urlbarBindings.xml#autocomplete-result-popup.updateEngines()
:: updateEngines :: line 3"  data: no]
Source File:
chrome://navigator/content/urlbarBindings.xml#autocomplete-result-popup.updateEngines()
Line: 3

Error: uncaught exception: [Exception... "Component returned failure code:
0x804e03f7 [nsIRDFService.GetDataSource]"  nsresult: "0x804e03f7 (<unknown>)" 
location: "JS frame :: chrome://navigator/content/sessionHistoryUI.js ::
addToUrlbarHistory :: line 168"  data: no]


V. Still happening in nightlies. Also now occurrs for me in Netscape 6.2.1,
where I've never had it happen before.

It's really in the way of being able to use Mozilla and report bugs, et cetera.
Whiteboard: [driver:asa]
odd, are you seeing this in a new profile? If it only recently started happening
in an old build then it's likely a problem in your profile. Can you test with a
new profile? Thanks.
If you open your JS console and see the messages in comment 55 above (the ones 
about nsIRDFService.GetDataSource), then your problem is that your 
localstore.rdf has become malformed (corrupt) -- see bug 120049. 

This would have been corrupted if you ran a build from Monday evening (PST) or 
very early Tuesday morning (PST). You can fix the problem by deleting your 
localstore.rdf (or by repairing the file, if you know how). 

Note: bug 120049 only existed for a short while Monday night. It has nothing to 
do with this (long-running) bug.
OK, I definitely found another source of this problem which seems to match up to
others' comments. I'm seeing this on Carbon OS X, and I was not getting any
Javascript errors. This started happening to me in early January on one of the
nightlies, so I took the following steps today:
1) Downloaded 0.9.7 and 0.9.6 releases. Problem still exists there, but not when
I originally ran them so it's almost certainly a profile issue. Also explains
why others are seeing this in NS 6.2.1 after encountering it.
2) I created a new profile and it does not have this problem.
3) I copied files from my broken profile into the new one until it broke, too.
The problem file is definitely history.dat.
I'm attaching my broken history.dat file. It looks short, but I can't tell if
it's really corrupted.
Try relocating your profile's history.dat and see if the problem goes away.
Attaching broken history.dat as binary file.
This seems to be happening again on Linux Build 2002012308 to me as well :p
I just can say that only one my client have this one on Win 98SE with NN6.2.1.
Creating a fresh profile fixed it only for some entered urls.
My parents' main profile on their iMac at home (OS 9.2.2) exhibits this problem
as well under Netscape 6.1 through 6.2.1 (we have all three -- Mom doesn't trust
6.2+ as much as 6.1 for some reason).  I was able to create a new profile that
does work, but I'd like to be able to salvage their current proferences.
I can reproduce with build 2001090111 (rpm mozilla-0.9.2.1-2) on Linux, but I
think ONLY if I modify an inner part of a currently displayed file:// URL.  For
example, if current URL is 

file:///home/rocs/WITS-dev/tools/Linux/jdk/j2sdk1.4.0-beta3/docs/index.html

and I click on it and replace "beta3" with "rc1", like this 

file:///home/rocs/WITS-dev/tools/Linux/jdk/j2sdk1.4.0-rc1/docs/index.html

and then hit enter, nothing happens.

I tried similar things with http:// URLs and did not observe the bug.  I also
tried just modifying the end of a file:// URL, e.g. 

file:///home/rocs/WITS-dev/tools/Linux/jdk/j2sdk1.4.0-beta3/docs/index.html

to

file:///home/rocs/WITS-dev/tools/Linux/jdk/j2sdk1.4.0-rc1

and did not observe the bug.

I tried erasing my localstore.rdf and history.dat files but that did not correct
the problem.
This is still an issue on Mac OS X.

It seems random, almost.

The bug was NOT there when I created a clean profile. After that I changed some
preferences (nothing related to keyboard), and restarted. Then it DID happen.

Now after a third restart, I CAN press Enter/Return again.

On another profile, this bug always happens.

I wish this were a 0.9.8 blocker.
if nothing else, it seems we should be able to better handle the error. It
should load the URL even if it can't add it to the session history.
Keywords: mozilla0.9.9
this should be release noted as well. a lot of people have this problem and
creating a new profile isn't a good solution. some of us are very fond of our
migrated 4.x profiles, thankyouverymuch ;) ;)
Keywords: relnote
*** Bug 121982 has been marked as a duplicate of this bug. ***
If you open your JS console and see the messages in comment 55 above (the ones
about nsIRDFService.GetDataSource), indicating your problem is that your
localstore.rdf has become malformed (corrupt), the corruption might also have
occurred because of bug 57246.
*** Bug 122066 has been marked as a duplicate of this bug. ***
*** Bug 92531 has been marked as a duplicate of this bug. ***
I don't think this is related to my profile.  I ran into this problem with 0.9.7
and was able to roll back to 0.9.6 to get rid of it.  I wavered back and forth
between the builds, and am able to make the problem come and go easily by
rolling back and moving forward.  Still happens in 0.9.8.

I also don't think this is URL bar specific.  I made a default web page with a
text area into which I enter an URL.  I noticed that when I hit the enter key
within the text area, the default behavior is to accept the text as if it were a
SUBMIT button click and the text area text is added to the URL like an ASP
string:  file:///D:/Data/HTML/homepage/default.html?txtURL=http%3A%2F%2Fwww.cnet.com

Also of note I added onKeyup code to the page and observed that the enter key’s
keyup did not fire an event within the text area and had been captured by a
different control.

I also wondered if this didn't have anything to do with the MultiZilla beta I've
been using, but have no reason to think it is...

script/html sample:
<html><head><title>Site Launcher</title></head>
<script language =" javascript">
function txtAreaKeyUp()
{
	//alert("processed");
}
function btnUpdateClick()
{
	strUrl = document.frmArea.txtURL.value;
	subChangeUrl(strUrl);
}
function subChangeUrl(strUrl)
{
	document.location.href = strUrl;
}
</script>
<body><form name="frmArea"><p>Enter URL:&nbsp; <input type=text style="WIDTH:
294px; HEIGHT: 22px" size=37 
name="txtURL" value="http://www." onkeyup="javascript:txtAreaKeyUp();">&nbsp;
<input type=button value="Open Page" name=btnUpdate
onclick="javascript:btnUpdateClick();"></p>
<p>&nbsp;</p></form></body></html>
This was a very irritating bug for me on MOZ 0.9.7, and unfortuantely
it is still present in MOZ 0.9.8 (Linux RH 7.1).

reproducible every time.....

-Don
don, on linux when you see this problem do you get the same errors in the JS
console? that would help a lot to know.

also, does the problem go away when you delete your localstore.rdf file?
Renaming localstore.rdf in my profile subdir solved the problem. <YAAY!>

Here is the original JS error:


Error: [Exception... "Component returned failure code: 0x804e03f7
[nsIRDFService.GetDataSource]"  nsresult: "0x804e03f7 (<unknown>)"  location:
"JS frame ::
chrome://navigator/content/urlbarBindings.xml#autocomplete-result-popup.updateEngines()
:: updateEngines :: line 3"  data: no]
Source File:
chrome://navigator/content/urlbarBindings.xml#autocomplete-result-popup.updateEngines()
Line: 3

ok, so we now know for sure:

- this is profile-related
- the localstore.rdf is somehow corrupted
- deleting your localstore.rdf fixes it
- it's XP
*** Bug 123639 has been marked as a duplicate of this bug. ***
*** Bug 123547 has been marked as a duplicate of this bug. ***
*** Bug 124129 has been marked as a duplicate of this bug. ***
*** Bug 124177 has been marked as a duplicate of this bug. ***
Sorting out any issues I saw with 0.9.7 before I move to 0.9.8, just in case I
mess something big up :-)

Anyway, Win98 (2k committed hara kiri so I can't test that ATM, sorry), build
2001122106 and this problem in one of my profiles. I've renamed my
localstore.rdf file and it's now working, I can enter URLs directly in the bar.
Of course I'm still instinctively hitting Ctrl-Shift-L :-) but this has fixed it
and it works now.
Bug appears after migrating from 0.9.7-win32 to 0.9.8-win32. Removed:
- history.dat (1 occurrence)
- localstore.rdf (3 occurrences)

Result: bug still appears.
Discovery regarding comment#82:
I only restored \\Documents and Settings\...\default\...\localstore.rdf and the
bug disappeared!! Weird though...
*** Bug 123538 has been marked as a duplicate of this bug. ***
I am able to make this happen if I set the user_pref("general.startup.mail",
true).  If I set it to user_pref("general.startup.mail", false), it seemed to
fix itself.

I saved most of my prefs.js while trying to figure this out if you want them.
nsbeta1+/major per Nav triage team
Severity: critical → major
Keywords: nsbeta1 → nsbeta1+
Attached patch patch (obsolete) — — Splinter Review 
seems when localstore gets messed up, we aren't handling the RDF errors
correctly.  These two safeguards should help.
*** Bug 126833 has been marked as a duplicate of this bug. ***
Attached patch patch — — Splinter Review 
new patch, catch exceptions higher up in the process
Attachment #70464 - Attachment is obsolete: true
*** Bug 127327 has been marked as a duplicate of this bug. ***
*** Bug 118496 has been marked as a duplicate of this bug. ***
Comment on attachment 70998 [details] [diff] [review]
patch

sr=blake
Attachment #70998 - Flags: superreview+
Comment on attachment 70998 [details] [diff] [review]
patch

r=hyatt
Attachment #70998 - Flags: review+
fixed...  I hope!
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
I'm getting this bug with build 2002030808 (the latest) on MacOS X 10.1.3. 
It started happening to me yesterday for no apparent reason, and is now
happening 100% of the 
time. It was happening with an old 0.9.7 build, and downloading this new build
didn't help. I thought maybe something I'd done with my prefs had triggered it,
but when I tried trashing my Mozilla preferences and Mozilla registry, it didn't
help.

Still occurring with 0.9.9, build 2002031005, on MacOS X 10.1.3.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
did you use a new profile on their since this was fixed? Or the same profile
from before the fix?  If so, it appears you are seeing another old-profile
related bug.  If not, dunno why it is happening.  I haven't seen this yet on
3-10-08 w2k, except a sidebar addressbook issue with the enter key.  I know the
'Go' button issue has regressed in 3-7, but I've not had the enter key URL
problem on windows.  The other obvious thing to check here is if you having a
focus issue with the URL bar.
for those still seeing this error, if you open up the Tasks:Tools:Javascript
Console menu, what errors do you get when you hit return? anything?
I'm using the same profile I've been using for a long time, not a new one.

I get some errors in the javascript console when I open a new browser window,
but I don't get any more errors there when I hit return in the URL bar. The
errors I get when I open a window are "redeclaration of const hide" in
walletOverlay.js, line 1, "popup has no properties" in mailNavigatorOverlay.xul,
line 100, and "popup has no properties" in editorApplicationOverlay.js, line 55.
*** Bug 130005 has been marked as a duplicate of this bug. ***
ADT2 per adt triage team, but we need a reproducible case.  Claudius, can you
find one?
Whiteboard: [driver:asa] → [driver:asa][adt2]
Please let me know if there's any further information I could provide that would
help other people reproduce this bug. I could supply my prefs, profile, etc.,
but I just don't know what's relevant, and what's likely to be specific to my OS
(MacOS X).
Keywords: qawanted
Target Milestone: mozilla0.9.9 → mozilla1.0
Bug 131931 (a dupe of this one) sez:
'The problem occured after deleting the history in
"preferences->navigator->history"'
and has an example of a broken history.dat.
*** Bug 131931 has been marked as a duplicate of this bug. ***
Just a confirmation, no test case I'm afraid:

Bug reappeared upon upgrading from 0.9.8 to 0.9.9 on Win98.  Solved as usual by
deleting localstore.rdf.  Was using an old profile.
Blocks: profile-corrupt
I installed Mozilla 0.9.9 (first build ever on this machine- no netscape, either)
last night,  my OS = win2k sp2  

I did not notice the symptom then, but tonight I can't enter a URL and get the
browser to do anything but RELOAD the current page.  If I select a URL from the
drop-down history, or a bookmark, the browser loads the correct page.

I renamed localstore.rdf to localstore.rdf.old, no improvement.  
I have just had this happen in 0.9.9 (build 2002031104) on win ME. It seemed to
happen when I typed in a new address (www.debian.org) while windows was
connecting and pressed enter before the default page (www.google.com) had
loaded. Removing localstore.rdf fixed it.
No longer blocks: 115520
Mike Pinkerton (re: #99):

It still happens to me sometimes on my 2002031104 build on WINNT4-SP6a. The
error message you asked for is:

Error: gURLBar has no properties
Source File: chrome://navigator/content/navigator.js
Line: 914

Error: gURLBar has no properties
Source File: chrome://navigator/content/navigator.js
Line: 1352

I'm using an old profile and have never deleted localstore.rdf

Wim
This has been happening consistently in mine since upgrading to NS 6.2.1 (Mac OS
9.2) and including 6.2.2.  Possibly since in January I set my preferences to
store 30 days' history instead of just today's (which has never worked either).
 I downloaded and installed 2002031106 last night to see if it would fix the
problem.  It didn't.  On deleting/renaming history.dat it appears to have fixed
the problem for now.  Could the corruption of history.dat been related to asking
it to change the number of days back I don't know when in January perhaps? 
Until ten minutes ago it was 100% reproduceable.
The patch with approval has landed. can you please mark it as obsolete or
resolve this bug and file a new one for new problems? thanks.
What build is the fix in?  It's still happening for me in 2002033109.  Removing
localstore.rdf makes it go away temporarily, but it returns soon.
*** Bug 135329 has been marked as a duplicate of this bug. ***
I believe the problem has gone away for me now that I uninstalled and
reinstalled Mozilla (as needed to fix bug 135222, wherein the 20020403 build
failed to work at all).
For me, with build 2002031005 and MacOS X 10.1.3, the problem occcurred 100%.
Deleting localstore.rdf had no effect, but deleting history.dat fixed it. I have
been able to change various History settings without reincurring the problem (so
far).
i would also suggest moving this to adt1. it renders the product unusable for a
large number of users. how can that be adt2?
Keywords: mozilla1.0
*** Bug 130640 has been marked as a duplicate of this bug. ***
*** Bug 135938 has been marked as a duplicate of this bug. ***
OS/2 users appear to be hitting this a lot for some reason.
I found an easy way to make this happen, but I am not sure if it is the same 
problem.

Hide the Navigation toolbar with the menuitem.

Close the browser.

Reopen and Show the Navigation toolbar.

Nothing in the URL bar works anymore.
*** Bug 136425 has been marked as a duplicate of this bug. ***
*** Bug 136546 has been marked as a duplicate of this bug. ***
I also notice in Windows Trunk build 2002041006 that if I type in a link and 
get no response, I can select a bookmark and the URL doesn't update but the 
browser does render the page and updates the URL icon. 

So I can get a URL icon for Bugzilla next to "www.cnn.com" in the URL bar. Neat!
*** Bug 137110 has been marked as a duplicate of this bug. ***
*** Bug 137571 has been marked as a duplicate of this bug. ***
*** Bug 137730 has been marked as a duplicate of this bug. ***
*** Bug 138322 has been marked as a duplicate of this bug. ***
*** Bug 138590 has been marked as a duplicate of this bug. ***
*** Bug 138654 has been marked as a duplicate of this bug. ***
alright, where does OSX keep it's preferences?
I'm getting this on the 1.0rc1 windows build, with Windows 2000 sp2 (5.00.2195),
AMD k6 with 256 Mb. 
I guess as this stems from old profiles.. So for you guys having problems, you
didn't try a new profile as localstore seems to be profile/build related.  I
re-iterate that I've not seen this bug since it was fixed on win2k as i use a
new profile for every new build.  what strike me oddly is that mozilla is also
not an end user product.. this bug seems to manifest itself with old profiles
being used with new builds that were installed on top of the old build.  For
everyone that is having problems with this.. please try installing mozilla/ns to
a new directory.. and create a new profile.  Why?  because my reason is that
many changes occur between builds/milestones.. some do affect the profile code.
 some files do not correctly use the newer version of the files from the
installer when installing on top of the old build.  Now this was recently looked
at and I believe fixed.  I can understand if RC1 still has this bug and you
tried all these related steps.  For a good example.. MS software causes a lot of
problems of the same kind after adding/upgrading/removing/re-installing on top
of old software.  And 99% of the time.. re-installing new/fresh/formating fixes
every problem you have including weirdness stuff like this.  If you try on Mac
file system using a new build directory, and even the same profile then doing
the localstore trick it may fix it.  If you are using the same build directory
and same profile then the localstore trick doesn't seem to fix it.. is that correct?
This would be that new files are not being used over the old ones that exist..
this was fixed to some degree, I dont remember the bug #, but seems to be
installer related. 

I dont know why we should still try to mess with another technical fix.. I can
understand the issues that arrise that theoretically you shouldn't have to use a
new build directory and a new profile, but re-read what I just wrote above and
you will understand.. mozilla is ever changing and such problems are a
side-effect of ongoing development..  I cant even begin to tell you all the
reasons that code changed and why you should use a new profile since 0.9.7 or
0.9.8 came out.  please consider this upon whether this bug is really still in
latest builds.
I see if the JS errors still do occur if they do still have a problem then I
agree they should be fixed.
see my comment in 120. There is a way to make this always happen.

But I agree. When a lot of my Os/2 people see it, it is corrupt history.dat
on win 98 and 98 SE with 2002041711 it doesn't appear! 
OK, I deleted Mozilla, I deleted Netscape, and I did a "find / -name mozilla
-print" and deleted all other Mozilla files.  Then, i rebooted my computer
before launching the build I had just downloaded.
It didn't work.
Any ideas on how to get Mozilla working?
I had this problem with rc 1 but not previous versions. I have always installed
mozilla over previous versions before and not had any problems. 

Uninatalling mozilla, deleting my profile and reinstalling  and creating a new
profile seemed to fix it (windows 2000)
 
*** Bug 139925 has been marked as a duplicate of this bug. ***
*** Bug 139864 has been marked as a duplicate of this bug. ***
Creating a new profile did not seem to resolve the problem for me.  I have not
yet tried deleting and reinstalling Mozilla.  But if the problem is profile
related, why would creation of a new profile not address the problem?

I submitted bug 139925 and included this additional information which may or may
not be related to this bug:

It seems that once I have tried to load a new page by typing a URL in the
location bar, some aspects of the Mozilla user interface become unresponsive. 
For example, the tree controls in the bookmark manager and preferences dialog
will not expand.

Upon further investigation, ever since this problem started affecting my
installation of Mozilla, these user interface components (e.g., bookmark manager
and preferences dialog) are completely unusable due to their tree controls no
longer functioning (even prior to trying to use the URL bar after a restart).

I think it is at least possible that these issues are interconnected.  Another
item which appears related is that the status bar (bottom) seems to get stuck on
the indication "Transferring data from www.yahoo.com..." way after the page has
been completely loaded.
*** Bug 141211 has been marked as a duplicate of this bug. ***
I tried recreating my profile and it didn't work. What does seem to fix this bug
and another related to the preference menu is to remove Mozilla & Netscape 6,
reboot and then reinstall only Mozilla (I reinstalled the latest build
2002050108). I also cleared out the chrome directory before I reinstalled. Be
sure to save your plugins before un/reinstalling. (WinNT 4.0 SP6a)
Just a minor point. When you test the problem with a new profile, make sure to
create a new profile, open Mozilla with that new profile, and then test. Don't
make any changes to the profile before testing. 
Andrew, just to confirm, that is what I did when I created a new profile and tested.

What I ended up doing is what others have suggested: uninstall + delete Mozilla
and then reinstall.  I didn't bother rebooting in between, though, since Mozilla
doesn't muck around in my OS the way other browsers (cough) do.  This did solve
the problem.  True, I had to recreate my default profile, but in the end, the
URL bar bug and tree-controls bug were no longer affecting me, which is a happy
thing.
I found something interesting in investigating this on someones 
machine and thought I would give everyone the info.

On this machine, I noticed that the dropdown was not appearing for 
autocomplete.

I looked in the JS console and saw some JS errors about a popup 
object.

I checked and in this particular instance, the issue was an old 
component.reg. The name of the popupbox changed between some Mozilla 
versions and as a result, the component was no long registered.

This person has installed an old browser over a new one instead of 
deleting the old.

So my suggestion is that you rename component.reg and then run 
mozilla.

Keep the old one around - we can use regexport to compare them and see 
if that was the problem
*** Bug 141752 has been marked as a duplicate of this bug. ***
I had this problem after installing 1.0rc1 build.  Didn't go away with latest
snapshot, so after reading all the bug report comments, I tried the least
destructive option.

I would like to report that deleting history.dat solved the problem.
This bug is appearing for me with Mozilla 1.0RC1 on Windows 2000 SP2.  It didn't
happen with 0.9.9 or any previous version that I recall.  Renaming
localstore.rdf and/or component.reg have no effect.  Renaming history.dat solves
the problem once.  If I exit Mozilla and restart it, I'm back where I was
before--typing in the URL bar is ineffectual.  Creating a new profile doesn't do
any good; the new profile has the same problem as the existing one.

It may or may not be related that this version also doesn't properly save window
settings (size, location, sidebar on/off) or preferences (like theme).  I
wouldn't think it'd be related, but it seems like it's also a profile-related
issue, so there may be a connection.
Windows 2000 SP2
Having this Bug on RC2 after uprading from RC1(german language pack). Pressing
return does not work, using GO-Button does it. The same thing happened when I
upgraded to RC1 from V0.99. Deleting the profile directory solved the problem.
*** Bug 143655 has been marked as a duplicate of this bug. ***
This has been happening in RC1 and RC2 (WinXP). If I start the browser and the
Nav bar isn't visable, and then make it visable, the URL bar is "dead". Opening
a new window will make it work, but only in the new window - the original "dead"
bar will never work. If the Nav bar is visable on startup, there is no problem.
Proposed relnote: If the URL bar does not respond to the Enter/Return key, you
can use the temporary workaround of pasting the URL into File | Open Web
location. Closing Mozilla, then deleting your history.dat and localstore.rdf
usually solves the problem. Otherwise, you may have to reinstall and create a
new profile.
Another dup: RC1.  Note that I just installed RC2 and it's currently running as
another user.  Not sure if that has any impact on this, though it really
shouldn't.  I should note that the last time this user was on, the machine was
shut down from the other user, which doesn't log this user out cleanly.  I'll
try to save the profile for analysis.  This user has never run RC2.

Having problems like this on corrupted profile files is a really serious
problem, since non-developers will likely _never_ find out how to fix it,
relnote or otherwise, and just go back to IE.  Relnote is _NOT_ a solution for
this (though until it's fixed it should be relnoted.

We have been WAY too lax at paying attention to profile-corruption bugs (I've
seen innumerable "oh, just delete your profile" comments.
Severity: major → critical
Keywords: mozilla0.9.9, mozilla0.9.9+
Also suffering this bug under RC2 (build 2002050105) Mac OS X.  Removing
history.dat and restarting mozilla makes the problem go away.  Restoring the
corrupted history.dat makes the problem come back.  Also affects Netscape 6.2.2.
lowering impact to adt3 per Nav triage team.  severity->major (no crash,
dataloss or severe leak)
Severity: critical → major
Priority: P2 → P3
Whiteboard: [driver:asa][adt2] → [driver:asa][adt3]
so, uh, i don't understand how "the browser stops working" is not adt1? The
workaround is geeky and unknown to most users. Even if we relnote it, nobody
reads those.

We can't ship with this problem. You may not lose data, but you lose your
browser. Which is worse?

requesting re-triage.
Whiteboard: [driver:asa][adt3] → [driver:asa]
This is *not* 'browser stops working', not even close.  Provide reprodicible
steps to get into this state and we'll consider raising priority, but we never
hold releases for bugs we cannot reproduce, and we have no compelling reason to
hold any release for this bug.  We don't know how History is getting corrupted,
nor is there any indication that it is happening with high frequency for target
users, so the Nav triage team considers it a lower impact (ADT3) defect. If beta
feedback shows otherwise, then we will consider that too. In the meantime, Joe
could use some help on this, and the best we may be able to do is to recognize
when it has happened, and nuke the history file programatically.
Whiteboard: [driver:asa] → [driver:asa] [ADT3]
Whiteboard: [driver:asa] [ADT3] → [driver:asa] [ADT3 rtm]
Well this is not easily reproducible. I have hit this bug twice in the past 8
months. I nuked the history file and everything worked fine after that. Off
course this should be fixed, but this may not be a blocker.

I agree with comment #157 regarding the fix. Hopefully the fix happens soon.
I think this Bug is a major blocker. Mozilla is not for the freaky users that
now everything about their system. Mozilla should be an alternative to MS IE for
the masses. You can't tell the users "delete your history file" or something
like that. I suggest to fix this bug before releasing any final version of Mozilla.

I hit this bug daily by the way.
Is everyone who sees this problemm able to fix it by deleting history.dat? Are 
you sure deleting history.dat is what does it, or is it just closing and 
opening the browser?

Or is it some file that gets recreated when history.dat is deleted.

It seems to me that if it genuinely is a history.day issue, we should be able 
to look at the file and see what is wrong.
*** Bug 145718 has been marked as a duplicate of this bug. ***
Sebastian, if you think this bug should be fixed, and it bites you every day,
then you need to help others fix it: please attach your history.dat file after
(and ideally, just before, or at least from an earlier point in the same
session) the bug bites.

/be
well... the problem is that there is some private data in my history-file. some
sites allow to login via the urls in the history-file. if i change these data,
the history file won't be the same anymore.

i want this bug to be fixed, because i want mozilla to become a strong browser,
i know how to go round this bug (crtl-shift-l), but the normal user does'nt know
how to do this. or does'nt want to do this.

let's see what the press will say if the mozilla.org-people say "it's final" but
people find out very soon, that some people even can't navigate to some pages.
There's a testcase in comment 120. It works with the 2002052006 branch build.

The workaround to that is opening a new browser window. I think the same
workaround applies to all of the instances of this bug. If so, we should change
the relnote.
Keywords: testcase
*** Bug 147311 has been marked as a duplicate of this bug. ***
I have the same problem. If I type something like www.moonpig.com and press
enter it doesn't go; however, it I put a SPACE after the url, it goes. Strange
I find that hitting my return key twice does what one key stroke should. I'm
using a Powerbook G4/400 on OS X 10.1.4. Does this work for anyone else? Why
would two key stokes work instead of simply one?
*** Bug 148374 has been marked as a duplicate of this bug. ***
Nav triage team: nsbeta1-
Keywords: nsbeta1+ → nsbeta1-
Keywords: mozilla1.0 → mozilla1.0.1
*** Bug 149590 has been marked as a duplicate of this bug. ***
*** Bug 151065 has been marked as a duplicate of this bug. ***
Build ID: 2002053012
OS: Win98SE

Originally didn't work for me, either in Navigation Toolbar URL or File>Open Web
Location.  I got the same results as all others listed above. 'Enter' did not work.
I was originally using the Classic Theme.  After installing SkyPilotM(u) Theme,
'Enter' worked in both Navigation Toolbar URL and File>Open Web Location. I went
back to Classic Theme and now it works there as well.  Hope this helps someone
track down the problem.
*** Bug 132386 has been marked as a duplicate of this bug. ***
Have the same problem Moz 1.1a (2002061104) and 1.0.  Win98 or Win98SE (I 
forget which, sorry).
I've pasted the the error I got from the Console into the bottom of this 
message.  I got a gazillion of these, all identical.  I guess one for each time 
I pressed enter.
Someone suggested putting a space after the URL.  I tried that, and it makes 
everything work fine.  How weird is that?
At another point, I was typing in a form in IE, and I noticed that the letters 
were typing over each other.  I've seen that before in Word Processors, so I 
pressed <insert>, and it fixed that problem, of course.  I took a wild guess, 
and tried the url bar thing again, pressing <insert>.  It started working 
normally for a while, but it stopped, and I haven't been able to reproduce this 
phenomenon, so it may be just that.
This problem started for me when I downloaded 1.0.  Before, I had 0.9 
something.  I think it might have been 0.97, and it worked just fine.  
Upgrading also brought another bug, which I could not find, so I wrote a new 
report.  It's currently labeled Bug 156947.  I thought, since they happened at 
the same time, they might be related.  Just a thought.
I was considering trying the suggestion of deleting my localstore.rdf and/or 
history.dat files, but I was wondering what the repercussions of that would 
be.  Would I lose my user preference settings?  The only thing I really need to 
be able to salvage is my downloaded mail.  As I understand it, that's a 
seperate file, but isn't the information that tells Mozilla where to find my 
saved mail kept in my user preferences?  Also, I didn't change any of those 
settings.  They should be exactly the way the were back when this worked, right?
I was also considering getting the patch, but I don't know how you get it, or 
what you do with it once you do.
Well, that's all I've got so far.  In case you hadn't figured it out, I don't 
know a whole lot about this stuff, but I'd like to help.  This bug, if you'll 
pardon the pun, is really bugging me, and I want to squash it.
*****************************************************
Error: [Exception... "Component returned failure code: 0x80004002 
(NS_NOINTERFACE) [nsISupports.QueryInterface]"  nsresult: "0x80004002 
(NS_NOINTERFACE)"  location: "JS frame :: 
chrome://global/content/bindings/tree.xml#tree.treeBoxObject (getter) :: 
onget :: line 0"  data: no]
Source File: chrome://global/content/bindings/tree.xml#tree.treeBoxObject 
(getter)
Line: 0
*****************************************************
Reverified with Mozilla 1.1alpha on Win2k
Verified on Mac OS 10.1.5 with Mozilla 1.1b.

Using space or tab does not work, but hitting enter twice does load the url.

If I open a new browser window, or quit and restart, the problem remains.

If I delete the history.dat file it goes away.

If I change the number of days in history, it goes away.  I usually keep my
history at 0 days - could this be a factor?
I just upgraded to 1.1b (under macOS 9.2.1) build 2002072203.  Now my url bar is
broken.  I'm not very well-versed in development or such, so I'm not sure if the
following (as copied directly from JS console) is of any relevance:
Error: popup has no properties
Source File: chrome://messenger/content/mailNavigatorOverlay.xul
Line: 110

If I delete the url up to "www." the browser will attempt to load "www." and
fail, displaying standard error mesage.

Reinstall solves nothing.
Hitting return or enter twice does nothing.
Deleting history.dat has fixed the problem after a program restart (not sure if
it will reoccur; I will put the possibly corrupted history.dat back and see if I
can reproduce the bug.).
Replacing the new history.dat with the corrupted one reproduces the bug.

Removed offensive file and the problem s fixed again.  Looks like it's
history.dat.  I have saved the offending file, and have posted it as an attachment.

Here is what appears in my JS console when this bug is fixed:
Error: popup has no properties
Source File: chrome://messenger/content/mailNavigatorOverlay.xul
Line: 110

Error: this.mMissedIconCache has no properties
Source File:
chrome://global/content/bindings/tabbrowser.xml#tabbrowser.addToMissedIconCache()
Line: 2

Error: this.mMissedIconCache has no properties
Source File:
chrome://global/content/bindings/tabbrowser.xml#tabbrowser.addToMissedIconCache()
Line: 2

I'd have to say that this bug is, at the very least, "major," as  Mozilla 1.1b
(being after a point release) is expected to "ship" with functioning widgits. 
Any crippling problems such as this may turn a user off mozilla for a long long
time.

I'd try to use the "broken history.dat" file attached above, but it downloads as
attachment.cgi.  Stuffit 6.5.1 is unable to uncompress the file.

Good luck!
what keywords are needed to make this a stopship for 1.1?
Keywords: nsbeta1- → nsbeta1
Similar Bug in:
Mozilla 1.1b
Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:1.1b) Gecko/20020722

This has been hanging around since 0.9 I think... its SERIOUS!
Again:
Sometimes (cannot reproduce delibrately), the URL bar is empty. Typing and
hitting enter with ANYTHING in the field reloads the PREVIOUS URL. This can only
be corrected by opening a new window.
Please fix!
Alex
Removing target milestone to trigger triage.
Target Milestone: mozilla1.0 → ---
Keywords: mozilla1.1
I have seen unresponsive urlbar a few times in the last month or so. I can't
figure out how to reproduce it, but occasionally I remember some unusual
situation just before that. The browser functions normally otherwise, and I can
open a new window and close the dysfunctional (bad urlbar), and continue using
it normally.
Nav triage team: nsbeta1+/adt2
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [driver:asa] [ADT3 rtm] → [driver:asa] [adt2]
*** Bug 160833 has been marked as a duplicate of this bug. ***
I've reinstalled Mozilla (removing all prefs, etc).  And the problem persists. 
Deleting history.dat is only a short term fix.  The bug appears with such
frequency that the other users of our main machine have gone back to IE, as they
don't want to muck around with files.

This one is really a pain.  It's happening with great frequency (5+ times a day;
light use).

In this scenario:
New browser window doesn't fix.
Localstore.rdf doesn't fix.

OS 9.2.1

Have using the history.dat files posted above created a test case?
Cautious Yippeee!
Downloaded and using
Build: 2002072203
Mozilla 1.1b
Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:1.1b) Gecko/20020722
(I downloaded this build on Aug 10, 2002 - says 1.1fc on download site but the
installer is 1.1b! - it was mentioend somewhere that this was pulled?)

on Mac OS 9.2.2, PB G3/400

Its been 3 days and counting - this bug has failed to show its clever eyes!
I dont get empty URL bars or the "typing nothing happening" - yet!
I hope it stays this way.
AM
I have also installed version 1.1beta (after doing a remove of 1.0 release) and
it also seems to have fixxed this problem for me as it's been over a week now
with out it happening once!
Could not verify this to be working. Neither with 1.1beta not with build
2002081409. The whole GUI seems to be ****, the preferences Dialog does'nt work
proper, I can't use boomarks and so on and it's terribly slow. Is there a native
WinForms-Alternative like Galeon is for GTK and *NIX? K-Meleon seems not to be
developed anymore.
Its back - No show for a week and then today I fired up the browser window - got
an empty URL field - even though the "Home" page loaded correctly. Typing in
anything in the URL field and hitting enter resulted in just a refresh - the new
URL was not loaded. Opening a new browser window did not show the error.

Someone mentioned erasing the History.Dat file - will try and report if the
problem reappears.

Can someone tell me how to know if the History.Dat file is corrupted?

Build: 2002072203
Mozilla 1.1b
Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:1.1b) Gecko/20020722

Thanks
AM
Blocks: majorbugs
More important for me is, that in the past double clicking in the URL bar first
selected the URL and after double clicking again it loaded it. The URL get's
loaded when hitting Enter but double clicking doesn't work anymore, so we have
also some sort of regression now. 

I'm getting this problem - not sure if it started when I started this instance,
but it's doing it now.  I'm running 1.1 release Win32 (WinXP).
->1.0.2/1.2
Marking as Make 1.2a Not Suck

BTW I'm using an existing profile (recently updated from 1.0 to 1.1); moz1.1 was
installed to a brand-new directory.  No JS errors in the console.

As a driver, I do _not_ accept the suggestion that "well, sometimes profiles get
bad somehow if you upgrade too often, just delete it and start from scratch".  I
understand that a bad daily (or even candidate) build might hose a profile - but
that's not the report here, and even if it was we should hopefully ignore the
bad data file.  In my case, I was running 1.1 after installing; it was working,
and then "something" happened and it stopped.

Code that reads data that is known to get trashed somehow on occasion should
have lots of error checking and good fallbacks.  Obviously we don't have that
for history.dat.

Deleting a profile should be a measure of last-resort, even more extreme than
uninstalling and re-installing, since unless you're a developer or technical
user you'll lose all your prefs, mail config, mail directories, bookmarks,
address books, etc, etc.

I'll see what happens when I quit/restart, and if I delete history.dat (I saved
a copy).
Blocks: 1.2a
Keywords: mozilla1.0.1, mozilla1.1 → mozilla1.0.2, mozilla1.2
My 1.1 problem with enter not working (etc - no autocomplete, etc) was corrected
by quitting and restarting.  This doesn't mean that this isn't a big problem,
and we still have other people apparently reporting history.dat corruption.

This bug has been bothering me for awhile, but the url bar works fine now, after
I turned off Location Bar Autocomplete in the preferences.
I can duplicate this with Moz 1.1 running on OSX 10.2 (Jaguar).

Strangely enough, the Return key will not work, but if I "delete" back (left) across the URL, as soon as the URl is "www." Mozilla tries to load "www." - without me ever hitting return or Go.

I can type a URL, and click "Go" or click on the 'zilla throbber - and it will load.

This seems to be fairly serious, as most people I have been trying to get to use Mozilla are annoyed, and have returned to IE.  (And they claim that this is why they don't like open source programs - yeah, WE know better - but perception is still that Mozilla can't get something simple working.)

I noticed this bug often in Mozilla 1.0 r 2, but in Netscape 7 (Moz 1.0.1) I
haven't seen it yet.  I don't know why.  I didn't create a new profile, it just
doesn't seem to surface.
No longer blocks: 1.2a
Further fixes for this will not make 1.0.2.  Please keep after this one for
future releases (1.2/1.0.3/etc); this is the sort of recurring bug that can
cause people to stop using Mozilla/etc and get very annoyed.
I'd like to confirm the effect described comment #194 that removing autocomplete
removed the "no enter" problem. I am running latest 1.1 release on Mac OS X
(10.1.5).

Mozilla ran fine the first session after installation. This particular bug
showed up only after I ended the session and tried starting a new one. Maybe
this is something to look at?
*** Bug 162740 has been marked as a duplicate of this bug. ***
Since 1.0.2 will not cut for a little while yet (TBD), IF there's a fix for it
and it's reviewed, it would be considered.
*** Bug 169702 has been marked as a duplicate of this bug. ***
*** Bug 169702 has been marked as a duplicate of this bug. ***
I entirely agree with Randell Jessup
This needs to be fixed, damn it!
and how the HELL does history.dat screw up the location bar??
this is **** UP
I use MacOS X 10.2, btw

FUBAR maybe I should use Chimera, but it doesn't have the
contextual menu when you hold the mouse button on a link :(

<sigh> do I even HAVE a history.dat?  I told it not to
record history...
here's what to do on MacOS X
and maybe others, or maybe
with some minor modifications:

#! /bin/tcsh
cd ~/Library/Mozilla/Profiles/default/
cd `ls`
rm history.dat

simple, yes?
...and it prolly doesn't need tcsh
>#! /bin/tcsh
>cd ~/Library/Mozilla/Profiles/default/
>cd `ls`
>rm history.dat
>
>simple, yes?

NOT SIMPLE ENOUGH.

We can't expect Grandma to know this, therefore this
solution to a user interface deficiency is inadequate.
Try again.  Please.
> NOT SIMPLE ENOUGH.

> We can't expect Grandma to know this, therefore this
> solution to a user interface deficiency is inadequate.
> Try again.  Please.

OK, you can write this as a cocoa app.
'cause I don't know cocoa :(
all I know is that shell script works for me 
when I install new versions of mozilla

Or, better, perhaps the |4ym3r2 can fix this?
This is damned annoying and I'd give it more 
than one vote if I could figure out how.
*** Bug 171070 has been marked as a duplicate of this bug. ***
“#! /bin/tcsh
cd ~/Library/Mozilla/Profiles/default/
cd `ls`
rm history.dat”

My Chimera (10/09/02) build just started exhibiting this problem... I deleted
history.dat, but that didn’t change anything. Still no response from the URL
bar, and since Chimera doesn’t have a ‘go’ button this is extremely problematic.
comment #209 are you building Chimera yourself?
Or you grabbing the nightly build binary?

I have 2002100804 and Iv yet to see this bug appear in Chimera
I'm using the nightly binary. The problem is occuring in the 10-10 build too.
WFM 2002101004
I would recommend picking threw your Chimera Profile... moving stuff back and forth
n/m, it was a nightly build problem. See
http://bugzilla.mozilla.org/show_bug.cgi?id=173766
As a driver, I'd like to note that "scripts to delete history.dat" are cute
toys, but are not in any way solutions to this bug.  General users will simply
stop using mozilla/netscape/etc after this happens and never come back.

We need to start taking this seriously.  -> critical

Hewitt - you haven't commented here since February - are you still planning on
addressing this bug?
Severity: major → critical
Comment 12 may apply to my experience as well. The problem does not occur on my
G4 (OS 9.1) but does on my wife's iMac (G3, OS 9.1). We are both using Moz 1.2a.
My wife does not like the list of possible addresses popping up while she types
in a URL, so I turned the history off for her.

i have done the same thing as comment #32. however the first URL i noticed it
with, www.troweprice.com won't load at all now. i also noticed that if i use
delete to try to go back over and change the URL, once i get to the . after www,
it then "enters" and responds back, "www..com could not be found. Please check
the name and try again." i am using OS 10.1.5 and using Moz 1.1, build=
Gecko/20020826. i can reproduce this easily. just try to type in URL bar and
nothing happens when i hit return. same with the part about deleting. just
delete back far enough and then it will return. last night i downloaded a java
1.3.1 update from apple, i don't know if that had anything to do with it.
Still a problem in 1.2b (Mac OS 9.1). See comment 215.

*** Bug 147874 has been marked as a duplicate of this bug. ***
Just noting, 59 duplicate bugs have been entered since this bug's beginning. But
this bug isn't anything to worry about... :( In any case, this bug absolutely
doesn't occur if you do not import Netscape profiles. As soon as you import a
Netscape profile, you are set up to have this problem. I don't know how Mozilla
recreates the Netscape files, or simply copies them, but perhaps Mozilla should,
when importing Netscape files, read the information and fully recreate all files.
*** Bug 177867 has been marked as a duplicate of this bug. ***
Keywords: mozilla1.3
*** Bug 171466 has been marked as a duplicate of this bug. ***
*** Bug 168229 has been marked as a duplicate of this bug. ***
This issue was around at times I recall in Mozilla early versions prior to 1.2
(final) There was one build that corrected this issue wish I could recall which
it was so as to compare, but many builds later and I seeing numbers.  Since
upgrading to 1.2 (final), I'll note this the 11/24 build didn't have this issue,
the so called final dated 11/26 started having this issue on my end (and I tried
it on my other computers too and the issue reproduced itself there too) I went
up to try to 1.3a's 11/27 build [on a seperate partition] and it too had this
issue reproduce itself.

The issue seems to surface more while attempting to key and hit return on tabbed
(new) pages where as you'd all guess it doesn't go into the requested page, I
have however gotten around being **** by this issue bu using Mozilla's menu
item of "Open Web Location" this should serve as a temporary move along 'til the
issue is resolved.

FYI: On my main computer I'm using MacOSX 10.1.5 messing around with Mozilla
nighty build 1.3a of 11/27 though I have reproduced the issue on Mozilla
1.2(final) for OS' Mac OS 9.2.2 and X 10.2.2
Be advised that Mozilla's 1.3a nightly build of the morning of 11/28 seems to
have resolved this issue completely.  I tried to reproduce the issue in its
entirity but to no avail.

I downloaded the 1.3a Gecko/20021128 build for Apple OS X and prior to
installing moved my bookmarks.html, cookies.txt and cookperm.txt files (the
cookies files were an option to save, I did because I decline most and accept
few) afterwards, I trashed the Mozilla folder in the prefs folder, the Mozilla
program itself and three files found in Library->Preferences (folder) the
Mozilla Registry, some companion file near it and a Property List file also in
there.  Can't recall the other two files I found in my user preferences folder
but a simple search of your Apple or computer for anything Mozilla would
suffice.  Essentially doing a clean install without trashing my bookmarks file
and also in my case my cookies files too.

I tried reproducing the issue numerous times,
a) by just typing in a non-bookmarked URL on a new page immediately after
Mozilla launched itself.
b) by closing the prior page, opening a new page and retyping a different
nonbookmarked URL
c) by typing in a URL on a tabbed (new) page and on a third (new) tabbed page
In all examples I was able to hit the return key and get the browser to forward
to the requested page.  I tried reproducing the issue time after time again
quiting Mozilla, launching it and it never reproduced itself.

I'll note I did try this only on my X 10.1.5 drive too early in the morning and
too full of turkey to attempt at both OS 9.2.2 and/or X 10.2.2 but most likely
will try it much later after I get some rest, etc, etc.  As for other OS' try it
(the 11/28 build) and holler back, going on the notion that some individual
doesn't tinker with the 11/28 build of 1.3a I'd hope if not figure that any
build post 11/28 will too work, though I'll keep my finger crossed that no one
messes with the core and this issue doesn't resurface ;)  In any case will
someone else confirm this as the issue does seem resolved.

Obtain nightlies at: http://ftp.mozilla.org/pub/mozilla/nightly/latest/
Build I used: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.3a)
Gecko/20021128
Hi think I have this problem too. Especially when I opened new tabs and used
Mozilla after a while. Think I posted this problem in another bug report.^^;
Related to "pressing enter reloads the current page instead on new URL".I am
using Mozilla 1.2 with Win2k.

By the way if there is a patch available how do I apply it? newbie here.^^;
This bug still shows up with the 1.3 pre-alpha Build 2002120408 on Windows 98,
using the testcase in comment 120. Patch exists, but it may need updating.
Flags: blocking1.3a?
Keywords: mozilla1.2, qawanted → patch
Flags: blocking1.3a? → blocking1.3a-
The testcase in comment #120 is also filed as bug 111559.
Looks like gURLBar doesn't work correctly in the test case in comment #120.
gURLBar.value can be get and set, but it doesn't reflect to its
gURLBar.inputField.value (which seems to contain what the user has typed).

Disclaimer: I know nothing about the ui.
*** Bug 183285 has been marked as a duplicate of this bug. ***
If Mozilla is started with Navigation toolbar hidden, gURLBar doesn't even have
inputField attribute, according to Venkman. Showing the toolbar makes this
attribyte appear, but something is screwed. According to Venkman the values
don't match, although from the bindings it looks like gURLBar.value should be
taken from gURLBar.inputField.value:
0001: gURLBar.inputField.value
$[0] = [string] ""
0001: gURLBar.value
$[1] = [string] "file:///c:/temp/empty.html"
This may be a new twist on the URL bar problem...

System configuration:
   Win2k, SP3, latest patches (as of Dec. 9, 2002);
   Cyrix CPU (Celeron-Equiv), 500MHz;
   256MB SDRAM;
   geForce 2-MX400/64MB

Installed 1.2.1 binaries, URL bar still does not respond to "Enter" key.

Tried the "history.dat" deletion mentioned, no joy...

Noticed this as different behavior from buglist: When typing a URL in 
the "File|Open from web" method, system visibly began slowing down to a crawl, 
keystrokes were full seconds behind actually typing. CPU discovered to be at 
100% through Task Manager at this point. Wound up having to shut Mozilla down 
through Task Manager.
After quite a few hours of debugging and working out how things work here, I've
found what causes at least the problem described in comment #120. I'm not sure
if it might cause other similar problems also. Actually, if I was bold enough,
I'd think this might be the root of many similar problems.

So, when some object such as url-bar is created, certain methods are called to
do the xbl bindings. The flow is:
nsElementSH::PostCreate()
  xblService->LoadBindings()
    GetBinding()

Now, if the requested binding is already loaded or gets completely loaded
immediately, no problem. GetBinding() returns it and LoadBindings goes ahead and
calls among others: 
    newBinding->SetBoundElement(aContent);
    newBinding->GenerateAnonymousContent();
    newBinding->InstallEventHandlers();
    newBinding->InstallImplementation();
    newBinding->GetFirstBindingWithConstructor(aBinding);
    newBinding->HasStyleSheets(aResolveStyle);

But if the binding is not loaded yet (which just happens to url-bar if nav-bar
isn't visible) GetBinding() returns NS_ERROR_FAILURE. If this happens,
LoadBindings() bails out and the above things never get called resulting in a
serious malfunction. 

I verified the following by hacking it enough to be able to force everything
load synchronously. I can try to put this into a nice patch, if it sounds
appropriate.

Any thoughts?
I'm working on a solution, but need to consult some higher authorities. 
In case someone wants to try out the sync-loading version, I compiled an
optimized  Win32 build. It's available at http://atp.fi/~ere/moz-sync.zip. It's
just a packed bin directory. Unpack somewhere and fire it up. 
Ere: not to be paranoid or anything, but could you attach the diffs as well :)
Attached file Diff for the paranoid — 
Sure, here it is. Not a clean patch but the current situation on my system.
Flags: blocking1.3b?
*** Bug 187079 has been marked as a duplicate of this bug. ***
I tested applying the patch, and it applied fine. Unfortunately, I meant to 
test a different patch. Since I applied it, I tried testing it, but I couldn't 
reproduce this bug on a recent trunk build, so I don't know if it fixes it :-/
Test case of comment #120 still does it for me. Closing the browser means
shutting Mozilla down completely.
If you use Mozilla with a Netscape 4.x profile, the bug is 100% reproducable on
Mac OS X.  The same thing happens in Netscape 6 if you use a Netscape 4.x profile.

It can be fixed by creating a new profile and using that instead.
Looks like we actually have two problems. First one is the binding problem
(testcase in comment #120, analysis in #232) but the second one is different. I
suspect we have a situation where timers go haywire. I just had the situation
with one system. Some symptoms:

- URL bar stopped responding, no autocomplete
- new mail notification slider stopped moving (halfway going out)
- scrollbars didn't autoscroll when pressing the arrow
- Venkman didn't load completely
- preferences window could not be closed
etc.

These all lead to timers. I'll try to investigate more.
Comment on attachment 109688 [details]
Diff for the paranoid

I don't think this is the right approach, after all the anonymous content still
gets bound, right? But while I mention it the constructor doesn't get called
either (try the test steps while using the toolbar text/icon prefs).
Ok, it will work around this specific issue, but how about fixing the root cause? 
I stumbled on this again half an hour ago as I noticed that the url bar was left
empty when I opened a new tab and loaded something in it. This time everything
else kept working (this seems to be the case with most people) and I was able to
fire up Venkman. I saw that for some reason gURLBar was again disconnected from
the inputField. I don't know why this would happen in the middle of everything
when xbl bindings are loaded etc, but when I did |delete gURLBar.value| in
Venkman, the url bar started working again. Therefore I think we should get
Neil's patch in asap as it fixes the most annoying problem and start thinking
about the complete solution after that.
Attachment #110865 - Flags: review+
Attachment #110865 - Flags: superreview?(jaggernaut)
I have the same problem on Mozilla 1.2.1
Useragent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130

I tried using a new profile, but the problem still persists. It is occasional
(once or twice a day) and seems to happen randomly...
Could you add "band-aid till we figure out what's going on here" to that XXX?
jag: sure (was that supposed to be a conditial sr=?)
Not only does the Enter/Return key not work, but neither does the Go button on
the toolbar. Only the drop down history bar works.
*** Bug 189634 has been marked as a duplicate of this bug. ***
Yes, we should get at least a bandaid in for this. setting blocking1.3b+
Flags: blocking1.3b? → blocking1.3b+
Comment on attachment 110865 [details] [diff] [review]
Fix the .value problem

sr=jag for the bandaid, but don't close this bug till we've got a real fix.

Make the comment more informative than just "XXX".
Attachment #110865 - Flags: superreview?(jaggernaut) → superreview+
Band-aid checked in with jag's suggested comment.
Ok, how about this: normally load the XBL bindings asynchronously, but if
required, block and wait until they're loaded. I suppose this shouldn't be too
hard to do, right?
with bandaid checked in, no longer blocking 1.3beta
Flags: blocking1.3b+ → blocking1.3b-
This has not been a problem in BeOS, im using Mozilla build 2003012211
reassigning
Assignee: hewitt → varga
Status: REOPENED → NEW
*** Bug 190250 has been marked as a duplicate of this bug. ***
the bandaid fixed caused a regression, see bug #190153
No longer blocks: 190153
Blocks: 190433
Bug is still 100% reproducible on 1.2.1 from a fresh install on Mac OS 9.x. And
even though the Go button is selected to be shown in the location bar, it does
not appear at any time.

Deleting localstore.rdf and history.dat does not fix either problem.
1.2.1 is _old_.
Downloaded a 1.3 today (2003020908)  Haven't had this problem in ages... already
had it 3 times.  Thinking it might be back.  Previously 1.2.1 didn't have this
issue for me (the entire time, not once).  So I'm a bit scaired.... has this bug
returned for 1.3b?
I wish I knew this code better, but unfortunately I don't, so I'll give up on
this one. I just hope someone with the knowledge takes this seriously and fixes
it properly :)
Keywords: mozilla1.0.2
Target Milestone: --- → mozilla1.4beta
Flags: blocking1.4a?
This may seem too simple but this how I dealt with the unresponsive gURLBar.

I dropped an onkeypress handler onto the gURLBar element so that it would
pay attention to the Enter and Return keys (both ASCII 13, although Enter
should be 10 on my Mac).

I placed this near the end of Startup() in comm/content/navigator/navigator.js

  gURLBar.onkeypress = function onkeypress(event) {
	if(pressedReturn(event)) BrowserLoadURL();
  }

and also added this function to navigator.js:

function pressedReturn(event) {
	return event.keyCode == event.DOM_VK_RETURN || 
		event.keyCode == event.DOM_VK_ENTER;
}

Works for me!
Richard 23, that's excellent. Could you implement that as a patch and post it as
an attachment?
Keywords: mozilla1.3
Is that a fix for the basic problem, or a hack-around?  Not that a hack-around
should be disdained after we've been such a long time without a fix...
Sounds like a hack to me, and we already have one.
It's only a hack if there is a better way to fix the problem. Thus, we don't
currently know whether it is a hack or not. Even if it is, I don't see a problem
with having more than one hack patch attached. At least we're getting some
traction on this bug. I'm tired of seeing this one go unfixed. 
There is a better way. It is to fix the cause, not the symptom. I've spent many
hours debugging and testing to find out what's happening here. My thoughts,
however, haven't received much attention. 
I compiled a new Mozilla (checkout finish: Mon Mar 10 17:23:58 CET 2003) for
gtk/Drawin and I hit this problem. I'm using many Carbon/OS X builds that do not
have it. Mozilla 1.1 from fink worked, too. 

Enter key does not work even in new profile.
I get no errors when I hit Enter but I get an error when I press the Go button
Error: uncaught exception: [Exception... "Component returned failure code:
0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE) [nsIJSCID.getService]"  nsresult:
"0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE)"  location: "JS frame ::
chrome://navigator/content/sessionHistoryUI.js :: addToUrlbarHistory :: line
173"  data: no]

I can try uninstalling the fink version (althogh it is in a different directory)
and applying the sync patch.
bug #193416 is another side effect of this.  

(dataloss, we lose the mail start page pref.)
Blocks: 193416
After removing the old Mozilla my url bar loads only one url after starting
mozilla, both with old and new profile.
ie. I type bugzilla.mozilla.org and hit enter -> page loads, later I edit the
bug number in the url bar and hit enter -> nothing happens.
Only pressing the Go button produces the JavaScript error, pressing Enter does not.
Typing 'bugzilla' in the url bar does not show the pulldown list with bugzilla
urls which it probably should. When I open the list manually I see all urls, not
only the ones containing bugzilla.
I agree that a workaround might be good, or bad depending on whether everyone
forgets about the underlying issue once the workaround is checked in. Since this
issue has come up a lot in Bugzilla, is it better to do something like check in
the workaround and temporarily and leave the bug open, or to not check anything
in until the underlying issue is fixed? Maybe someone with experience with
trying both methods can comment on whether they think checking in a temporary
fix would be a bad idea.
The problem with workarounds is that they sometimes cause other problems which
then need to be worked around (happened also with the .value fix checked in
earlier). When there are enough workarounds without fixing the underlying issue,
the result is spaghetti code that almost always breaks when someone tries to
implement or fix something else. 
I did a new build(checkout finish: Tue Mar 18 14:07:06 CET 2003) without any
patches and both url bar and go button work again with my old profile.
The only difference I can think of is that I enabled crypto and tried to build
some extensions (irc, venkman, .. - it did not work anyway).
Another difference may be that I did not have old mozilla libraries while I was
building this time.

So for me this is gone again :)
Flags: blocking1.4a? → blocking1.4a-
Blocks: 191896
Summary: URL bar not responsive to the "Enter/Return" key. → URL bar not responsive to the "Enter/Return" key (xbl bindings not loaded in time).
Blocks: 163372
Flags: blocking1.4b?
The fear with synchronous loading was that loading remote xbl could block the
thread and ui for too long. How about only loading chrome uris synchronously? As
far as I know, this shouldn't cause problems with blocking, but would fix for
example bug 191896 and lessen the need for different workarounds. I'll ask
around for opinions..
Comment on attachment 119611 [details] [diff] [review]
Synchronous load of chrome uris

Jag, what do you think? Or who should I ask? I've tested all components and
measured txul and didn't see any regressions. This would fix at least bug
191896 and make the .value hack here unnecessary. 

This might also help with other focus problems and I suspect it might have
something to do with the jinxed tabs.
Attachment #119611 - Flags: review?(jaggernaut)
Comment on attachment 119611 [details] [diff] [review]
Synchronous load of chrome uris

hyatt, what do you think about this solution?
Attachment #119611 - Flags: review?(jaggernaut) → review?(hyatt)
I hope this could make 1.4b.  It's such a silly problem that's going on.  Is
this still a bandaid patch?  Or a perminant solution?
As permanent as permanent usually is..
:( 

Then who is working on tomorrows patch?
I sure hope we learn about the past mistakes and do it right in beginning next
time :)

BTW, on my system the patch yields approximately 4% txul improvement when xul
cache is disabled.
Comment on attachment 119611 [details] [diff] [review]
Synchronous load of chrome uris

Please use 

"Always load chrome"

instead of

"Load chrome always"

in your comments.

r=hyatt
Attachment #119611 - Flags: review?(hyatt) → review+
Attachment #119611 - Flags: superreview?(roc+moz)
Taking, btw.
Assignee: varga → ere
Comment on attachment 119611 [details] [diff] [review]
Synchronous load of chrome uris

It looks OK to me but bz is the man.
Attachment #119611 - Flags: superreview?(roc+moz) → superreview?(bzbarsky)
Comment on attachment 119611 [details] [diff] [review]
Synchronous load of chrome uris

Yeah, sr=me.  hyatt and I were talking about doing this anyway, since XBL
consumers like the profile manager were totally failing to deal with async XBL
loading in any case.... (and they would start to hit async loads after my next
round of changes to loading).

My one fear was that this would regress Ts or Txul; if you tested Txul and this
doesn't hurt, then sounds good; chances are, it won't hurt Ts either.  ;)
Attachment #119611 - Flags: superreview?(bzbarsky) → superreview+
Checked in, fingers crossed :) And now to find out if we can get rid of some hacks..
Status: NEW → RESOLVED
Closed: 23 years ago → 21 years ago
Resolution: --- → FIXED
First results from tinderboxen indicate that Txul and Tp are unaffected but Ts
came down a bit.
er.... One thing to please keep in mind here is that XBL is still very much
broken when async loading is happening -- it does not give the page using XBL
much in the way of notifications as to when the binding is loaded.

We've "fixed" this for chrome://, but if we want XBL to work in general, we
should invest some effort into making it generally usable...

(Comment 232 makes me especially suspicious -- do the methods that didn't get
called the first time around get called once the binding is loaded, at least? 
Perhaps this means XBL consumers should not do stupid shit with bound elements
until onload fires and XBL binding loading should block onload till the bindings
are loaded?  This does not help the case when elements are created via DOM
methods and then accessed immediately, though....)
True. I suggest a new bug, this one is quite full.

I don't remember it too well anymore, but I think those methods are _never_
called if LoadBindings() doesn't do it. 
Could you please file a bug on me and put in whatever relevant information you
have?  That would be great.
Filed bug 202563.
Flags: blocking1.4b? → blocking1.4b-
If this is fixed, shouldn't we remove the relnote? :)
*** Bug 205623 has been marked as a duplicate of this bug. ***
Marking verified
Status: RESOLVED → VERIFIED
*** Bug 211528 has been marked as a duplicate of this bug. ***
*** Bug 213025 has been marked as a duplicate of this bug. ***
So... should we be removing the band-aid from autocomplete.xml?
*** Bug 128266 has been marked as a duplicate of this bug. ***
No longer blocks: majorbugs
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: