Bug 140326 - [Mac] AX: The input element with type="search" has no default focus outline
Summary: [Mac] AX: The input element with type="search" has no default focus outline
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Accessibility (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: chris fleizach
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2015-01-09 16:24 PST by chris fleizach
Modified: 2015-02-08 11:32 PST (History)
9 users (show)

See Also:


Attachments
patch (5.48 KB, patch)
2015-01-09 16:30 PST, chris fleizach
buildbot: commit-queue-
Details | Formatted Diff | Diff
Archive of layout-test-results from ews100 for mac-mountainlion (652.51 KB, application/zip)
2015-01-09 16:55 PST, Build Bot
no flags Details
patch (6.96 KB, patch)
2015-01-09 17:09 PST, chris fleizach
darin: review+
Details | Formatted Diff | Diff
screenshot1 (45.00 KB, image/png)
2015-02-04 22:48 PST, chris fleizach
no flags Details
screenshot2 (41.43 KB, image/png)
2015-02-04 22:48 PST, chris fleizach
no flags Details
screenshot3 (84.72 KB, image/png)
2015-02-04 22:48 PST, chris fleizach
no flags Details
screenshot4 (83.91 KB, image/png)
2015-02-04 22:49 PST, chris fleizach
no flags Details
screenshot5 (84.58 KB, image/png)
2015-02-04 22:49 PST, chris fleizach
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description chris fleizach 2015-01-09 16:24:16 PST
Unlike other types of input elements (e.g. type="text"), input elements with type="search" don’t show a visible default focus outline. The default focus outline is an essential accessibility feature and should be always visible.

<rdar://problem/19398333>
Comment 1 chris fleizach 2015-01-09 16:30:07 PST
Created attachment 244388 [details]
patch
Comment 2 Build Bot 2015-01-09 16:55:54 PST
Comment on attachment 244388 [details]
patch

Attachment 244388 [details] did not pass mac-ews (mac):
Output: http://webkit-queues.appspot.com/results/5557827493953536

New failing tests:
fast/css/focus-ring-exists-for-search-field.html
Comment 3 Build Bot 2015-01-09 16:55:58 PST
Created attachment 244391 [details]
Archive of layout-test-results from ews100 for mac-mountainlion

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews100  Port: mac-mountainlion  Platform: Mac OS X 10.8.5
Comment 4 chris fleizach 2015-01-09 17:09:30 PST
Created attachment 244392 [details]
patch
Comment 5 Darin Adler 2015-01-12 13:12:51 PST
Comment on attachment 244392 [details]
patch

View in context: https://bugs.webkit.org/attachment.cgi?id=244392&action=review

I’m going to say review+ but I have two substantial concerns:

This seems like a pretty big deal and would change how websites look; we’ve had this behaving like this for a long time. Do we have some examples of websites we looked at to vet this change not only preserves this feature to satisfy accessibility needs but also works well and looks good in the actual websites? I could even imagine contexts in apps or widgets where someone might have wanted to turn this off.

> Source/WebCore/rendering/RenderThemeMac.mm:1605
> +    if (isFocused(o) && o.style().outlineStyleIsAuto())
> +        wkDrawCellFocusRingWithFrameAtTime(search, NSRect(unzoomedRect), documentView, std::numeric_limits<double>::max());

RenderThemeMac::paintMenuList calls setFocusedElementNeedsRepaint. Is there a reason that is correct there but is not needed here?
Comment 6 chris fleizach 2015-01-12 13:42:36 PST
(In reply to comment #5)
> Comment on attachment 244392 [details]
> patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=244392&action=review
> 
> I’m going to say review+ but I have two substantial concerns:
> 
> This seems like a pretty big deal and would change how websites look; we’ve
> had this behaving like this for a long time. Do we have some examples of
> websites we looked at to vet this change not only preserves this feature to
> satisfy accessibility needs but also works well and looks good in the actual
> websites? I could even imagine contexts in apps or widgets where someone
> might have wanted to turn this off.

I'll do some browsing and post screenshots here of what it looks like

> 
> > Source/WebCore/rendering/RenderThemeMac.mm:1605
> > +    if (isFocused(o) && o.style().outlineStyleIsAuto())
> > +        wkDrawCellFocusRingWithFrameAtTime(search, NSRect(unzoomedRect), documentView, std::numeric_limits<double>::max());
> 
> RenderThemeMac::paintMenuList calls setFocusedElementNeedsRepaint. Is there
> a reason that is correct there but is not needed here?

I'll have to investigate what that does and why it did not seem necessary here
Comment 7 chris fleizach 2015-02-04 22:47:43 PST
> > 
> > > Source/WebCore/rendering/RenderThemeMac.mm:1605
> > > +    if (isFocused(o) && o.style().outlineStyleIsAuto())
> > > +        wkDrawCellFocusRingWithFrameAtTime(search, NSRect(unzoomedRect), documentView, std::numeric_limits<double>::max());
> > 
> > RenderThemeMac::paintMenuList calls setFocusedElementNeedsRepaint. Is there
> > a reason that is correct there but is not needed here?
> 
> I'll have to investigate what that does and why it did not seem necessary
> here

It looks like we probably need that NeedsRepaint, because of the comments in

[Mac] Allow focus rings to redraw themselves if necessary
https://bugs.webkit.org/show_bug.cgi?id=132593

"Mac allows focus rings to change rendering over time. Expose this
functionality to WebKit by having the rendering code detect that
a focused element has asked to repaint itself, and also have
the FocusController object remember how long it has been since
an element was focused."
Comment 8 chris fleizach 2015-02-04 22:48:11 PST
Created attachment 246085 [details]
screenshot1
Comment 9 chris fleizach 2015-02-04 22:48:29 PST
Created attachment 246086 [details]
screenshot2
Comment 10 chris fleizach 2015-02-04 22:48:44 PST
Created attachment 246087 [details]
screenshot3
Comment 11 chris fleizach 2015-02-04 22:49:03 PST
Created attachment 246088 [details]
screenshot4
Comment 12 chris fleizach 2015-02-04 22:49:17 PST
Created attachment 246089 [details]
screenshot5
Comment 13 chris fleizach 2015-02-08 00:03:59 PST
http://trac.webkit.org/changeset/179796
Comment 14 Alexey Proskuryakov 2015-02-08 11:32:12 PST
This test fails on all Mavericks bots:

https://webkit-test-results.appspot.com/dashboards/flakiness_dashboard.html#showAllRuns=true&tests=fast%2Fcss%2Ffocus-ring-exists-for-search-field.html

Looks like a font difference, so I'm going to land platform specific results.