Open
Bug 1469779
Opened 8 years ago
Updated 6 months ago
EVENT_OBJECT_LOCATIONCHANGE not fired for objects moved by JavaScript with certain attributes
Categories
(Core :: Disability Access APIs, enhancement, P5)
Tracking
()
NEW
People
(Reporter: mike.hill, Assigned: morgan)
Details
Attachments
(1 file)
If JavaScript on a page changes the location of an object, then an EVENT_OBJECT_LOCATIONCHANGE is not fired for that object. If a screen reader/magnifier is tracking based on the location of the object and caching the location (to reduce the number of IAccessible calls it has to do), it does not know to update it's locations and ends up hilighting the wrong location on the screen.
// test case to replicate bug
<!DOCTYPE html>
<html>
<head>
<script type="text/javascript">
function movedivtranslate()
{
document.getElementById('transform').style.transform="translate(-100px,20px)";
}
function movediv()
{
document.getElementById('transform').style.margin="45px";
}
</script>
<title>Transform-translate example</title>
</head>
<body>
<p onClick="movedivtranslate()">Click this text to move the div with a translate</p>
<p onClick="movediv()">Click this text to move the div by changing the margin</p>
<div id="transform" style="transform:translate(100px,0)">
<div id="divOver" style="height:300px; width:300px; background-color:grey;" >
<span>This object can be moved</span>
</div></div>
</body>
|
||
Comment 1•8 years ago
|
||
That'd be probably a challenge to implement this event, since Firefox never fired it, and we don't have any hook in code to do that easily. For the reference, here's Mike's use case 1466551#c4.
Priority: -- → P5
Ok. I was trying to avoid calling accLocation() more than I had to.
The only workaround I can think of to ensure the visible screen reader highlight is always at the screen location, is to continually call accLocation() on a timer, just in case it might have changed. I shouldn't have to poll for changes in what should be an event driven system.
|
||
Updated•3 years ago
|
Severity: normal → S3
|
Assignee | |
Updated•6 months ago
|
Assignee: nobody → mreschenberg
|
|
Assignee | |
Comment 3•6 months ago
•
|
||
Here's the info microsoft has on when this event should be used:
An object has changed location, shape, or size. The system sends this event for the following user interface elements: caret and window objects. Server applications send this event for their accessible objects.
This event is generated in response to a change in the top-level object within the object hierarchy; it is not generated for any children that the object might have. For example, if the user resizes a window, the system sends this notification for the window, but not for the menu bar, title bar, scroll bar, or other objects that have also changed.
The system does not send this event for every non-floating child window when the parent moves. However, if an application explicitly resizes child windows as a result of resizing the parent window, the system sends multiple events for the resized children.
If an object's State property is set to STATE_SYSTEM_FLOATING, the server sends EVENT_OBJECT_LOCATIONCHANGE whenever the object changes location. If an object does not have this state, servers only trigger this event when the object moves in relation to its parent. For this event notification, the idChild parameter of the WinEventProc callback function identifies the child object that has changed.
I think we need to fire this event directly with something like this instead of FireWinEvent, because we don't have a corresponding gecko event to map here.
|
|
Assignee | |
Comment 4•6 months ago
|
||
FWIW, Looking at the UIA event list I don't see a corresponding event
|
|
Assignee | |
Comment 5•6 months ago
|
||
|
|
Assignee | |
Comment 6•6 months ago
|
||
You need to log in
before you can comment on or make changes to this bug.
Description
•