Revision as of 15:30, 8 January 2013

Awesomebar Search Provider Reset

Feature	Status	Lead engineer	QA Lead
Awesomebar Search Provider Reset	In Planning	Gavin Sharp	Manuela Muntean

Users falling victim to "search hijacking" (keyword.URL being taken over by an unwanted search engine) is a common problem.

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.

bug 718088 - offer to re-set keyword.URL if it has a non-default value - RESOLVED FIXED

Test that the notification which prompts the user is displayed when

manually changing keyword.URL pref from "about:config" and then actually performing a keyword search

The test cases for this feature can be viewed [here]. (tests are still under development, will be updated)

bug 732671 - Prevent third party apps to change default search engine - RESOLVED DUPLICATE
bug 784189 - Offer to re-set keyword.URL if it has a non-default value until a better solution can be found - RESOLVED DUPLICATE
bug 736878 - keyword.URL reset prompt doesn't properly re-set prefs if default engine is modified - RESOLVED FIXED
bug 744957 - Enhancements to help mitigate search hijacking - RESOLVED INCOMPLETE

@@ Line 31: / Line 31: @@
 == Use Cases to Test ==
+Test that the notification which prompts the user is displayed when
+*manually changing keyword.URL pref from "about:config" and then actually performing a keyword search