Closed Bug 245433 Opened 17 years ago Closed 17 years ago

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

Categories

(Firefox :: General, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: tmeader, Assigned: steffen.wilberg)

References

Details

(Keywords: regression, Whiteboard: fixed-aviary1.0)

Attachments

(1 file, 2 obsolete files)

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.
WFM: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040602
Firefox/0.8.0+
WFM also.. 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040602
Firefox/0.8.0+
Just wondering, are they installer builds?
Perhaps this is an issue with installer builds? I was using a zip archive build
when I tested.
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.
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.
Confirming with same build: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.7) Gecko/20040602 Firefox/0.8.0+
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
Summary: "Search Web for" on the right click menu of highlighted text doesn't work → "Search Web for" on the right click menu of highlighted text doesn't work (installer only)
Flags: blocking0.9?
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+

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]
I really need this feature, so I suggest it is changed to blocking 0.9.
Attached patch patch (obsolete) — Splinter Review
make sure browser-region content package is registered.
Assignee: firefox → bugs
Status: NEW → ASSIGNED
I'm going to guess that this is fixed now, branch and trunk. 
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Attached patch bustage fix (obsolete) — Splinter Review
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.
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.
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.
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.
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.
Attached patch patchSplinter Review
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.
Attachment #150124 - Attachment is obsolete: true
Attachment #150130 - Attachment is obsolete: true
Comment on attachment 150157 [details] [diff] [review]
patch

Ben, please see detailed explanation in comments 15-19.
Attachment #150157 - Flags: review?(bugs)
Adjusting summary and platform to prevent dupes. Taking.
Assignee: bugs → steffen.wilberg
Status: REOPENED → NEW
OS: Windows XP → All
Hardware: PC → All
Summary: "Search Web for" on the right click menu of highlighted text doesn't work (installer only) → right-click-"Search Web for", default homepage and throbber urls missing
I checked in basically this patch (which amounts to a back-out) on the branch
and trunk. fixed. 
Status: NEW → RESOLVED
Closed: 17 years ago17 years ago
Resolution: --- → FIXED
Flags: blocking0.9?
Whiteboard: fixed-aviary1.0
Comment on attachment 150157 [details] [diff] [review]
patch

patch already checked in -> removing review request
Attachment #150157 - Flags: review?(bugs)
*** Bug 245432 has been marked as a duplicate of this bug. ***
*** Bug 245271 has been marked as a duplicate of this bug. ***
*** Bug 254362 has been marked as a duplicate of this bug. ***
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
What are you talking about? This bug occured around June 2, and is fixed since
June 6 (before Firefox 0.9 was released).
(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

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
You need to log in before you can comment on or make changes to this bug.