Open Bug 935566 Opened 11 years ago Updated 2 years ago

Canvas 2D API drawSystemFocusRing() introducing error in computing width of bounds in MSAA accessibility API

Categories

(Core :: Graphics: Canvas2D, defect, P2)

28 Branch
x86
macOS
defect

Tracking

()

People

(Reporter: richschwer, Unassigned)

References

(Blocks 1 open bug, )

Details

(4 keywords)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:25.0) Gecko/20100101 Firefox/25.0 (Beta/Release)
Build ID: 20131025151332

Steps to reproduce:

Load the following page: http://www.w3.org/2013/08/canvas-editor.html in Firefox 28 nightly builds with canvas.focusring.enabled turned on in about:config. Use Windows Inspect32 to determine the right bounds of the second checkbox. Compare it to the actual mouse pointer position of the right edge. 


Actual results:

You will see that the right edge is far to the right of the actual edge of the bounds of the rectangle. 


Expected results:

The location of the right edge of the second checkbox should match the right edge of the focus ring drawn when it receives focus.

This is related to the change for https://bugzilla.mozilla.org/show_bug.cgi?id=540456. 

Rik Cabanier will work on this defect.
Component: General → Canvas: 2D
Priority: -- → P2
Whiteboard: parity-chrome-canary
In fixing defect 540456 I did some testing and discovered that the right edge of the second checkbox drawn on the canvas did not have an accessibility API bounds that matched the second focus ring in that the right edge was farther to the right. I confirmed this with the MSAA Inspec32 program. It appears as if the width of the first checkbox may have been added to it. I shared this with Rik Cabanier who also confirmed the defect and he will be working on a fix. 

Here is the test file: http://www.w3.org/2013/08/canvas-editor.html
Setting to NEW as it's clear this is a confirmed issue.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Depends on: 966591
We're running an experiment to see if we can implement hit regions which could/should be used to set up a11y for canvas.
We still need drawFocusIfPossible to show a ring that meets the browser conventions in the absence of media queries - even if that means we remove setting the location from it in favor of hit regions.
(In reply to Rich Schwerdtfeger from comment #4)
> We still need drawFocusIfPossible to show a ring that meets the browser
> conventions in the absence of media queries - even if that means we remove
> setting the location from it in favor of hit regions.

That will still go in. drawFocusIfNeeded is currently behind a runtime flag but we could expose that shortly.
OK. Paul Cotton and Sam Ruby want to shut down canvas 1 next week but we need to fix drawFocusIfNeeded. There is one bug left in Firefox. Can you get this fixed and then get the function exposed in the next week without the flag having to be set?

Here is the bug:

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.
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
Keywords: parity-chrome
Whiteboard: parity-chrome-canary → -canary
Whiteboard: -canary
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.