User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:40.0) Gecko/20100101 Firefox/40.0 Build ID: 20150526004004 Steps to reproduce: 1 about:preferences#search 2 click on the search table,the border will get highlighted with blue dots 3 click outside anywhere Actual results: the border will still remain highlighted which is not an expected User experience Expected results: The border should have been went to normal state as it was

Mozilla/5.0 (X11; Linux x86_64; rv:41.0) Gecko/20100101 Firefox/41.0 20150529030205 Also, after clicking a search engine in the list, it's not possible to deselect it via Ctrl+Click.

Review commit: https://reviewboard.mozilla.org/r/67142/diff/#index_header See other reviews: https://reviewboard.mozilla.org/r/67142/

Comment on attachment 8774692 [details] Bug 1169704 - In-content preferences - Search tab - "One-click search engines" table remains highlighted after clicking elsewhere on the page, Review request updated; see interdiff: https://reviewboard.mozilla.org/r/67142/diff/1-2/

Comment on attachment 8774692 [details] Bug 1169704 - In-content preferences - Search tab - "One-click search engines" table remains highlighted after clicking elsewhere on the page, @Jared, This patch makes the selected search engine and the search engine tab not highlighted when clicking outside the search engine tab. Please have a look, thanks.

@Jared, Clicking on the "removeEngineButton" does not blur the selection since we should highlight what is being removed.

Comment on attachment 8774692 [details] Bug 1169704 - In-content preferences - Search tab - "One-click search engines" table remains highlighted after clicking elsewhere on the page, https://reviewboard.mozilla.org/r/67142/#review64162 r=me with the following nits fixed. ::: browser/components/preferences/in-content/search.js:111 (Diff revision 2) > handleEvent: function(aEvent) { > switch (aEvent.type) { > case "click": > + if (aEvent.target.id != "engineChildren" && aEvent.target.id != "removeEngineButton") { > + let engineList = document.getElementById("engineList"); > + // We don't want to toogle off selection while editing keyword s/toogle/toggle/ ::: browser/components/preferences/in-content/search.js:114 (Diff revision 2) > + if (aEvent.target.id != "engineChildren" && aEvent.target.id != "removeEngineButton") { > + let engineList = document.getElementById("engineList"); > + // We don't want to toogle off selection while editing keyword > + // so proceed only when the input field is hidden > + if (engineList.inputField.hidden) { > + var selection = engineList.view.selection; s/var/let/

Comment on attachment 8774692 [details] Bug 1169704 - In-content preferences - Search tab - "One-click search engines" table remains highlighted after clicking elsewhere on the page, Review request updated; see interdiff: https://reviewboard.mozilla.org/r/67142/diff/2-3/

Comment on attachment 8774692 [details] Bug 1169704 - In-content preferences - Search tab - "One-click search engines" table remains highlighted after clicking elsewhere on the page, Review request updated; see interdiff: https://reviewboard.mozilla.org/r/67142/diff/3-4/

Try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=531d2f3d7372&selectedJob=24603587

Pushed by mozilla@noorenberghe.ca: https://hg.mozilla.org/integration/fx-team/rev/90b49d2b0133 In-content preferences - Search tab - "One-click search engines" table remains highlighted after clicking elsewhere on the page, r=jaws

@Carsten, This bug's patch is merged. So we could mark it as FIXED, right? Thanks.

hm, there is no rev like 90b49d2b0133 on central - but will check

(In reply to Fischer [:Fischer] from comment #11) > @Carsten, > This bug's patch is merged. So we could mark it as FIXED, right? Thanks. now it got merged :)

I have reproduced this bug with Nightly 41.0a1 (2015-05-29) on Windows 7, 64 Bit! This bug's fix is verified on latest Aurora Build ID 20160803004014 User Agent Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/50.0 [bugday-20160803]

Reproduced this bug in firefox nightly 41.0a1 (2015-05-29) as comment 0 with ubuntu 16.04 (64 bit) Verified this bug as fixed with latest firefox aurora 50.0a2 (Build ID: 20160804004004) Mozilla/5.0 (X11; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0

With the landing of this patch, it's fairly more troublesome to support the addition of new UI elements attached to commands for the selected search engine via an extension; I have a WIP unpublished add-on adding a button below the engines list, next to "Remove". It applies only to the selected engine, and it's disabled if not engine is selected. This change disables it on click before it triggers. I thinks that a friendly alternative would be checking for a class instead of the fixed "removeEngineButton" id, something as: >> if (aEvent.target.id != "engineChildren" && ! aEvent.target.classList.contains("searchEngineAction")) { ...where "searchEngineAction" is some new classname that need be added to #removeEngineButton.

(In reply to Carlos [nohamelin] from comment #17) > With the landing of this patch, it's fairly more troublesome to support the > addition of new UI elements attached to commands for the selected search > engine via an extension; > I have a WIP unpublished add-on adding a button below the engines list, next > to "Remove". It applies only to the selected engine, and it's disabled if > not engine is selected. This change disables it on click before it triggers. > > I thinks that a friendly alternative would be checking for a class instead > of the fixed "removeEngineButton" id, > something as: > > >> if (aEvent.target.id != "engineChildren" && ! aEvent.target.classList.contains("searchEngineAction")) { > > ...where "searchEngineAction" is some new classname that need be added to > #removeEngineButton. You should file a new bug ask :jaws to weight in.

(In reply to Carlos [nohamelin] from comment #17) > With the landing of this patch, it's fairly more troublesome to support the > addition of new UI elements attached to commands for the selected search > engine via an extension; > I have a WIP unpublished add-on adding a button below the engines list, next > to "Remove". It applies only to the selected engine, and it's disabled if > not engine is selected. This change disables it on click before it triggers. > > I thinks that a friendly alternative would be checking for a class instead > of the fixed "removeEngineButton" id, > something as: > > >> if (aEvent.target.id != "engineChildren" && ! aEvent.target.classList.contains("searchEngineAction")) { > > ...where "searchEngineAction" is some new classname that need be added to > #removeEngineButton. I am OK with this recommendation. Did you file a new bug for this change?

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #19) > I am OK with this recommendation. Did you file a new bug for this change? Done.