Bug 138457 – Canvas with focusable fallback content does not scroll into view when focus is moved to fallback

• Status: NEW
• Component: Canvas

[Joanmarie Diggs]

Created attachment 241091 [details]
test case

Steps to reproduce:
1. Load the attached test case in Safari or Epiphany
2. Press Tab to move focus to Link 1
3. Press Tab again to move focus to Link 2 (which is fallback content and not rendered)

Expected results: The parent canvas element would be scrolled into view.

Actual results: Link 1 loses the focus ring, but the canvas element is not scrolled into view making it difficult to identify what has focus.

[Joanmarie Diggs]

Created attachment 241092 [details]
Patch

[Joanmarie Diggs]

Created attachment 246810 [details]
Patch

[Michael Catanzaro]

Comment on attachment 246810 [details]
Patch

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

> Source/WebCore/dom/Element.cpp:2053
> +    else if (auto* canvas = ancestorsOfType<HTMLCanvasElement>(*this).first()) {

Make sure canvas is guaranteed to be non-null.

[Joanmarie Diggs]

Thanks for the review. I had forgotten about this patch.

That said, the previous/obsoleted patch (or some revised version thereof) may need to be the approach taken. The spec changed and scrolling to the top is no longer a requirement. (This is a good thing because scrolling to the top is inconsistent with what some user agents do when other focusable elements need to be scrolled on screen.) See http://www.w3.org/TR/2dcontext/#drawing-paths-to-the-canvas.