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.
Created attachment 241092 [details] Patch
Created attachment 246810 [details] Patch
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.
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.