drawFocusIfNeeded defect 425149

Dominic,

The latest editors draft says to scroll the focus ring into view in
drawFocusIfNeeded.

Although this related to a Chrome defect, (
https://code.google.com/p/chromium/issues/detail?id=425149)

Both Chrome and Firefox don't work properly.

The editor's version of the spec. states:

"If the focus area is not on the screen, then scroll the focus outline into
view by aligning it to the top when it receives focus. "

http://www.w3.org/html/wg/drafts/2dcontext/html5_canvas_CR/#dom-context-2d-drawfocusifneeded


These are the two effected test cases:

This impacts two test cases:
https://www.w3.org/wiki/HTML/Canvas_Task_Force/CR-Test#drawFocusIfNeeded_when_a_default_path_is_provided_and_the_associated_fallback_element_is_descendant_of_the_element_with_focus_but_the_element_is_not_visible_on_the_screen


and

https://www.w3.org/wiki/HTML/Canvas_Task_Force/CR-Test#drawFocusIfNeeded_when_a_default_path_is_provided_and_the_associated_fallback_element_is_descendant_of_the_element_with_focus._Scroll_the_window_so_that_the_canvas_moves
.

The best way to reproduce this problem is shrink your brower window so that
the canvas area is well below the bottom of the frame. Then tab to it.


Rik,

Firefox is close but not quite right. It looks like the editors missed an
edit on the working draft as it should say to scroll the focus ring into
view but I believe we were not supposed to say align it to the top of the
window. We can correct that if needed. We believed the browser vendors
agreed it should scroll it the focus ring into view but not necessarily to
the top of the windows. I ran inspect32 on it and the bounds of the
fallback link were not accurate. Aside from these Firefox's implementation
is complete for drawFocusIfNeeded.


Rich


Rich Schwerdtfeger