Closed Bug 90337 Opened 23 years ago Closed 22 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 → 22 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: