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)

55 Branch
enhancement

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)
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)
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
Jared, can you help me review this patch? Thanks
Flags: needinfo?(jaws)
Flags: needinfo?(jaws)
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+
Pushed by rchien@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/0e2417cb980a
Visiting preferences should always focus on search field r=jaws
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)
Flags: needinfo?(rchien)
Pushed by rchien@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/eae501f2729b
Visiting preferences should always focus on search field r=jaws
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)
Flags: needinfo?(rchien)
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)
Pushed by rchien@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/6cc6282c67c7
Visiting preferences should always focus on search field r=jaws
sorry had to back this out for failures like https://treeherder.mozilla.org/logviewer.html#?job_id=109981946&repo=autoland
Flags: needinfo?(rchien)
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
Flags: needinfo?(rchien)
Target Milestone: --- → Firefox 56
Pushed by rchien@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/530f3f121cae
Visiting preferences should always focus on search field r=jaws
Flags: needinfo?(rchien)
Pushed by rchien@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/0f39cea7289a
Visiting preferences should always focus on search field r=jaws
https://hg.mozilla.org/mozilla-central/rev/0f39cea7289a
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
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.

Attachment

General

Created:
Updated:
Size: