Closed Bug 245433 Opened 17 years ago Closed 17 years ago
right-click-"Search Web for", default homepage and throbber urls missing
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
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)
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.
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 → ---
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.
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 on attachment 150157 [details] [diff] [review] patch Ben, please see detailed explanation in comments 15-19.
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 ago → 17 years ago
Resolution: --- → FIXED
Comment on attachment 150157 [details] [diff] [review] patch patch already checked in -> removing review request
*** 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.