Closed
Bug 1374852
Opened 7 years ago
Closed 7 years ago
Visiting preferences should always focus on search field
Categories
(Firefox :: Settings UI, enhancement, P1)
Tracking
()
VERIFIED
FIXED
Firefox 56
Tracking | Status | |
---|---|---|
firefox56 | --- | verified |
People
(Reporter: caspy77, Assigned: rickychien)
References
(Depends on 1 open bug)
Details
(Whiteboard: [photon-preference])
Attachments
(1 file)
(I thought this was a part of the spec, but alas no.) In Chrome, when you open the settings, the search box is already focused. This is excellent polish as I'm able to find what I'm looking for with no mousing. Per my discussion with JAWS, we want to allow keyboard navigation with the arrow keys and spacebar in order to scroll the page so we shouldn't focus it by default. However capturing visible keystrokes and focusing the search box may be a viable option. That's what this bug proposes.
chsiang was told to ni? you to see if this can be included in the photon-preferences work.
Flags: needinfo?(chsiang)
Updated•7 years ago
|
Flags: qe-verify+
Priority: -- → P3
QA Contact: hani.yacoub
Whiteboard: [photon-preference]
(In reply to Caspy7 from comment #1) > chsiang was told to ni? you to see if this can be included in the > photon-preferences work. Caspy7, We list this in our scope as P3. Will have some further discussions with our UX designer tina about the ideal behavior and get back on this.
Flags: needinfo?(chsiang)
Assignee | ||
Comment 3•7 years ago
|
||
According to spec https://mozilla.invisionapp.com/share/ZDAGPK3AF#/screens/218928209, we should always focus on search field when user visits Preferences. Patch will be submitted soon.
Assignee: nobody → rchien
Status: NEW → ASSIGNED
Priority: P3 → P1
Summary: Preferences should allow search without manually selecting the search box → Visiting preferences should always focus on search field
Comment hidden (mozreview-request) |
Comment hidden (mozreview-request) |
Assignee | ||
Comment 6•7 years ago
|
||
Jared, can you help me review this patch? Thanks
Flags: needinfo?(jaws)
Assignee | ||
Updated•7 years ago
|
Flags: needinfo?(jaws)
Comment 7•7 years ago
|
||
mozreview-review |
Comment on attachment 8880254 [details] Bug 1374852 - Visiting preferences should always focus on search field https://reviewboard.mozilla.org/r/151610/#review157242 Okay, this is fine. Initially I wanted something more complex, but I think it may be better to go with something simple first and see if we need to make it more complex later (complexity being allowing space and arrow keys to still scroll the page).
Attachment #8880254 -
Flags: review?(jaws) → review+
Comment hidden (mozreview-request) |
Pushed by rchien@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/0e2417cb980a Visiting preferences should always focus on search field r=jaws
Comment 10•7 years ago
|
||
Backed out for failing browser_openPreferences.js, at least on Windows: https://hg.mozilla.org/integration/autoland/rev/04428785cdf4de11ae5a49dc4a43a1d496d04e4f Push with failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&revision=0e2417cb980a2b8753e3d0aa7535a45047198e89&filter-resultStatus=testfailed&filter-resultStatus=busted&filter-resultStatus=exception&filter-resultStatus=retry&filter-resultStatus=usercancel&filter-resultStatus=runnable Failure log: https://treeherder.mozilla.org/logviewer.html#?job_id=109727004&repo=autoland 23:30:00 INFO - Entering test bound test_openOldDataChoicesTab 23:30:00 INFO - Buffered messages logged at 23:29:59 23:30:00 INFO - TEST-PASS | browser/components/uitour/test/browser_openPreferences.js | Should open to the dataChoicesTab in the old Preferences - 23:30:00 INFO - == Done test, doing shared checks before teardown == 23:30:00 INFO - TEST-PASS | browser/components/uitour/test/browser_openPreferences.js | Element should not be null, when checking visibility - 23:30:00 INFO - TEST-PASS | browser/components/uitour/test/browser_openPreferences.js | Highlight should be closed/hidden after UITour tab is closed - 23:30:00 INFO - TEST-PASS | browser/components/uitour/test/browser_openPreferences.js | Element should not be null, when checking visibility - 23:30:00 INFO - TEST-PASS | browser/components/uitour/test/browser_openPreferences.js | Tooltip should be closed/hidden after UITour tab is closed - 23:30:00 INFO - TEST-PASS | browser/components/uitour/test/browser_openPreferences.js | @noautohide on the menu panel should have been cleaned up - 23:30:00 INFO - TEST-PASS | browser/components/uitour/test/browser_openPreferences.js | The panel shouldn't have @panelopen - 23:30:00 INFO - TEST-PASS | browser/components/uitour/test/browser_openPreferences.js | The panel shouldn't be open - 23:30:00 INFO - TEST-PASS | browser/components/uitour/test/browser_openPreferences.js | Menu button should know that the menu is closed - 23:30:00 INFO - Done shared checks 23:30:00 INFO - Leaving test bound test_openOldDataChoicesTab 23:30:00 INFO - Entering test bound test_openPrivacyReports 23:30:00 INFO - Buffered messages finished 23:30:00 INFO - TEST-UNEXPECTED-FAIL | browser/components/uitour/test/browser_openPreferences.js | uncaught exception - NS_ERROR_UNEXPECTED: Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [nsIPrefBranch.getCharPref] at init@chrome://browser/content/preferences/in-content-new/advanced.js:58:27 23:30:00 INFO - init@chrome://browser/content/preferences/in-content-new/preferences.js:45:7 23:30:00 INFO - initializeCategories@chrome://browser/content/preferences/in-content-new/findInPage.js:64:11 23:30:00 INFO - handleEvent@chrome://browser/content/preferences/in-content-new/findInPage.js:29:7 23:30:00 INFO - init@chrome://browser/content/preferences/in-content-new/findInPage.js:21:7 23:30:00 INFO - init_all@chrome://browser/content/preferences/in-content-new/preferences.js:64:3 23:30:00 INFO - EventListener.handleEvent*@chrome://browser/content/preferences/in-content-new/preferences.js:51:1 23:30:00 INFO - 23:30:00 INFO - Stack trace: 23:30:00 INFO - chrome://mochikit/content/tests/SimpleTest/SimpleTest.js:simpletestOnerror:1652 23:30:00 INFO - chrome://browser/content/preferences/in-content-new/findInPage.js:init:21 23:30:00 INFO - chrome://browser/content/preferences/in-content-new/preferences.js:init_all:64 23:30:00 INFO - GECKO(5652) | Unable to read VR Path Registry from C:\Users\cltbld\AppData\Local\openvr\openvrpaths.vrpath 23:30:00 INFO - GECKO(5652) | JavaScript error: chrome://browser/content/preferences/in-content-new/advanced.js, line 58: NS_ERROR_UNEXPECTED: Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [nsIPrefBranch.getCharPref] 23:30:00 INFO - TEST-PASS | browser/components/uitour/test/browser_openPreferences.js | Should not display the reports subcategory in the location hash. -
Flags: needinfo?(rchien)
Comment hidden (mozreview-request) |
Assignee | ||
Updated•7 years ago
|
Flags: needinfo?(rchien)
Comment hidden (mozreview-request) |
Comment 13•7 years ago
|
||
Pushed by rchien@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/eae501f2729b Visiting preferences should always focus on search field r=jaws
Comment 14•7 years ago
|
||
Backed out for still failing browser_openPreferences.js on OS X and Windows: https://hg.mozilla.org/integration/autoland/rev/90add23aa905184e042cac1cd6887b2278f2b3f9 Push with failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&revision=eae501f2729beac5ce9010309a5a2f4097f5d6ef&filter-resultStatus=retry&filter-resultStatus=usercancel&filter-resultStatus=runnable&filter-resultStatus=testfailed&filter-resultStatus=busted&filter-resultStatus=exception Failure log: https://treeherder.mozilla.org/logviewer.html#?job_id=109807990&repo=autoland 10:31:18 INFO - Entering test bound test_openPrivacyReports 10:31:18 INFO - Buffered messages finished 10:31:18 INFO - TEST-UNEXPECTED-FAIL | browser/components/uitour/test/browser_openPreferences.js | uncaught exception - NS_ERROR_UNEXPECTED: Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [nsIPrefBranch.getCharPref] at init@chrome://browser/content/preferences/in-content-new/advanced.js:58:27 10:31:18 INFO - init@chrome://browser/content/preferences/in-content-new/preferences.js:45:7 10:31:18 INFO - initializeCategories@chrome://browser/content/preferences/in-content-new/findInPage.js:66:11 10:31:18 INFO - handleEvent@chrome://browser/content/preferences/in-content-new/findInPage.js:31:7 10:31:18 INFO - init@chrome://browser/content/preferences/in-content-new/findInPage.js:22:9 10:31:18 INFO - init_all@chrome://browser/content/preferences/in-content-new/preferences.js:64:3 10:31:18 INFO - EventListener.handleEvent*@chrome://browser/content/preferences/in-content-new/preferences.js:51:1 10:31:18 INFO - 10:31:18 INFO - Stack trace: 10:31:18 INFO - chrome://mochikit/content/tests/SimpleTest/SimpleTest.js:simpletestOnerror:1652 10:31:18 INFO - chrome://browser/content/preferences/in-content-new/findInPage.js:init:22 10:31:18 INFO - chrome://browser/content/preferences/in-content-new/preferences.js:init_all:64
Flags: needinfo?(rchien)
Assignee | ||
Updated•7 years ago
|
Flags: needinfo?(rchien)
Comment hidden (mozreview-request) |
Comment 16•7 years ago
|
||
We're sorry, Autoland could not rebase your commits for you automatically. Please manually rebase your commits and try again. hg error in cmd: hg rebase -s 0dd3d08c0626 -d 4961b6529b1a: rebasing 404005:0dd3d08c0626 "Bug 1374852 - Visiting preferences should always focus on search field r=jaws" (tip) merging browser/components/preferences/in-content-new/findInPage.js merging browser/components/preferences/in-content-new/tests/browser_search_within_preferences_1.js merging browser/components/preferences/in-content-new/tests/browser_search_within_preferences_2.js warning: conflicts while merging browser/components/preferences/in-content-new/findInPage.js! (edit, then use 'hg resolve --mark') unresolved conflicts (see hg resolve, then hg rebase --continue)
Comment hidden (mozreview-request) |
Comment 18•7 years ago
|
||
Pushed by rchien@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/6cc6282c67c7 Visiting preferences should always focus on search field r=jaws
Comment 19•7 years ago
|
||
sorry had to back this out for failures like https://treeherder.mozilla.org/logviewer.html#?job_id=109981946&repo=autoland
Flags: needinfo?(rchien)
Comment 20•7 years ago
|
||
Backout by cbook@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/44331317cfac Backed out changeset 6cc6282c67c7 for test failures in browser_urlbarSearchSuggestions_opt-out.js
Assignee | ||
Updated•7 years ago
|
Flags: needinfo?(rchien)
Updated•7 years ago
|
Target Milestone: --- → Firefox 56
Comment hidden (mozreview-request) |
Comment hidden (mozreview-request) |
Comment hidden (mozreview-request) |
Comment hidden (mozreview-request) |
Comment 25•7 years ago
|
||
Pushed by rchien@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/530f3f121cae Visiting preferences should always focus on search field r=jaws
Comment 26•7 years ago
|
||
Backed out for still failing at least browser_openPreferences.js: https://hg.mozilla.org/integration/autoland/rev/55a67af850961f75eaa4918ac5e2d099e24334a1 Push with failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&revision=530f3f121cae47693b7f3b473f1d4a7f1f297d5f&filter-resultStatus=testfailed&filter-resultStatus=busted&filter-resultStatus=exception&filter-resultStatus=retry&filter-resultStatus=usercancel&filter-resultStatus=runnable
Flags: needinfo?(rchien)
Assignee | ||
Updated•7 years ago
|
Flags: needinfo?(rchien)
Comment hidden (mozreview-request) |
Comment hidden (mozreview-request) |
Comment 29•7 years ago
|
||
Pushed by rchien@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/0f39cea7289a Visiting preferences should always focus on search field r=jaws
Comment 30•7 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/0f39cea7289a
Comment 31•7 years ago
|
||
Build ID: 20170702030204 User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0 Verified as fixed on Firefox Nightly 56.0a1 on Windows 10 x 64, Mac OS X 10.12 and Ubuntu 16.04 x64.
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•