Created attachment 8559329 [details] screenshot Steps To Reproduce: 1. Open about:preferences#search 2. Double click to display keyword input field in the Search engine list view (e.g. Double click "Bing" row) 3. Type keyword and do not press ENTER key now (e.g. "b" not include quotation) 3. Click "General" pane 4. Click "Search" pane 5. Scroll the Search engine list view 6. Attempt to continue to type keyword (e.g. "ing" following "b") Actual Results: Unable to edit keyword. Expected Results: Should be able to continue edit the keyword
status-firefox35: --- → unaffected
status-firefox36: --- → affected
status-firefox37: --- → affected
status-firefox38: --- → affected
status-firefox-esr31: --- → unaffected
status-firefox-esr38: --- → affected
Version: Trunk → 36 Branch
(In reply to Alice0775 White from comment #0) > Actual Results: > Unable to edit keyword. > > Expected Results: > Should be able to continue edit the keyword I think the expected result is rather that leaving the search pref pane should remove the textfield, as it appears the tree is no longer in editing mode when returning.
This is not a bug specific to in-content preferences, so removing it from the ship-incontent-prefs meta bug.
No longer blocks: 1014201
Sorry, I now see that this is specific to in-content prefs. Adding back the blocker.
OS: Windows 7 → All
Priority: -- → P2
Hardware: x86_64 → All
The easiest way to fix this (and bug 1129587) is to hide the input once the user has changed panes.
Can you pick this up, Gijs? (Asking specifically because this and the dep will give you more bugs towards your Q1 deliverable.)
Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED
Iteration: --- → 39.1 - 9 Mar
Created attachment 8567873 [details] [diff] [review] hide search engine keyword editor on blur,
Attachment #8567873 - Flags: review?(florian)
Comment on attachment 8567873 [details] [diff] [review] hide search engine keyword editor on blur, Works well and also fixes bug 1129587. I wonder if we should look for a more generic solution, but if this is the only editable tree we'll ever have in the in-content prefs, I guess that would be more work than this edge case is worth.
Attachment #8567873 - Flags: review?(florian) → review+
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
status-firefox39: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 39
Verified as fixed using Nightly 39.0a1 under Win 7 64-bit, Mac OSX 10.10 and Ubuntu 12.04 32-bit. I believe it should be uplifted to 38 where inline preferences will be default.
Status: RESOLVED → VERIFIED
status-firefox39: fixed → verified
Comment on attachment 8567873 [details] [diff] [review] hide search engine keyword editor on blur, Approval Request Comment [Feature/regressing bug #]: search engine prefs [User impact if declined]: in some cases, focus state and/or the search tree gets confused if you switch panes in in-content prefs [Describe test coverage new/current, TreeHerder]: no [Risks and why]: pretty low, just making sure we stop editing when the pane disappears [String/UUID change made/needed]: nope
Attachment #8567873 - Flags: approval-mozilla-aurora?
Attachment #8567873 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
status-firefox38: affected → fixed
Verified as fixed using Nightly Firefox 38 beta 1 under Win 7 64-bit, Mac OSX 10.10 and Ubuntu 12.04 32-bit.
status-firefox38: fixed → verified
You need to log in before you can comment on or make changes to this bug.