| Summary: | Canvas with focusable fallback content does not scroll into view when focus is moved to fallback | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Joanmarie Diggs <jdiggs> | ||||||||
| Component: | Canvas | Assignee: | Joanmarie Diggs <jdiggs> | ||||||||
| Status: | NEW --- | ||||||||||
| Severity: | Normal | CC: | cmarcelo, commit-queue, eric.carlson, esprehn+autocc, gyuyoung.kim, kangil.han | ||||||||
| Priority: | P2 | ||||||||||
| Version: | 528+ (Nightly build) | ||||||||||
| Hardware: | Unspecified | ||||||||||
| OS: | Unspecified | ||||||||||
| Attachments: |
|
||||||||||
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. |
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.