245433 - right-click-"Search Web for", default homepage and throbber urls missing

Status: RESOLVED FIXED

(Firefox :: General, defect)

Description

[Tim Meader]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040602 Firefox/0.8.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040602 Firefox/0.8.0+

If you highlight text in the browser window, right click, then choose "Search
Web for", Firefox never initiates the search.

Reproducible: Always
Steps to Reproduce:
1.Highlight text
2.Right click on the highlighted text
3.Choose "Search Web for"

Actual Results:  
Nothing happens.

Expected Results:  
This should initiate a search of your chosen search engine for the highlighted text.

Comment 1

[Ali Ebrahim]

WFM: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040602
Firefox/0.8.0+

Comment 2

[Firebot, IRC Bug Reporting Bot]

WFM also.. 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040602
Firefox/0.8.0+

Comment 3

[Tim Meader]

Just wondering, are they installer builds?

Comment 4

[Ali Ebrahim]

Perhaps this is an issue with installer builds? I was using a zip archive build
when I tested.

Comment 5

[Tim Meader]

I'm thinking it is isolated to installer builds. This was reported earlier in
the daily build topic on Mozillazine forums. The two talking about it there were
both using installer builds. I'll add that to the whiteboard if the other WFM
confirms he was using a zip build.

Thanks.

Comment 6

[Tim Meader]

Just noticed that when this happens in the installer build, the following JS
error shows up in the JS console:

Error: uncaught exception: [Exception... "Component returned failure code:
0x8000ffff (NS_ERROR_UNEXPECTED) [nsIStringBundle.GetStringFromName]"  nsresult:
"0x8000ffff (NS_ERROR_UNEXPECTED)"  location: "JS frame :: XStringBundle ::
getString :: line 16"  data: no]

Hope this helps.

Comment 7

[José Jeria]

Confirming with same build: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.7) Gecko/20040602 Firefox/0.8.0+

Comment 8

[Ross Kendall]

Confirming behaviour with installer build:

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040601
Firefox/0.8.0+

Comment 9

[Ross Kendall]

Confirming with another installer build (anybody thought about using a different
UserAgent string for installer to zip?):

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040602
Firefox/0.8.0+

(a clean install)

This error in JS console:

Error: uncaught exception: [Exception... "Component returned failure code:
0x8000ffff (NS_ERROR_UNEXPECTED) [nsIStringBundle.GetStringFromName]"  nsresult:
"0x8000ffff (NS_ERROR_UNEXPECTED)"  location: "JS frame :: XStringBundle ::
getString :: line 16"  data: no]

Comment 10

[Hussam Al-Tayeb]

I really need this feature, so I suggest it is changed to blocking 0.9.

Comment 11

[Ben Goodger (use ben at mozilla dot org for email)]

Attachment: patch

make sure browser-region content package is registered.

Comment 12

[Ben Goodger (use ben at mozilla dot org for email)]

I'm going to guess that this is fixed now, branch and trunk. 

Comment 13

[Steffen Wilberg]

The tree is burning:
error: file
'/cygdrive/g/mozilla/mozilla/browser/base/content/contents-region.rdf' doesn't
exist at /cygdrive/g/mozilla/mozilla/config/make-jars.pl line 410, <STDIN> line 3.
-> Reopening.

Comment 14

[Steffen Wilberg]

Attachment: bustage fix

browser/base/content/contents-region.rdf needs to be added to allmakefiles.sh
in order to be created from contents-region.rdf.in.
You might need to run configure after applying the patch.

Comment 15

[Steffen Wilberg]

Something's wrong with the new contents-region.rdf, it's created from
contents-region.rdf.in and included in browser.jar, but contents-region is not
registered anymore:
chrome://browser-region/locale/region.properties results in a page load error.

In a new profile, this results in a blank start page.

Comment 16

[Hussam Al-Tayeb]

I still can't use "Search Web for" in this build:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040606
Firefox/0.8.0+
I still se this bug.

Comment 17

[Steffen Wilberg]

Thanks again Mike for checking in the bustage fix.

But this bug is still not fixed because browser-region is not registered
anymore! Before Ben's checkin contents.rdf in browser-region said:
chrome:localeVersion="0.9.9"

Now we've got "@MOZILLA_REGION_VERSION@" in contents.rdf.in, which is replaced
by "1.7" when built from the branch. But we've got "0.9.9" everywhere else in
browser:
http://lxr.mozilla.org/mozilla/search?string=chrome%3AlocaleVersion%3D

"1.7" in locale/contents-region.rdf doesn't match with "0.9.9" in
content/contents-region.rdf. So browser-region isn't registered.
The result is no default homepage and no right-click-"search web for" url.

Comment 18

[Steffen Wilberg]

The fix is get those version numbers in sync. The simple option is to hardcode
chrome:localeVersion="0.9.9" instead of "@MOZILLA_REGION_VERSION@" in
browser/base/content/contents-region.rdf.in.

But then we don't need to have a .rdf.in file anymore. So we could go back to a
contents-region.rdf file.

Additional info:
Outside browser and toolkit, the .rdf.in files were replaced by a
preprocessor-based approach with "#expand", as you can see with the link in
comment 17. But we don't need to bother about that since skinversion and
localeversion is about to become obsolete anyway, see bug 217410 comment 67:

bsmedberg: We are going to be removing skinversion and localeversion checks
completely.
Steffen: Then we can remove skinVersion and localeVersion from the contents.rdf
files in browser and toolkit as well?
bsmedberg: I haven't actually disabled skinVersion and localeVersion yet... when
I do, then we can clean up the RDF.

But this hasn't happened yet.

Comment 19

[Steffen Wilberg]

Attachment: patch

It's simply enough check in the .rdf file and remove the .rdf.in file.
This patch fixes all problems mentioned before, i.e. register browser-region
and therefore provide default homepage and "search web for" urls.
It works in zip and installer builds.

Comment 20

[Steffen Wilberg]

Comment on attachment 150157 [details] [diff] [review]
patch

Ben, please see detailed explanation in comments 15-19.

Comment 21

[Steffen Wilberg]

Adjusting summary and platform to prevent dupes. Taking.

Comment 22

[Ben Goodger (use ben at mozilla dot org for email)]

I checked in basically this patch (which amounts to a back-out) on the branch
and trunk. fixed. 

Comment 23

[Steffen Wilberg]

Comment on attachment 150157 [details] [diff] [review]
patch

patch already checked in -> removing review request

Comment 24

[Steffen Wilberg]

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

Comment 25

[Steffen Wilberg]

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

Comment 26

[Logan Ingalls]

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

Comment 27

[Clint Hamilton]

So what the heck is the fix for this bug anyway? I can't figure that out from 
this thread.  I made an "allmakefiles.sh" file and pasted 150157 from comment 
#19 in it, but no one says where to place it!  I see in the 
file "mozilla/allmakefiles.sh" so I tried that path, and it doesn't work.
Thank you.
-Clint

Comment 28

[Steffen Wilberg]

What are you talking about? This bug occured around June 2, and is fixed since
June 6 (before Firefox 0.9 was released).

Comment 29

[Clint Hamilton]

(In reply to comment #28)
> What are you talking about? This bug occured around June 2, and is fixed since
> June 6 (before Firefox 0.9 was released).

No it's not...it's not on my .9.3 .  If you know the fix, then when you please 
post it?
Thanks.
-Clint

Comment 30

[Steffen Wilberg]

I don't know what problem you're experiencing, but it's not this bug unless
you're using a build which was created between July 02 and July 06.

Please try at least Firefox PR:
http://www.mozilla.org/products/firefox/
Or maybe a nightly from here:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-0.9/
Please open a new bug if necessary.

The patches in this bug, or in other bugs, are (usually) of no use to you unless
you compile Firefox yourself. Just download a newer build.

For what it's worth, here are the branch checkins related to this bug:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=AviaryBranchTinderbox&branch=AVIARY_1_0_20040515_BRANCH&branchtype=match&dir=&file=contents-region.rdf*%7Cbrowser.jst%7Callmakefiles.sh%7Cjar.mn&filetype=regexp&who=ben%25bengoodger.com%7Cmconnor%25myrealbox.com&whotype=regexp&sortby=Date&hours=2&date=explicit&mindate=2004-06-06+02%3A50&maxdate=2004-06-06+21%3A48&cvsroot=%2Fcvsroot