No notification when trying to add the same keyword for two search engines

VERIFIED FIXED in Firefox 36



4 years ago
4 years ago


(Reporter: petruta.rasa, Assigned: florian)


35 Branch
Firefox 37
Dependency tree / graph
Bug Flags:
firefox-backlog +
qe-verify +

Firefox Tracking Flags

(firefox35 wontfix, firefox36+ verified, firefox37+ verified)



(1 attachment)

Reproduced using Firefox 35 beta 5, latest Developer Edition 36.0a2 and latest Nightly 37.0a1 2014-12-18 under all platforms with *in-content preferences*.

Steps to reproduce:
1. Open about:preferences#search
2. Double click on the keyword cell associated to a search engine and add it a keyword (eg yh for yahoo)
3. Click outside the textarea or press Enter
4. Select another search engine and add it the same keyword as in step 2

Expected results:
User should be informed that the same keyword has been already used.
When the Preferences are displayed in separate tab, the following message is used: "You have chosen a keyword that is currently in use by "<search engine>". Please select another." and the same keyword cannot be chosen twice.

Actual results:
The textarea remains displayed no matter what fields are clicked after that:
Console error message: NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS: [JavaScript Error: "strings is null" {file: "chrome://browser/content/preferences/in-content/search.js" line: 155}]'[JavaScript Error: "strings is null" {file: "chrome://browser/content/preferences/in-content/search.js" line: 155}]' when calling method: [nsITreeView::setCellText]


4 years ago
Blocks: 718011

Comment 1

4 years ago
I forgot to add <stringbundle id="engineManagerBundle" src="chrome://browser/locale/"/> to the in-content preferences xul file.

Comment 2

4 years ago
Created attachment 8540064 [details] [diff] [review]

In comment 1 I thought the stringbundle had to go in in-content/preferences.xul, but putting it in search.xul actually works too. in-content/advanced.xul does it that way.
Assignee: nobody → florian
Attachment #8540064 - Flags: review?(felipc)

Comment 3

4 years ago
[Tracking Requested - why for this release]: This is a bug of my patch from bug 1106559 that got uplifted to 35 and 36. I don't think we should care about this for 35 as the in-content preferences aren't enabled by default on beta/release, but it would be nice to fix this trivial error on 36.
Points: --- → 1
status-firefox35: --- → wontfix
status-firefox36: --- → affected
status-firefox37: --- → affected
tracking-firefox36: --- → ?
tracking-firefox37: --- → ?
Flags: qe-verify+
Flags: firefox-backlog+


4 years ago
Attachment #8540064 - Flags: review?(felipc) → review+

Comment 5

4 years ago
Comment on attachment 8540064 [details] [diff] [review]

Approval Request Comment
[Feature/regressing bug #]: new search preference UI (bug 1106559)
[User impact if declined]: broken UI when adding 2 identical search keywords in the in-content preferences (currently enabled only on Nightly and Aurora)
[Describe test coverage new/current, TBPL]: only tested locally; trivial fix
[Risks and why]: very low, trivial fix.
[String/UUID change made/needed]: none.
Attachment #8540064 - Flags: approval-mozilla-aurora?
Attachment #8540064 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Iteration: --- → 37.2
status-firefox36: affected → fixed
status-firefox37: affected → fixed
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 37
tracking-firefox37: ? → +
Verified fixed on Windows 7 64bit, Windows 8 32bit, Ubuntu 13.10 32bit and Mac OSX 10.9.5 using latest Nightly 37.0a1 (buildID: 20141230030214) and latest Aurora 36.0a2 (buildID: 20141230004009).
status-firefox36: fixed → verified
status-firefox37: fixed → verified
tracking-firefox36: ? → +
You need to log in before you can comment on or make changes to this bug.