HTML/Canvas Task Force/CR-Test

From W3C Wiki

Test Environments

ID Browser Flags OS Platform Assistive Technology Accessibility Inspector
FFN1 Firefox Nightly 36.0a1 (2014-10-17) canvas.hitregions.enabled Windows N/A Inspect32

stive Technology !! Accessibility Inspector

FFN2 Firefox Nightly 37.0a1 (2014-10-17) canvas.hitregions.enabled Windows N/A Inspect32
CC1 Chrome Canary 45.0.2431.0 dev (64-bit) #enable-experimental-canvas-features Windows N/A Inspect Object 64
CC2 Chrome Canary 41.0.2258.2 canary (64-bit) #enable-experimental-canvas-features Windows N/A Inspect Object 64
WK1 WebKit 7.1 r174761 N/A MAC N/A Accessibility Inspector
IE1 Internet Explorer 11.0.9600.17351 N/A Windows N/A Inspect Object 64

Bug lists

Chrome

[addHitRegion], [drawFocusIfNeeded]

Mozilla

[addHitRegion], [drawFocusIfNeeded]

Webkit

[addHitRegion], [drawFocusIfNeeded]

Testable Statements

drawFocusIfNeeded with no default path defined

Status: Can probably be automated.

Expected Result: No outline is drawn.


Run Test Source File

Browser/OS Platform Special Instructions for testing Pass/Fail
FFN1 None PASS
CC1 None PASS
Webkit/MacOSX None PASS
IE1 None FAIL

drawFocusIfNeeded when the associated element does not have focus and is not a descendant of the an element with focus

Status: Can probably be automated

Expected Result: No outline is drawn.

Run Test Source File


Browser/OS Platform Special Instructions for testing Pass/Fail
FFN1 None PASS
CC1 None PASS
Webkit/MacOSX None PASS
IE1 None FAIL

drawFocusIfNeeded when a default path is provided and the associated fallback element has focus

Status: Can probably be automated

Expected Result: The outline style for the fallback element rendered on the canvas matches a standard link style when it has focus and follows the path applied.

Run Test Source File

Browser/OS Platform Special Instructions for testing Pass/Fail
FFN1 None PASS
CC1 None PASS
Webkit/MacOSX None PASS
IE1 None FAIL

drawFocusIfNeeded when a default path is provided and the associated fallback element is descendant of the element with focus

Status: Can probably be automated

Expected Result: The outline style for the fallback element rendered on the canvas matches a standard link style when it has focus and follows the path applied

Run Test Source File


Browser/OS Platform Special Instructions for testing Pass/Fail
FFN1 None PASS
CC1 None PASS
Webkit/MacOSX None PASS
IE1 None FAIL

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

Run Test Source File

Status: Can probably be automated

Test file: The test file should have enough content in front of the canvas area to allow for it to be scrolled into view upon tabbing to the fallback element.

Expected Result: The outline style for the fallback element rendered on the canvas matches a standard link style when it has focus and follows the path applied when you tab to it. The focus ring on the canvas is scrolled into view by aligning it to the top of the browser window. The location of the fallback element in the platform accessibility APIs, as a result of the scrolling must match the new location resulting from the scroll into view.

Browser/OS Platform Special Instructions for testing Pass/Fail
FFN1 None PASS
CC1 None PASS
Webkit/MacOSX None FAIL
IE1 None FAIL

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.

Run Test Source File

Status: Can probably be automated

Test file: The test file should have enough content in front of the canvas area to allow for it to be scrolled.

Expected Result: The outline style for the fallback element rendered on the canvas matches a standard link style when it has focus and follows the path applied when you tab to it and draw the focus outline. The location of the fallback element in the platform accessibility APIs, as a result of the scrolling, must match the new of the focus outline after scrolling.

Browser/OS Platform Special instructions for testing Pass/Fail
Firefox/Windows Same PASS
Chrome Canary 47.0.2500.0/Win7 Same. PASS
Webkit/MacOSX Same. Fail: No focus ring drawn, no scroll into view.
Internet Explorer Same. Fail: Not implemented.

drawFocusIfNeeded when a default path is provided, the associated fallback element has focus and the system is in a high contrast mode

Status: This requires manual verification

Expected Result: The outline style for the fallback element rendered on the canvas matches a standard link style when it has focus and follows the path applied

Run Test Source File


Browser/OS Platform Special Instructions for testing Pass/Fail
FFN1 High contrast theme #1 PASS Dotted border still visible
CC1 High contrast theme #1 PASS Blue border is now yellow
Webkit/MacOSX None PASS Blue border is now yellow
IE1 High contrast theme #1 FAIL

drawFocusIfNeeded when a default path is provided, the associated fallback element has focus and shadowColor='green', shadowOffsetX=4, shadowOffset=5, globalAlpa="1.0", and globalComposition='xor'

Status: Can probably be automated

Expected Result: The outline style for the fallback element rendered on the canvas matches a standard link style when it has focus and follows the path applied. There will be no effect by a

Run Test Source File


Browser/OS Platform Special Instructions for testing Pass/Fail
FFN1 None PASS
CC1 None PASS
Webkit/MacOSX None PASS
IE1 None FAIL

drawFocusIfNeeded when a default path is provided, the associated fallback element has focus, and a default path is then set to draw the focus for the fallback element that extends beyond the bounds of the canvas element, the focus outline should be clipped, but the fallback element bounds must not

Status: Manual test, requires AAPI inspection

Expected Result: The outline style for the fallback element rendered on the canvas and is clipped to the bounds of the canvas element. The bounds of the fallback element are not clipped.

Run Test Source File


Browser/OS Platform Special Instructions for testing Pass/Fail
FFN1 None PASS (focus indicator is clipped) Fallback: L15,T269,R59,B18 Canvas: L15,T269,R102,B102
CC1 None PASS (focus indicator is clipped) Fallback: L25,T282,R127,B292 Canvas: L25,T282,R127,B385
Webkit/MacOSX None PASS
IE1 None FAIL

addHitRegion receives a dictionary object whose id is empty and a current path is empty

Status: Already automated. Remove "-manual" from file name once approved.

Expected Result: Throw a NotSupportedError

Run Test Source File

"(should write visible DOM text that indicates a NotSupportedError is thrown). Load the test file that uses addHitRegion to Canvas with an empty id. "


Browser/OS Platform Special Instructions for testing Pass/Fail
FFN1 None PASS
CC1 None PASS
Webkit/MacOSX None FAIL
IE1 None FAIL

addHitRegion receives a dictionary object whose id is NULL and the Control is Null

Status: Already automated. Remove "-manual" from file name once approved.

Expected Result: Throw a NotSupportedError

Run Test Source File

"(should write visible DOM text that indicates a NotSupportedError is thrown). Load the test file that uses addHitRegion to Canvas with an empty id. "


Browser/OS Platform Special Instructions for testing Pass/Fail
FFN1 None PASS
CC1 None PASS
Webkit/MacOSX None FAIL
IE1 None FAIL

addHitRegion receives a dictionary object whose id is not null, assign a new hit region to this id with a non-null control

If the arguments object's id member is not null, then let previous region for this ID be the region identified by the ID given by the id member's value in this canvas element. If the id member is null or no such region currently exists, let previous region for this ID be null.

Expected Result: The id for the old hit region is null and the new region has an id equivalent to the new id. The accessibility API bounds of the element pertaining to the control must be equivalent to the regions bounding circumferance in screen coordinates.

Run Test Source File

"On load the test file should set the first region to the id of an associated element in fallback content and the second call, resulting from a button push, should assign the new region to the ID with the old of null. The web page should print out the list each bounding circumference, pertaining to the region and the corresponding id for before and after the new region assignment."

Browser/OS Platform Special Instructions for Testing Pass/Fail
Firefox/Windows Verify the output results. Check the bounds with the MSAA inspect tool. Partial PASS
Chrome/Windows. Verify the output results. Check the bounds with the MSAA inspect tool. Partial PASS
Webkit/MacOSX Verify the output results. Check the bounds with Accessibility Inspector. FAIL
Internet Explorer Verify the output results. Check the bounds with the accessibility inspect tool. FAIL

addHitRegion is called when the specified path has no pixels (no path is assigned) with a valid id in fallback content.

Status: Already automated. Remove "-manual" from file name once approved.

Expected Result: Throw a NotSupportedError. The bounds fallback elements are unaffected.

Run Test Source File

"Should have a button that causes the addHitRegion to be called. (should write visible DOM text that indicates a NotSupportedError is thrown). Load the test file that uses addHitRegion to Canvas with no current path created. "

Browser/OS Platform Special Instructions for testing Pass/Fail
FFN1 None PASS
CC1 None PASS
Webkit/MacOSX None FAIL
IE1 None FAIL

TODO addHitRegion receives a dictionary object whose id is not null, and has a non-null control, and a previous region having the same control exists

Status: Can probably be automated

Expected Result: The region for the old control is replaced with the new region.The id for the old hit region is null and the new region has an id equivalent to the new id. The accessibility API bounds of the element pertaining to the control must be equivalent to the regions bounding circumference in screen coordinates.

Run Test Source File

The test file should set a region with an id and fallback control at load time. This region information should be visible in the DOM as well as the visible path. A button should be available that replaces the hit region with the new control and id and replace the visible DOM content for that region with the new information. A new visible path should be drawn matching the new path.


Browser/OS Platform Special Instructions for testing Pass/Fail
Firefox 39/Windows None Pass
Chrome Canary 46.0.2473.0 canary (64-bit) None Pass
Webkit/MacOSX None FAIL - NO Hit Regions Support
IE1 None FAIL

TODO addHitRegion receives a dictionary object whose id is null, and a previous region has a null id

Expected Result: The previous region for the id is null.

Run Test Source File

Test file: The test file should set up a hit region that includes an id for a region that is null with an associated path representing a region at load time. Also at load time the hit region should be rendered in the DOM, outside of the physical canvas for testing. An HTML button should be visible that, when pressed, makes the new association of null id and then replaced the hit region information for visible inspection in the DOM so that teh tester can validate that the region associated with the null id is null. .

Browser/OS Platform Special Instructions for Testing Pass/Fail
Firefox 39/Windows Verify the region for the null id is null. Pass
Chrome Canary 46.0.2473.0 canary (64-bit)/Windows. Verify the region for the null id is null. Pass
Webkit/MacOSX Verify the region for the null id is null. Fill In "TEST FILE MISSING"
Internet Explorer Verify the region for the null id is null. Fill In "TEST FILE MISSING"

TODO addHitRegion receives a dictionary object whose id is not null, with a non-null region, and a previous region for the id is not null

Expected Result: The previous region for the id is null.

Run Test Source File

Test file: The test file should set up a hit region that includes an id for a region that is not null with an associated path representing a region at load time. Also at load time the hit region should be rendered in the DOM outside the canvas area for visible inspection. An HTML button should be visible so that, when pressed, makes the new association of id with the new non-null region and renders the id and associated region information for visible inspection in the DOM so that the tester can validate that the region associated with the id is null .

Browser/OS Platform Special Instructions for Testing Pass/Fail
Firefox/Windows Verify the region for the id matches the new region. Firefox has a hit region on the first region that is not right but then again there are two regions having the same id and the second overrides the first. This is really an error condition as you have two hit regions having the same id so you would not be able to tell which object the hit test applied to if you had an event handler on canvas. I would consider this an author error although it is necessary that this be tested.
Chrome Canary 46.0.2473.0 canary (64-bit) Verify the region for the id matches the new region. Pass
Webkit/MacOSX Verify the region for the null matches the new region Fill In
Internet Explorer Verify the region for the null matches the new region. Fill In

3.17 addHitRegion receives a dictionary object whose id is not null, with a non-null region, and a non-null control id where a previous non-null region is associated with this id exists

Expected Result: The hit region associated with the control and id matches the new region and the bounds of the control matches, in the accessibility API for this control, the region location in terms of a best fit rectangle in screen coordinates.

Run Test Source File

Test file: The test file should set up a hit region for a fallback element using addHitRegion with an associated id and the corresponding fallback element represented by the control. Also at load time the hit region should be rendered in the DOM outside the canvas area for visible inspection. An HTML button should be visible so that, when pressed, makes the new association of id, and control, with the new non-null hit region and renders the id and associated region information for visible inspection in the DOM. An accessibility test tool should be used so that the tester can validate that the region associated with the control matches the screen location of the hit region as a best fit rectangle.

Browser/OS Platform Special Instructions for Testing Pass/Fail
FFN2 None PASS
Chrome Canary 47.0.2500.0/Win7 None Fail: Top left coordinate is incorrect.
Webkit/MacOSX Verify the AXPosition and AXSize for the fallback element (control) match a best fit rectangle for the new associated hit region with Accessibility Inspector in screen coordinates. FAIL - NOT YET IMPLEMENTED
Internet Explorer Verify the bounding rectangle for the fallback element (control) matches a best fit rectangle for the new associated hit region with the UIA inspect tool. FAIL - NOT YET IMPLEMENTED

addHitRegion receives a dictionary object whose id is not null, with a non-null region, and a non-null control where a previous non-null region, associated with this id, does not exist in the hit region list

Expected Result: A hit region, associated with a control and region id, where the id and the bounds of the control match the hit region location in terms of a best fit rectangle in screen coordinates. The tester can verify this using

Run Test Source File

Test file: The test file should set up a hit region for a fallback element using addHitRegion with an associated id and the corresponding fallback element represented by the control at load time. However, since there is no API to enumerate the hit region list, we must ensure that we are getting mouse events directed at the canvas element with the associated id in the new hit region. The test file should print out mouse events, in an area outside the canvas element that shows hits exist only in the new hit region location for that id and nowhere else. This can be done by applying mouse event handlers on canvas element that check for the id for the hit region. An accessibility test tool must be used so that the tester can validate that the region associated with the control matches the screen location of the hit region as a best fit rectangle.

Browser/OS Platform Special Instructions for Testing Pass/Fail
FFN2 None PASS
Chrome Canary 47.0.2500.0/Win7 None PASS
Webkit/MacOSX Verify the AXPosition and AXSize for the fallback element (control) match a best fit rectangle for the associated hit region with Accessibility Inspector in screen coordinates. FAILS - NOT IMPLEMENTED
Internet Explorer Verify the bounding rectangle for the fallback element (control) matches a best fit rectangle for the associated hit region with the UIA inspect tool. FAILS - NOT IMPLEMENTED

addHitRegion receives a dictionary object whose id is not null, with a non-null region, and a non-null control id where a previous non-null region is associated with this id does exist in the hit region list

Run Test Source File

Expected Result: A hit region, associated with the control and id region, where the id and the bounds of the control match the hit region is stored in the hit region list. The hit region previously associated with the id is removed from the list. However, since there is no API to enumerate the hit region list, mouse events received must only be received for the id in the new hit region location and not the old location. The same hit region is exposed as a best fit rectangle in screen coordinates in the platform accessibility API implementation for the corresponding fallback element.

Test file: The test file should set up a hit region for a fallback element using addHitRegion with an associated id and the corresponding fallback element represented by the control at load time. A timer should be set up to create a new hit region having the control, but a distinctively new location, and remove the old region. The test file should print out mouse events associated with the ids in an area outside the canvas element. An accessibility test tool must be used so that the tester can validate that the region associated with the control matches the screen location of the hit region as a best fit rectangle.

Browser/OS Platform Special Instructions for Testing Pass/Fail
Firefox/Windows Verify that mouse hits having the unique id exist only in the new hit region location for that id and nowhere else. Verify the location for the fallback element (control) matches a best fit rectangle for the associated hit region, with inspect32. PASS
Chrome Canary 47.0.2500.0/Win 7 Verify that mouse hits having the unique id exist only in the new hit region location for that id and nowhere else. Verify the location (bounds for UIA Inspect) for the fallback element (control) matches a best fit rectangle for the associated hit region with inspect32 or UIA Inspect. PASS.
Webkit/MacOSX Verify that mouse hits having the unique id exist only in the new hit region location for that id and nowhere else. Verify the AXPosition and AXSize for the fallback element (control) match a best fit rectangle for the associated hit region with Accessibility Inspector in screen coordinates. Fill In
Internet Explorer Verify that mouse hits having the unique id exist only in the new hit region location for that id and nowhere else. Verify the bounding rectangle for the fallback element (control) matches a best fit rectangle for the associated hit region with the UIA inspect tool. Fill In

addHitRegion receives a dictionary object whose id is not null, with a non-null region, and a non-null control id where a previous non-null region, associated with this control, does exist in the hit region list but has a different id

Expected Result: A hit region, associated with the control and id region, where the id and the bounds of the control match the hit region is stored in the hit region list. The hit region previously associated with the control is removed from the list. However, since there is no API to enumerate the hit region list, mouse events received must only be received for the id in the new hit region location and not the old location. The same hit region is exposed as a best fit rectangle in screen coordinates in the platform accessibility API implementation for the corresponding fallback element.

See PR#2 Run Test Source File

Test file: The test file should set up a hit region for a fallback element using addHitRegion with an associated id and the corresponding fallback element represented by the control at load time. A timer should be set up to replace the hit region for the same control with a new hit region that is distinctly different in location. The test file should print out mouse events associated with the ids in an area outside the canvas element. An accessibility test tool must be used so that the tester can validate that the region associated with the control matches the screen location of the hit region as a best fit rectangle.

Browser/OS Platform Special Instructions for Testing Pass/Fail
Firefox 39/Windows Verify that mouse event hits rendered having a unique id only match the new hit region. Verify the location for the fallback element (control) matches a best fit rectangle for the associated hit region, with inspect32. Pass
Chrome Canary Version 46.0.2473.0 (64-bit)/Windows. Verify that mouse event hits rendered having a unique id only match the new hit region. Verify the location (bounds for UIA Inspect) for the fallback element (control) matches a best fit rectangle for the associated hit region with inspect32 or UIA Inspect. Pass
Webkit/MacOSX Verify that mouse event hits rendered having a unique id only match the new hit region. Verify the AXPosition and AXSize for the fallback element (control) match a best fit rectangle for the associated hit region with Accessibility Inspector in screen coordinates. Fill In
Internet Explorer Verify that mouse event hits rendered having a unique id only match the new hit region. Verify the bounding rectangle for the fallback element (control) matches a best fit rectangle for the associated hit region with the UIA inspect tool. Fill In

addHitRegion is called twice. The first call receives a dictionary object whose id is not null, with a non-null region, and a non-null control. The control is associated with a fallback <div> having a WAI-ARIA role="button" and descendant text. The second call receives a dictionary object whose id is not null, with a non-null region, and a non-null control. Both hit regions have distinctly different ids and controls. The control is associated with a fallback <a> having and descendant text. Each hit region is at distinctly different locations within the canvas. The path used to create each hit region is drawn on the canvas. Call removeHitRegion() for the ID of the first region.

Expected Result: A hit region is only associated with the second control and id in a hit region list. However, since there is no API to enumerate the hit region list, canvas mouse events received must have a matching id corresponding to the second region with the id matching location touched by the mouse pointer. Each hit region must must be exposed as a best fit rectangle in screen coordinates in the platform accessibility API implementation for the corresponding fallback elements.

See PR#3 Run Test Source File

Test file: The test file should initially set up a hit region for each fallback element using addHitRegion with an associated id and the corresponding fallback element represented by the control at load time and then call removeHitRegion on the region having the first ID. The test file should print out mouse events associated with the ids in an area outside the canvas element. An accessibility test tool must be used so that the tester can validate that the region associated with the control matches the screen location of the hit region as a best fit rectangle.

Browser/OS Platform Special Instructions for Testing Pass/Fail
Firefox 39/Windows Verify the location for the fallback element (control) matches a best fit rectangle for each initial associated hit region, with inspect32. Verify that mouse events with a unique id only matching the second hit region are rendered. PASS
Chrome Canary 47.0.2500.0 )/Win7. Verify that mouse events with a unique id only matching the second hit region are rendered. Verify the location (bounds for UIA Inspect) for the fallback element (control) matches a best fit rectangle for each initial associated hit region with inspect32 or UIA Inspect. Fail The top left of corner of the green rectangle is incorrect in the accessibility API mapping.
Webkit/MacOSX Verify that mouse events with a unique id only matching the second hit region are rendered. Verify the AXPosition and AXSize for the fallback element (control) match a best fit rectangle for each initially associated hit region with Accessibility Inspector in screen coordinates. Fill In
Internet Explorer Verify that mouse events with a unique id only matching the second hit region are rendered. Verify the bounding rectangle for the fallback element (control) matches a best fit rectangle for the associated hit region with the UIA inspect tool. Fill In

addHitRegion is called twice. The first call receives a dictionary object whose id is not null, with a non-null region, and a non-null control in fallback content, where the control is a <div> having a WAI-ARIA role="button" and descendant text. The second call receives a dictionary object whose id is not null, with a non-null region, and a non-null fallback content control where the control is a <a> having and descendant text. Both hit regions have distinctly different ids and controls. Each hit region is at distinctly different locations within the canvas. The path used to create each hit region is drawn on the canvas.

Expected Result: A hit region is associated with each control and id in a hit region list and each is associated with the respective control in fallback content. However, since there is no API to enumerate the hit region list, canvas mouse events received must have a matching id corresponding to the respective region with the id matching location touched by the mouse pointer. Each hit region must must be exposed as a best fit rectangle in screen coordinates in the platform accessibility API implementation for the corresponding fallback elements.

Run Test Source File

Test file: The test file should set up a hit region for each fallback element using addHitRegion with an associated id and the corresponding fallback element represented by the control at load time. The test file should print out mouse events associated with the id in an area outside the canvas element.

Browser/OS Platform Special Instructions for Testing Pass/Fail
FFN2 Verify the location for the second fallback element (control) matches a best fit rectangle for the associated hit region, with inspect32. Verify that mouse events for each id matching the corresponding hit region are rendered. PASS
Chrome Canary 47.0.2500.0 )/Win7 Verify the location (bounds for UIA Inspect) for the second fallback element (control) matches a best fit rectangle for the associated hit region with inspect32 or UIA Inspect. Verify that mouse events for each id matching the corresponding hit region are rendered. PASS
Webkit/MacOSX Verify the AXPosition and AXSize for the second fallback element (control) match a best fit rectangle for the associated hit region with Accessibility Inspector in screen coordinates. Verify that mouse events for each id matching the corresponding hit region are rendered. FAIL: Not Implemented.
Internet Explorer Verify the bounding rectangle for the second fallback element (control) matches a best fit rectangle for the associated hit region with the UIA inspect tool. Verify that mouse events for each id matching the corresponding hit region are rendered. FAIL: Not implemented.