Last Comment Bug 718088 - offer to re-set keyword.URL if it has a non-default value
: offer to re-set keyword.URL if it has a non-default value
Status: RESOLVED WONTFIX
:
Product: Firefox
Classification: Client Software
Component: General (show other bugs)
: Trunk
: All All
: -- normal with 2 votes (vote)
: Firefox 19
Assigned To: :Gavin Sharp [email: gavin@gavinsharp.com]
:
Mentors:
: 732671 784189 (view as bug list)
Depends on: 736878 744957 838864 839410 839416
Blocks:
  Show dependency treegraph
 
Reported: 2012-01-13 15:17 PST by :Gavin Sharp [email: gavin@gavinsharp.com]
Modified: 2013-06-20 11:39 PDT (History)
42 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
-
disabled
disabled
+
disabled
disabled


Attachments
patch (12.47 KB, patch)
2012-02-22 21:21 PST, :Gavin Sharp [email: gavin@gavinsharp.com]
no flags Details | Diff | Review
screenshot of notification (368.94 KB, image/png)
2012-02-23 13:07 PST, :Gavin Sharp [email: gavin@gavinsharp.com]
limi: ui‑review+
Details
patch (11.82 KB, patch)
2012-03-01 16:08 PST, :Gavin Sharp [email: gavin@gavinsharp.com]
bzbarsky: review+
fryn: review+
Details | Diff | Review
updated patch (12.27 KB, patch)
2012-03-09 16:10 PST, :Gavin Sharp [email: gavin@gavinsharp.com]
no flags Details | Diff | Review
Telemetry data for release users with keyword.url set to something other than the default (30.78 KB, image/jpeg)
2012-08-20 15:08 PDT, Verdi [:verdi]
no flags Details

Description :Gavin Sharp [email: gavin@gavinsharp.com] 2012-01-13 15:17:47 PST
SUMO feedback shows that users falling victim to "search hijacking" (keyword.url being taken over by an unwanted search engine) is a common problem.

Some of these cases are triggered by aggressive malware that wants to steal search referrals, but other cases can be resolved by us simply resetting the pref to its default value once: 
- poorly written add-ons that legitimately change the pref, but programmatically such that removing the add-on doesn't revert the change
- sketchy software installations might do a one-time change of the pref value in the user's profile
- users may have unintentionally change the pref value, or may have been encouraged to modify it by a "tweaks" site, without realizing that this leaves them susceptible to brokenness in the future (google.com/firefox is no longer being maintained, and might go away at some point)

There are two cases we can detect:
- pref is changed, and the hostname is different (e.g. switched from the default of Google to SuperAwesomeWebDealsSearch.com)
- pref is changed, and only parameters are different (e.g. user customized to a specific type of Google search, or referral codes where added)

In either case, we could prompt the user and offer to reset the keyword.URL value to the default after they trigger a search from the location bar (with perhaps a slightly different string for each).
Comment 1 Alex Limi (:limi) — Firefox UX Team 2012-02-03 14:04:29 PST
Yes, I agree that we should prompt the user for this, as it is most likely hijacking or something they are unaware of.

* We should have a list of the values we ship (including Google, Bing, Yandex, Yahoo, etc) and not ask them if it's been changed to one of these. 

* We should ask after startup; if we try to ask when they are doing a search, we're less likely to get their attention, since we'll just be in the way.

* It's OK to be a bit "in your face" about this, since it's a one-time question, and it won't affect most of our audience (which have the default value).

Text suggestion for the dialog box:

  You — or software you installed — has changed the search provider in Firefox to be:

   evilsearch.com

  Is this what you wanted, or should we restore the standard search provider?

  [Restore Google as my search] [Keep the new search provider]

The "Restore" button should be the selected and default choice.

I usually don't like using modal dialog boxes for this, but in this case, I think it's warranted.
Comment 2 Alex Limi (:limi) — Firefox UX Team 2012-02-03 14:05:53 PST
And, if Yandex or something else is our default search for that locale, show that instead of Google, of course.
Comment 3 Thomas Ahlblom 2012-02-03 14:22:51 PST
How do you prevent the malware from storing that the user already has answered the question with "Keep the new search provider"?

Or is the intention to annoy the user each and every startup, 50 times per day if necessarily?
Comment 4 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-02-03 17:45:45 PST
(In reply to Thomas Ahlblom from comment #3)
> How do you prevent the malware from storing that the user already has
> answered the question with "Keep the new search provider"?

We don't. We're not trying to get into a malware arms race, we're just trying to solve this problem for some number of users who got into this state accidentally, and can easily get out of it.
Comment 5 Sheila Mooney 2012-02-13 09:41:32 PST
Gavin, I am working on getting closure on the wording of the text. What do you need from Limi (or UI perspective) to go ahead and add this in per your proposal.
Comment 6 Sheila Mooney 2012-02-22 15:59:50 PST
Gavin, are we still planning on getting this done to check in for 13? I am assigning it to you - let me know if that's the wrong thing to do.
Comment 7 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-02-22 21:21:06 PST
Created attachment 599866 [details] [diff] [review]
patch

I finally took the time to work on this today, sorry for the delay. I think this patch is functionally complete, but I also wanted to do was telemetrize the response buttons, and I also need to write some tests. Will provide more info to help iron out the exact strings and the interaction etc. tomorrow.
Comment 8 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-02-23 13:04:25 PST
So the behavior implemented by the patch is that when a search is triggered using the pref value of keyword.URL, and keyword.url has a user-set value (i.e. was manually changed by the user or by a third party program/addon) we run the following steps:

1) If there is a notification currently being displayed, or if the user has previously said "no thanks", do nothing
2) if the keyword.URL value's "base domain" (e.g. "google.com" for "www.google.com" or "search.google.com") matches the base domain of the default search plugin, do nothing. This means that users who have a custom google.com keyword.URL value won't see this prompt.
3) Show a notification bar that says:
"Firefox is using 'evilsearch.com' for searches from the location bar. Would you like to use Google instead?"
where "evilsearch.com" is the hostname extracted from the custom keyword.URL value, and "Google" is the name of the default engine (which we use for keyword searches by default). The button options are "Yes, use Google" or "No, continue using evilsearch.com".
4) If the user selects "Yes, use Google", we:
   a) reset keyword.URL
   b) if they are currently viewing a page whose base domain matches the base domain of keyword.URL, then we navigate the current tab to the Google search form (essentially google.com)
5) If the user selects "No", we record their decision (to avoid reprompting in the future), and do nothing.

The notification bar persists for three page loads, to avoid redirects from loading keyword.URL causing it to disappear prematurely. The notification bar has no close button.

There is a mechanism in place to easily allow us to force the notification to be re-shown, even if it has been previously dismissed. We might consider doing this if we later decide to re-word the prompt, or something like that.
Comment 9 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-02-23 13:07:18 PST
Created attachment 600146 [details]
screenshot of notification

So, things I'm looking for feedback on from UX:
- The notification/button strings
- behavior of 1), 2) and 4b) from comment 8
Comment 10 Sheila Mooney 2012-02-28 08:44:54 PST
UX guys, can we get some answers to Gavin's questions? Thanks.
Comment 11 [:Cww] 2012-02-29 16:47:52 PST
I think there may need to be some indication that Google is the default and some wording for when the search engine changes.

"Firefox is using "evilsearch.com" for searches from the location bar would you like to restore the default search? [Yes, use Google] [No, use evilsearch.com]"

And if we detect that the search was subsequently changed to newsearch.com:

"Something has changed Firefox to use "newsearch.com" for searches from the location bar. Would you like to restore "evilsearch.com"? [Yes, use evilsearch.com][No, use newsearch.com]
Comment 12 Alex Limi (:limi) — Firefox UX Team 2012-03-01 13:46:37 PST
Comment on attachment 600146 [details]
screenshot of notification

Looks good to me.
Comment 13 Axel Hecht [:Pike] 2012-03-01 14:58:02 PST
I'm a tad concerned about the mismatch between ShortName and the domain, in particular if malicious attackers would try to spoof google or something.

Apart from that, we're in a "oh my f'ing god" situation, and the UI is in a separate notification box, so I'm less concerned about string changes. We should alert the l10n newsgroup, though.
Comment 14 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-03-01 16:08:09 PST
Created attachment 602185 [details] [diff] [review]
patch

bz, can you review the docshell change?
Comment 15 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-03-01 16:14:22 PST
(In reply to Axel Hecht [:Pike] from comment #13)
> I'm a tad concerned about the mismatch between ShortName and the domain, in
> particular if malicious attackers would try to spoof google or something.

You mean by setting the pref to a domain that "looks like" google.com, that they control? That seems unlikely to be much of a problem in practice - Google-squatting probably isn't that commonly used for real search hijacking, and even if someone is using "g0ogle.com", the fact that we're prompting at all should raise enough doubt to have at least a decent chance of users clicking "Yes, use Google". We don't need to be perfect.

> Apart from that, we're in a "oh my f'ing god" situation, and the UI is in a
> separate notification box, so I'm less concerned about string changes. We
> should alert the l10n newsgroup, though.

I'm not sure what you mean by this - I wasn't planning to land this on Aurora/Beta, if that's what you're thinking?
Comment 16 Jesse Ruderman 2012-03-01 16:49:39 PST
> 2) if the keyword.URL value's "base domain" (e.g. "google.com" for 
> "www.google.com" or "search.google.com") matches the base domain of the default 
> search plugin, do nothing. This means that users who have a custom google.com 
> keyword.URL value won't see this prompt.

Sounds reasonable. Google will close their open redirects if they become a problem ;)

> The notification bar persists for three page loads, to avoid redirects from
> loading keyword.URL causing it to disappear prematurely. The notification
> bar has no close button.

The notification bar should go away iff the user has interacted with the page before leaving.  Persisting based on the number of redirects isn't ideal for usability (it persists after leaving a legitimate search page) or for security (attackers can insert additional redirects through data: URLs).

> browser.promptedToResetKeywordURL

Maybe call this browser.browserPromptedToResetKeywordURL to make it extra clear that an add-on or piece of third-party software that tweaks this value is lying. Also, let's add this pref name to the AMO pre-review scanner.
Comment 17 Jesse Ruderman 2012-03-01 16:52:50 PST
I think it's great that the prompt will only be shown to users who actually use the keyword.URL feature.

Of users who have a modified keyword.URL, how many also have a strange engine (or Google with a strange affiliate tag) selected in their search bar?
Comment 18 Boris Zbarsky [:bz] (Out June 25-July 6) 2012-03-02 09:36:13 PST
Comment on attachment 602185 [details] [diff] [review]
patch

r=me on the docshell bits
Comment 19 Axel Hecht [:Pike] 2012-03-02 10:30:12 PST
(In reply to Gavin Sharp (use gavin@gavinsharp.com for email) from comment #15)
> (In reply to Axel Hecht [:Pike] from comment #13)
> 
> > Apart from that, we're in a "oh my f'ing god" situation, and the UI is in a
> > separate notification box, so I'm less concerned about string changes. We
> > should alert the l10n newsgroup, though.
> 
> I'm not sure what you mean by this - I wasn't planning to land this on
> Aurora/Beta, if that's what you're thinking?

Oops, sorry. Sheila alerted me in mail, and I thought that had to be string freeze break, but it was re 13, so obviously not. Maybe I should read before I write :-).
Comment 20 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-03-02 11:21:07 PST
(In reply to Jesse Ruderman from comment #16)
> The notification bar should go away iff the user has interacted with the
> page before leaving.

This is rather complicated to implement (there's no good way to determine "interacted with the page").

> Persisting based on the number of redirects isn't
> ideal for usability (it persists after leaving a legitimate search page)

This isn't a big deal - in theory users may still want to change their mind even after interacting with the "EvilSearch" site.

> for security (attackers can insert additional redirects through data: URLs).

> Also, let's add this pref name to the AMO pre-review scanner.

I'm not too worried about people explicitly trying to get around this prompt - I don't really want to get into an arms race, the main goal here is to provide relief against slightly sleazy/confusing actors, not malware.

(In reply to Jesse Ruderman from comment #17)
> Of users who have a modified keyword.URL, how many also have a strange
> engine (or Google with a strange affiliate tag) selected in their search bar?

We could go further with this prompt and have it reset the default search engine, as well. I'd like to try and evaluate that in a followup (we should get more telemetry for search bar stuff).
Comment 21 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-03-02 12:49:17 PST
(In reply to [:Cww] from comment #11)
> I think there may need to be some indication that Google is the default and
> some wording for when the search engine changes.

This is a good suggestion.

> And if we detect that the search was subsequently changed to newsearch.com:

Distinguishing initial change from subsequent changes is more complicated, and I'm not sure there's much additional benefit (hopefully users aren't suffering from constant changes, but even if they are the generic message seems suitable).
Comment 22 Jesse Ruderman 2012-03-02 12:57:48 PST
(In reply to Gavin Sharp (use gavin@gavinsharp.com for email) from comment #20)
> (In reply to Jesse Ruderman from comment #16)
> > The notification bar should go away iff the user has interacted with the
> > page before leaving.
> 
> This is rather complicated to implement (there's no good way to determine
> "interacted with the page").

Can you piggyback on the popup blocker heuristic?
Comment 23 Sheila Mooney 2012-03-02 13:53:17 PST
Yes, sorry Axel I just wanted to let you know something was coming down the pipe. This is on the trunk and localizers will pick it up like all the other changes. I was just letting you know, well..to be nice :-). Apologies if it created confusion.
Comment 24 Matthias Versen [:Matti] 2012-03-03 06:45:44 PST
*** Bug 732671 has been marked as a duplicate of this bug. ***
Comment 25 khagaroth 2012-03-03 07:49:56 PST
(In reply to Gavin Sharp (use gavin@gavinsharp.com for email) from comment #21)
> Distinguishing initial change from subsequent changes is more complicated,
> and I'm not sure there's much additional benefit (hopefully users aren't
> suffering from constant changes, but even if they are the generic message
> seems suitable).
How about storing the user accepted user engine in the newly introduced browser.promptedToResetKeywordURL option (and possibly rename it to something like browser.userAcceptetKeywordURLChange) and check against that if it exist.
Comment 26 khagaroth 2012-03-03 08:10:26 PST
Another idea, it could also have some hash tacked on to it to make it harder to spoof.
Comment 27 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-03-05 12:15:19 PST
Comment on attachment 602185 [details] [diff] [review]
patch

Frank, can you review the browser/ parts of this?
Comment 28 Frank Yan (:fryn) 2012-03-05 14:51:34 PST
Comment on attachment 602185 [details] [diff] [review]
patch

Review of attachment 602185 [details] [diff] [review]:
-----------------------------------------------------------------

It looks good. :) Just a few small questions/notes:

::: browser/modules/KeywordURLResetPrompter.jsm
@@ +36,5 @@
> +    let defaultURI;
> +    try {
> +      defaultURI = defaultEngine.getSubmission("foo").uri;
> +    } catch (ex) {
> +      // If this somehow fails, our defaults are broken...

Why are we worried about the defaults being broken?

We don't check for this elsewhere, e.g. https://mxr.mozilla.org/mozilla-central/source/browser/components/nsBrowserContentHandler.js#878

@@ +46,5 @@
> +    let keywordBaseDomain;
> +    try {
> +      keywordBaseDomain = Services.eTLD.getBaseDomain(keywordURI);
> +      if (keywordBaseDomain == Services.eTLD.getBaseDomain(defaultURI))
> +        return;

Setting keyword.URL to something like http://www.google.com/search?q=site:evil.com+ slips through this, but that seems like an edge case.

@@ +82,5 @@
> +                                                [keywordBaseDomain]),
> +        accessKey: browserBundle.getString("keywordPrompt.noButton.accessKey"),
> +        popup:     null,
> +        callback: function(aNotificationBar, aButton) {
> +          Services.prefs.setIntPref("browser.promptedToResetKeywordURL", KEYWORD_PROMPT_REV);

If the user selects no, and later keyword.URL gets hijacked again to a different value, the user will not be prompted. Are we okay with that?
Comment 29 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-03-05 18:09:29 PST
(In reply to Frank Yan (:fryn) from comment #28)
> Why are we worried about the defaults being broken?

In theory it's possible for a search engine to mess with the return value of originalDefaultEngine getter by changing the defaultenginename pref (I've seen some toolbars that do this). Ideally we want to retrieve the build's actual original default engine, so we might need to make some adjustments for that.

> Setting keyword.URL to something like http://www.google.com/search
> ?q=site:evil.com+ slips through this, but that seems like an edge case.

Yeah, I suspect that's pretty uncommon. Adding in/switching Google referral parameters may be more likely, but that's less user-hostile, so not something we should worry about now, I think.

> If the user selects no, and later keyword.URL gets hijacked again to a
> different value, the user will not be prompted. Are we okay with that?

Yeah, this is related to khagaroth's suggestion. I'm not sure that we need to address this in this revision.
Comment 30 Frank Yan (:fryn) 2012-03-05 18:17:50 PST
Comment on attachment 602185 [details] [diff] [review]
patch

(In reply to Gavin Sharp (use gavin@gavinsharp.com for email) from comment #29)
> In theory it's possible for a search engine to mess with the return value of
> originalDefaultEngine getter by changing the defaultenginename pref (I've
> seen some toolbars that do this). Ideally we want to retrieve the build's
> actual original default engine, so we might need to make some adjustments
> for that.

It'd be great if originalDefaultEngine were more resilient to being hijacked, but that's for another bug.

Also, third-party code can now mess with the pref browser.promptedToResetKeywordURL, but I suppose we could blacklist them for doing things like that if necessary.

Thanks for the answers. :)
Comment 31 Robert Kaiser (not working on stability any more) 2012-03-06 04:57:43 PST
(In reply to Gavin Sharp (use gavin@gavinsharp.com for email) from comment #29)
> Ideally we want to retrieve the build's
> actual original default engine, so we might need to make some adjustments
> for that.

There should be ways to read the default branch of prefs (i.e. the ones the build has, and not the state after user/profile modifications), right? We should be able to get the original default from there.
Comment 32 Sheila Mooney 2012-03-07 16:29:35 PST
Gavin, how are we doing on this. Anything else we need before checking this in?
Comment 33 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-03-09 13:37:48 PST
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #31)
> There should be ways to read the default branch of prefs (i.e. the ones the
> build has, and not the state after user/profile modifications), right? We
> should be able to get the original default from there.

Yes, I am aware of the existence of the default pref branch :) The current originalDefaultEngine API doesn't use it, and reworking it to use it involves larger changes that I'm not going to tackle in this bug.
Comment 34 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-03-09 16:10:09 PST
Created attachment 604554 [details] [diff] [review]
updated patch

A few minor tweaks:
- "Would you like to use Google instead?" -> "Would you like to restore the default search (Google)?" per Cheng's comment
- tweaked the pref name from browser.promptedToResetKeywordURL to browser.keywordURLPromptDeclined
- worked around the originalDefaultEngine bug by just reading the pref myself
- added a !keywordBaseDomain check to better handle failure cases with getBaseDomain
Comment 35 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-03-09 16:20:02 PST
https://hg.mozilla.org/integration/mozilla-inbound/rev/4cbfa6301465
Comment 36 Marco Bonardo [::mak] 2012-03-10 02:54:04 PST
https://hg.mozilla.org/mozilla-central/rev/4cbfa6301465
Comment 37 Siddhartha Dugar [:sdrocking] 2012-03-22 00:37:55 PDT
The reset button says "Yes, use Google". So it should also load the Google search result page for the users query.
Comment 38 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-03-23 14:30:42 PDT
(In reply to Siddhartha Dugar [:sdrocking] from comment #37)
> The reset button says "Yes, use Google". So it should also load the Google
> search result page for the users query.

As mentioned in comment 8, we do load the engine's "searchform" URL if you click "Yes" and the base domain of the current page matches the base domain of the keyword.URL value. Extracting the users query from the keyword URI post-fixup is more involved, and it wasn't something I wanted to get into as part of the first revision.
Comment 39 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-03-23 14:31:51 PDT
I filed bug bug 738804 to back this patch out while we investigate additional changes to simplify our search prefs.
Comment 40 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-04-03 11:15:12 PDT
No longer tracking this for Firefox 13, since it was backed out in bug 738804.
Comment 41 Loic 2012-08-14 02:57:31 PDT
*** Bug 782559 has been marked as a duplicate of this bug. ***
Comment 42 Verdi [:verdi] 2012-08-20 15:08:22 PDT
Created attachment 653540 [details]
Telemetry data for release users with keyword.url set to something other than the default

It's been five months since this patch was backed out so that investigation could happen. What is the result of that investigation? 

50% of release users have the keyword.url pref set to something other than default which can only be done by editing about:config or by an external application. I think it's safe to assume these are being changed by external applications like software and add-on installs. Historically this is the largest issue reported to support. 

I think we should land this existing patch and then iterate on it unless there was some new insight that was learned in the last five months.
Comment 43 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-08-20 15:16:45 PDT
Hey Michael,

Bug 738818 is tracking the larger goal that we identified when we first looked into this. No real progress has been made there since we haven't dedicated any resources to tackling this problem specifically. Sounds like you want to push for that, and maybe have us revisit a shorter-term fix like the one we originally landed here. I agree with you that we should do something, but this bug isn't the best place to track it - can you file another one, and CC me?
Comment 44 Dave Townsend [:mossop] 2012-11-06 09:18:25 PST
Per the discussion in bug 784189 and elsewhere I've gone ahead and unbitrotted this and landed it.

https://hg.mozilla.org/integration/mozilla-inbound/rev/07ee3508f530
Comment 45 Ryan VanderMeulen [:RyanVM] 2012-11-06 18:23:30 PST
https://hg.mozilla.org/mozilla-central/rev/07ee3508f530
Comment 46 Axel Hecht [:Pike] 2012-11-09 05:14:22 PST
I'm glancing at this patch, and wonder:

If a user rejected to get his default search reset, 'cause they like it, and then get hijacked to a different keyword.URL, should we unset browser.keywordURLPromptDeclined? We wouldn't be able to reset them to what they initially wanted, but still get them off `evilsearch.com`
Comment 47 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-11-09 09:32:26 PST
(In reply to Axel Hecht [:Pike] from comment #46)
> If a user rejected to get his default search reset, 'cause they like it, and
> then get hijacked to a different keyword.URL, should we unset
> browser.keywordURLPromptDeclined? 

That scenario was considered unlikely enough that I didn't bother handling it. We can "bump" the keywordURLPromptDeclined pref at some later point to re-prompt users who had previously dismissed it, though.
Comment 48 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-11-09 16:41:57 PST
*** Bug 784189 has been marked as a duplicate of this bug. ***
Comment 49 Francesco Lodolo [:flod] - OFFLINE Jun 26-Jul 3 2012-11-09 23:18:19 PST
keywordPrompt.yesButton = Yes, use %1$S
keywordPrompt.noButton = No, continue using '%1$S'

Not sure about consistency here (one with quotes, the other one without, used in the same context).
Comment 50 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-11-11 21:31:35 PST
(In reply to Francesco Lodolo [:flod] from comment #49)
> keywordPrompt.yesButton = Yes, use %1$S
> keywordPrompt.noButton = No, continue using '%1$S'
> 
> Not sure about consistency here (one with quotes, the other one without,
> used in the same context).

Since the argument in the yesButton string is the default provider name, I decided quotes were unnecessary (we won't ship a default provider whose name is confusing). The argument in the noButton string is a host name from the user's prefs, so I couldn't really rely on it being something that necessarily made sense.
Comment 51 Cyko_01 2012-11-15 11:25:02 PST
I woud suggest giving the "never ask me again(for this domain)" option regardless if whether they choose yes or no.  2 of the worst, well intentioned, culprits are mcafee and avg with there own safe-search alternatives and if I recall correctly,they both reset the value repeatedly(on startup/windows startup/virus updates or something)
Comment 52 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-11-15 11:31:13 PST
That's a good idea - do you want to file a new bug about that, and CC me? I can file it if you don't want to.
Comment 53 Cyko_01 2012-11-15 11:52:56 PST
(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #52)
> That's a good idea - do you want to file a new bug about that, and CC me? I
> can file it if you don't want to.

Yes, please file it(and cc me)
Comment 54 Paul Silaghi, QA [:pauly] 2012-12-21 06:17:17 PST
Hello everyone,

How can I test this feature?
Is there a blacklist/whitelist with addons related to this ?
I'm not seeing any reset notification by installing for eg. yandex bar (http://bar.yandex.ru) or manually changing the keyword.URL to evilsearch.com.
Comment 55 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-12-21 13:28:37 PST
(In reply to Paul Silaghi [QA] from comment #54)
> How can I test this feature?
> Is there a blacklist/whitelist with addons related to this ?
> I'm not seeing any reset notification by installing for eg. yandex bar
> (http://bar.yandex.ru) or manually changing the keyword.URL to
> evilsearch.com.

There is no blacklist/whitelist. Manually changing keyword.URL and then actually performing a keyword search (e.g. entering "foo bar" in the location bar and pressing enter) should result in the notification appearing.
Comment 56 Paul Silaghi, QA [:pauly] 2012-12-26 14:58:41 PST
(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #55)
> Manually changing keyword.URL and then
> actually performing a keyword search (e.g. entering "foo bar" in the
> location bar and pressing enter) should result in the notification appearing.
This looks good.

But I've noticed something else:
1. Installing http://us.toolbar.yahoo.com/ and check "Set Yahoo! as default home page and default search" installs the toolbar but without setting the homepage and the default search engine. Also no sign of reset notification. This works fine on a nightly before the fix.
2. Installing http://bar.yandex.com/ is setting the homepage and the default search engine, but still no reset notification appears

Are this possible related bugs?
Comment 57 Paul Silaghi, QA [:pauly] 2012-12-27 07:23:03 PST
(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #55)
> Manually changing keyword.URL and then
> actually performing a keyword search (e.g. entering "foo bar" in the
> location bar and pressing enter) should result in the notification appearing.
3. Also no sign of reset notification if keyword.URL is set to an invalid link (e.g. "xxxxx")
Comment 58 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-12-27 09:40:31 PST
(In reply to Paul Silaghi [QA] from comment #56)
> 1. Installing http://us.toolbar.yahoo.com/ and check "Set Yahoo! as default
> home page and default search" installs the toolbar but without setting the
> homepage and the default search engine. Also no sign of reset notification.
> This works fine on a nightly before the fix.

What do you mean by "without setting the default search engine"? This patch should not have affected what happens when you install Yahoo toolbar, so if you're seeing something like that, please file a new bug.

> 2. Installing http://bar.yandex.com/ is setting the homepage and the default
> search engine, but still no reset notification appears

Does the yandex toolbar change keyword.URL? That's the only situation that this patch covers.
Comment 59 Paul Silaghi, QA [:pauly] 2012-12-28 09:00:48 PST
(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #58)
> What do you mean by "without setting the default search engine"? This patch
> should not have affected what happens when you install Yahoo toolbar, so if
> you're seeing something like that, please file a new bug.
bug 825239 filed

> Does the yandex toolbar change keyword.URL? That's the only situation that
> this patch covers.
Indeed keyword.url is not changed, so it's not a bug.
Comment 60 Manuela Muntean [Away] 2013-02-06 01:23:19 PST
After doing exploratory testing around this feature, I've found the next issue which concern me:

1) After manually changing the pref with "http://www.google.com" or "http://www.search.google.com" , the notification appears, when it shouldn't, in my opinion. Is this behavior expected?

2) After manually changing the pref with something like "evil.com" or" www.evil.com ", without "http://" , or with something invalid, the notification doesn't appear. I am not sure, is this behavior expected?
Comment 61 :Gavin Sharp [email: gavin@gavinsharp.com] 2013-02-11 10:06:32 PST
(disabled for Firefox 19 in bug 838864)
Comment 62 :Gavin Sharp [email: gavin@gavinsharp.com] 2013-04-17 15:06:08 PDT
We've decided to abandon this plan in favor of bug 738818. Disabled for Firefox 21 and 22 in bug 838864.

Note You need to log in before you can comment on or make changes to this bug.