Closed Bug 353025 Opened 19 years ago Closed 19 years ago

Search engine in Search Bar is randomly changed every time search updates are checked

Categories

(Firefox :: Search, defect, P1)

2.0 Branch
defect

Tracking

()

VERIFIED FIXED
Firefox 2

People

(Reporter: fehe, Assigned: Gavin)

References

Details

(Keywords: verified1.8.1)

Attachments

(1 file)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20060916 BonEcho/2.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20060916 BonEcho/2.0 Whenever Bon Echo runs a search engine update check, it "randomly" changes the search engine appearing in the search bar. I was able to confirm this after I suddenly noticed my search engines changing before my eyes, accompanied with a lot of disk activity. When I went to about:config and checked the time for app.update.lastUpdateTime.searc-engine-update-timer, it matched the time of occurrence. Others have also reported being affected by this issue (see: http://forums.mozillazine.org/viewtopic.php?p=2485017#2485017) Reproducible: Always Steps to Reproduce: 1. Configure Bon Echo to "Automatically check for updates to:" Search Engines 2. Install a few additional search engines, for good measure. :-) 3. Modify browser.search.updateinterval so the check occurs sooner (or more frequently), say 1 hour 4. Wait. It might take a few hits to present the issue. Actual Results: Too impatient so didn't try. I have seen this bug many times, and, as indicated above, others experiencing the issue have also mentioned it on the Mozillazine "Firefox Builds" thread. Expected Results: Checking for search engine updates should not modify the user selected search engine.
Version: unspecified → 2.0 Branch
Attached patch patchSplinter Review
This is an indirect regression from bug 348141, where the default for _useNow was changed to true. This means that update-only engines now have _useNow set, which causes nsIBrowserSearchService::observe to select them when they load. We need to explicitly ensure that this doesn't happen for engine-only loads, by setting _useNow to false.
Assignee: nobody → gavin.sharp
Status: UNCONFIRMED → ASSIGNED
Attachment #238909 - Flags: superreview?(mconnor)
Attachment #238909 - Flags: review?(pamg.bugs)
Blocks: 348141
Flags: blocking-firefox2?
OS: Windows XP → All
Priority: -- → P1
Hardware: PC → All
Target Milestone: --- → Firefox 2
(In reply to comment #1) > need to explicitly ensure that this doesn't happen for engine-only loads, by > setting _useNow to false. I meant "update-only loads", of course.
Comment on attachment 238909 [details] [diff] [review] patch very straightforward, r+a=me, please get this in ASAP
Attachment #238909 - Flags: superreview?(mconnor)
Attachment #238909 - Flags: review?(pamg.bugs)
Attachment #238909 - Flags: review+
Attachment #238909 - Flags: approval1.8.1+
mozilla/browser/components/search/nsSearchService.js 1.1.2.70
Keywords: fixed1.8.1
mozilla/browser/components/search/nsSearchService.js 1.86
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
IU: I would greatly appreciate it if you could verify (or ask others to verify on the forum) that builds including the patch I just checked in no longer show the bug.
Gavin, thanks for fixing this so quickly. I'll check the build out over the next couple days then post a confirmation. And as requested, I'll also post, tomorrow morning, asking others to verify.
Flags: blocking-firefox2? → blocking-firefox2+
Haven't seen this occur again, nor has anyone else reported seeing it. Therefore, verifying fixed. Thanks.
Status: RESOLVED → VERIFIED
Thanks for verifying (and filing!), IU.
*** Bug 353143 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: