Closed Bug 453288 Opened 16 years ago Closed 16 years ago

keyword search fails, gives error page trying to load nonsense jar contents

Categories

(Firefox :: Address Bar, defect)

Product:
Firefox
Component:
Address Bar
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: woodbourne, Unassigned)

References

Details

(Keywords: common-issue+, qawanted, regression) 

User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1

Unlike previous FF versions, this will not search in the location box on partial domains. For example, previously I could go to www.bluemassgroup.com by typing only bluemassgroup. FF would head to the right domain. 

Now if I try, I get:
Firefox can't find the file at jar:file:///C:/Program Files/Mozilla Firefox/chrome/en-US.jar!/locale/browser-region/region.propertiesbluemassgroup

Apparently one or more archives did not get installed.

Other functionality, such as recalling previous sites work. When I start typing bluemassgroup, the choices appear under the location bar and I can tab to or click on one to go to the right location. 


Reproducible: Always

Steps to Reproduce:
1. In the location bar, type a partial URL, using just the primary domain name
2. Press Enter
3. Receive jar error 
Actual Results:  
FF halts and displays the jar error.

Expected Results:  
FF to check its files, fill in the http:// plus the right extension and go to the site. It's been doing that for many versions.

I checked for updates and found none. I don't have enough info to locate and manually all the missing file(s).
Type about:config into the address bar. What value does keyword.URL have? Does it say it is default or user set?
How about the other keyword values, and please say whether they are default or user set.
The only other keyword in my about:config list is keyword.enabled. 

That has values of:

keyword.enabled;true
with Status as default and Type as boolean. 


Well down below that is:

oldKeyword;chrome://browser-region/locale/region.properties

It has Status of userset and Type of string.
Have you tested this with all extensions disabled?
How do I do that?
Tools - add-ons then disable them.
I disabled all, but got identical behavior and error.
Oh, and after I disabled them, I closed and restarted FF.
Component: General → Location Bar and Autocomplete
QA Contact: general → location.bar
Do you type "bluemassgroup" or "bluemassgroup." into the address bar?
No period -- that's a grammatical artifact, not unambiguous cyber-ese.

I actually tried numerous domains that worked with earlier versions of FF, all with the primary domain term and no www to lead in or com/org/net or whatever after.
Start at the "Troubleshoot extensions and themes" bullet of http://support.mozilla.com/en-US/kb/Basic+Troubleshooting and see if any of that helps.
I'm going to confirm this based on the duplicate bug and the newsgroup report.

Mike, if you paste the string "chrome://browser-region/locale/region.properties"
(without the quotes) in your URL bar and hit enter, does the resulting file
contain a line that starts with "keyword.URL="?  If so, what does the rest of
that line look like?  I assume it's "http://www.google.com/search?ie=UTF-8&oe=UTF-8&sourceid=navclient&gfns=1&q=" per comment 2?

I assume the problem is 100% reproducible, right?  If you create a testing profile and in that profile set keyword.enabled to true, does this problem appear in that clean profile as well?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.9.0.4?
Keywords: regression
I don't see how we can "block" on this when we don't know what's wrong or even if the effects are widespread. The bug certainly doesn't happen to me nor apparently any of the developers investigating.

The relevant code is
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/docshell/base/nsDefaultURIFixup.cpp&rev=1.53&mark=378,387,388,396#370

Some error prevents loading the localized pref so we fall back to using the pref value itself (assuming the user must've overridden the value), and then the query value itself is appended. That makes a non-existent file name inside the archive, thus the error.

I'm fairly confident you do have a en-US.jar. If not this bug would be the least of your problems.

In neither bug was there an answer to whether the properties file contained keyword.URI=, but since it's showing up in about:config that's probably a safe assumption.
Summary: Missing jar prevents domain searches → keyword search fails, gives error page trying to load nonsense jar file
Some diagnostic tests could help us know where to start looking since it doesn't happen for most people.

1) We know safe-mode doesn't help, but safe-mode doesn't rule out 100% of profile issues. Have you tried creating a new profile, does that help?

2) have you tried installing a fresh copy of Firefox 3 just in case it really is some corrupt jar file? When you try this you should install in a new directory (choose "custom" install) so if it works we can compare to your original files and see what's different.

If you need help with either of the above see the forum links on http://support.mozilla.org or look us up in IRC (see http://irc.mozilla.org )
Summary: keyword search fails, gives error page trying to load nonsense jar file → keyword search fails, gives error page trying to load nonsense jar contents
There's hardly enough info here to confirm the bug let alone make it a blocker. If we can find out that this is a widespread problem, or enough details to diagnose maybe we can think about fixing it, but right now there's not much we can actually do about this bug.
Flags: blocking1.9.0.4? → blocking1.9.0.4-
Keywords: qawanted
keyword.enabled;true
keyword.URL;http://www.google.com/search?ie=UTF-8&oe=UTF-8&sourceid=navclient&gfns=1&q=

Thats what I can get..
That's really odd...  The code in about:config is using the same codepath as docshell to get the keyword URL, but you get different answers?

James, does this happen every single time following the steps in bug 458501?
yes. every time... I did  a fresh install.. It still did it
James, can you try the build https://build.mozilla.org/tryserver-builds/2008-10-13_12:29-bzbarsky@mozilla.com-KeywordFixupPrintfs/bzbarsky@mozilla.com-KeywordFixupPrintfs-firefox-try-win32.zip perhaps?  I added some printfs to this code to see what's going on.

If you can run "firefox > c:\temp\log.txt" from the prompt, reproduce this bug, and then attach the resulting log.txt file to this bug, that would be much appreciated.
i too have been suffering from this problem lately. Don't know if this can help but this has been happening since i transfered my profile (default profile) by copying it to another computer. I simply changed the old file name to the name of the default profile on the new computer.

Any help would be appreciated.
Sly
> Don't know if this can help

What would help as a start is doing what I ask in comment 21.  If you can do that, it would be lovely.
Hi, I understand code (a little) but I don't have a clue what i am meant to do with the link in #21
James, just run it and then reproduce this bug in it...  Then post the output the build produces on the console in this bug.
Everything is fine now!!! :):):):)
I have this problem too, do you mind telling me and anyone else that wants to know, just how you got rid of the problem?
(In reply to comment #21)
> James, can you try the build
> https://build.mozilla.org/tryserver-builds/2008-10-13_12:29-bzbarsky@mozilla.com-KeywordFixupPrintfs/bzbarsky@mozilla.com-KeywordFixupPrintfs-firefox-try-win32.zip

Unfortunately that build's been cleaned up. bzbarsky: any chance you can repost it somewhere more permanent (and post the patch)?
I downloaded the latest build of Firefox from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20081224 Minefield/3.2a1pre (.NET CLR 3.5.30729)

It appears to have fixed the problem, but I haven't tested enough urls yet to be sure.
No and no in that order: that was just a try server build, and I no longer have that patch.

That said, what the change did was just add some printf logging to the relevant code to try to identify the codepath we were following.  I could try recreating that if someone can actually reproduce the bug.
Wogan could (bug 471142), but it seems that upgrading to a newer build fixed it (comment 30). I wonder if some external program is messing with the actual builds somehow...
Without more information (maybe this is now fixed?), this bug is INCOMPLETE.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → INCOMPLETE
Hi 
I have the same problem I have described it in the forum today 2nd FEB 09
I have the same problem and am about to try the solution at (comment 30).
Nope - exact same error :(
OK, this may help: I then disabled all extensions except 
Adblock Plus; Clipmarks; Google Toolbar; Java Quick Starter and the behaviour returned to normal.
Then I re-enabled 'Ask Toolbar for Firefox 2.1.0.5' - which I don't remember 'asking' for anyway!

Bad behaviour returns - so, as far as I'm concerned, the fault lies with Ask / Yahoo.
Agreed !! I disabled 'Ask Toolbar for Firefox 2.1.0.5' that I did not remember asking for . Fault disapeared  everything ok . Re enabled 'Ask Toolbar for Firefox 2.1.0.5' fault returned . Now uninstalled 'Ask Toolbar for Firefox 2.1.0.5' everything OK


Thanks MARK good work
Keywords: common-issue+
I diabled every addon and exension and I still get that error.
Less common than before, I suspect a new version of this extension doesn't have the problem... look into blocklisting?
You need to log in before you can comment on or make changes to this bug.