We may use this to inform the tour people get if we switch default search engines (e.g. if people are already using the existing default, don't show them anything about the change). We can probably use getConfiguration for this, and just add a "selectedSearch" type that returns the selected search engine's identifier (to be consistent with other UITour search-related APIs).
Who should review this?
Being cautious and wrapping the code around a Services.search.init
Comment on attachment 8526143 [details] [diff] [review] getSelectedEngine I think we should only send the identifier, I don't see any valid uses for the name and it could be potentially confusing. The test should also in theory use the async init API. r=me with those.
(In reply to :Gavin Sharp [email: email@example.com] from comment #3) > Comment on attachment 8526143 [details] [diff] [review] > getSelectedEngine > > I think we should only send the identifier, I don't see any valid uses for > the name and it could be potentially confusing. I thought the name would be useful if the tour wants to expose the name of the engine to the user (instead of just using the identifier for some internal comparison)
Removed engine name and updated test
Target Milestone: Firefox 37 → Firefox 36
Verified as fixed using the following environment: FF 34 Build Id:20141125180439 OS: Win 7 x64, Mac Os X 10.9.5, Ubuntu 14.04 x64 Manual verification was possible only on FF 34 the searchbar ui tour is available.
This was already verified on Firefox 34, and I don't think it needs further verification on 35 and 36.
Flags: qe-verify? → qe-verify-
You need to log in before you can comment on or make changes to this bug.