-
Notifications
You must be signed in to change notification settings - Fork 974
Add focus ring to about page form elements #6037
Conversation
Are these expected? I implemented https://github.com/brave/browser-laptop/blame/master/less/button.less#L9 to avoid unexpected regressions like this: #5661 @bradleyrichter @jkup should browser-laptop/less/forms.less Line 614 in f716273
|
oh no! This may have arrived with a chromium update? We need to prevent this selection from ALL mouse input outside of the page content box. |
If only elements on about pages should have the outline, I would add like this in preferences.less:
|
@bradleyrichter I thought only button, input and select element should have the outline. Please correct me if I'm wrong. Also the screenshots were taken after testing the commit by @jkup. |
To be more specific, this selection should only be shown when invoked for accessibility as an indicator for tabbing through elements when a mouse can not be physically used. If we can control this, it can be used in the toolbars as well. I just don't want it to appear outside of an accessibility mode. |
Can we detect it via JS? |
Reviewing Chrome and Firefox shows that no browser toolbar items are tab-advance selectable except for the URL field which should have its own style and not use the item-select border. Thus, "-webkit-focus-ring-color " should only apply to content area elements and never the toolbar elements. |
We want not only prefs pages but also the bookmarks bar to show the outline like Chrome does. Also there is no way to use JS to detect accessibility mode. I'll update the selectors to be more specific. |
Sorry that I'm just now getting to this; the outline style looks great 😄 When I tried latest against our prefs page, it seems to only be highlighting:
I didn't see buttons get focus, even if I clicked them and then tried the tab |
367b064
to
cf0bdb6
Compare
Fixed it for the navigation buttons like reload/back/forward but the links in preferences#payments should get a focus ring so users know they can interact with them. What @luixxiul mentioned here is the correct behavior: #6037 (comment) |
@bsclifton @luixxiul is this good to go? |
Hey @cezaraugusto I know @bsclifton is super busy lately.. any chance you can give this a review for me and add the ready-to-merge label if it looks good? 🙏 |
++ Manually tested, LGTM Not specifically related, but per @luixxiul comment here, it looks weird for me as well. Simple solution would be add In the future, as we talk about accessibility, would love to see switch buttons tabbable as well. |
@cezaraugusto thanks! I created #6439 to track that UI polish! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ran it manually; looking good 😄 Will run travis-ci tests and merge into 0.13.1-branch if passing
Last travis-ci run showed several errors that I believe are not related; I re-ran each of those locally and they pass as expected 😄 Merging... |
Removed milestone after revert with 2aa39bb |
@bsclifton I'm not sure why this needed to be reverted. Will you please let me know? |
There must be a way to contain this to the DOM/page region so it never effects the toolbar elements... |
|
I think at this point, it would be better to go back to the issue and re-open if we think it's important. We can lay out requirements and set an appropriate milestone |
git rebase -i
to squash commits (if needed).Fix #5971
Auditor @bsclifton, @cezaraugusto