Closed
Bug 798492
Opened 12 years ago
Closed 2 years ago
Deprecate/Remove our Windows MSAA BSTR accRole hack
Categories
(Core :: Disability Access APIs, defect, P3)
Tracking
()
RESOLVED
FIXED
117 Branch
Tracking | Status | |
---|---|---|
firefox117 | --- | fixed |
People
(Reporter: davidb, Assigned: Jamie)
References
(Blocks 1 open bug)
Details
Attachments
(2 files, 1 obsolete file)
8.74 KB,
patch
|
Details | Diff | Splinter Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review |
The BSTR hack was deemed a worthy role extensibility mechanism while MSAA-only AT were abundant. We need to find out if vendors are now relying on it, or at least if they can stop replying on it. We can simply use IA2+ (or UIA) extension mechanisms.
This was spun off of bug 734983 and related discussion with Rich regarding ARIA conformance, but at least for now let's see if we can make it about the totality of the BSTR accRole hack/trick.
It might be ambitious given the vendor outreach needed but let's target FF 19. We can probably put the fix behind a config option.
Reporter | ||
Comment 1•12 years ago
|
||
Note, a Microsoft person has asked me a few times (over the years) that we stop doing this.
I suspect it makes their MSAA->UIA bridge technology vomit a little bit.
Comment 2•12 years ago
|
||
David, do you take this bug? If so then please cc me to emails to at vendors.
Reporter | ||
Comment 3•12 years ago
|
||
Yes I should probably take this one of the plate. Taking...
Assignee: nobody → dbolter
Whiteboard: Needs vendor outreach
Reporter | ||
Comment 4•12 years ago
|
||
I'm using these to come up with the right MSAA roles:
http://dvcs.w3.org/hg/html-api-map/raw-file/tip/Overview.html
http://msdn.microsoft.com/en-us/library/windows/desktop/dd373608%28v=vs.85%29.aspx
Reporter | ||
Comment 5•12 years ago
|
||
First quick pass at replacing MSAA stringy roles.
Reporter | ||
Comment 6•12 years ago
|
||
Assignee | ||
Comment 7•12 years ago
|
||
David, I saw your email, but figured it made more sense to respond here. :)
NVDA always uses the IA2 role in preference to the MSAA role as long as retrieving the IA2 role doesn't fail and it isn't IA2_ROLE_UNKNOWN. This means that most of the time, we never even see the BSTR role hack, so this change won't affect us. Unfortunately, I do know that Gecko sometimes fails to map the "object" and "embed" tags correctly to IA2_ROLE_EMBEDDED_OBJECT. I can't remember whether it returns IA2_ROLE_UNKNOWN or fails, nor was I ever able to figure out exactly when this happens. To make matters worse, I recall that this was intermittent even with the same test case.
So, in short, this shouldn't affect us. The one case where it will affect us is "embed" and "object" tags, but that's another bug anyway. The only caveat is that this embed bug will need to be fixed rather urgently if it does show up after the BSTR role hack is removed.
Mick, please comment if you think I've missed anything.
Reporter | ||
Comment 8•12 years ago
|
||
(In reply to James Teh [:Jamie] from comment #7)
> So, in short, this shouldn't affect us. The one case where it will affect us
> is "embed" and "object" tags, but that's another bug anyway. The only caveat
> is that this embed bug will need to be fixed rather urgently if it does show
> up after the BSTR role hack is removed.
Thanks Jamie. I think we could leave the "embedded object" string for now - is that the one you are referring to?
Comment 9•12 years ago
|
||
(In reply to David Bolter [:davidb] from comment #8)
> (In reply to James Teh [:Jamie] from comment #7)
>
> > So, in short, this shouldn't affect us. The one case where it will affect us
> > is "embed" and "object" tags, but that's another bug anyway. The only caveat
> > is that this embed bug will need to be fixed rather urgently if it does show
> > up after the BSTR role hack is removed.
>
> Thanks Jamie. I think we could leave the "embedded object" string for now -
> is that the one you are referring to?
I lean towards to do nothing here because:
# the behavior is in use
# we can't suggest anything better for role mapping, that'll be either unknown role or generic role
# it doesn't really fix the bug 734983 since when 'xml-roles' attribute is standardized by IA2 group (I filed request a while ago and iirc nobody objected it) then it becomes a "standard role mechanism" and we break the spec again.
Reporter | ||
Comment 10•12 years ago
|
||
(In reply to alexander :surkov from comment #9)
> (In reply to David Bolter [:davidb] from comment #8)
> > (In reply to James Teh [:Jamie] from comment #7)
> >
> > > So, in short, this shouldn't affect us. The one case where it will affect us
> > > is "embed" and "object" tags, but that's another bug anyway. The only caveat
> > > is that this embed bug will need to be fixed rather urgently if it does show
> > > up after the BSTR role hack is removed.
> >
> > Thanks Jamie. I think we could leave the "embedded object" string for now -
> > is that the one you are referring to?
>
> I lean towards to do nothing here because:
> # the behavior is in use
> # we can't suggest anything better for role mapping, that'll be either
> unknown role or generic role
> # it doesn't really fix the bug 734983 since when 'xml-roles' attribute is
> standardized by IA2 group (I filed request a while ago and iirc nobody
> objected it) then it becomes a "standard role mechanism" and we break the
> spec again.
I think I understood and agree with the first two bullets, but not sure I understand the last one. Is it about the MSAA BSTR role hack or about object attributes (or both)? Can you explain a bit more?
Assignee | ||
Comment 11•12 years ago
|
||
(In reply to David Bolter [:davidb] from comment #8)
> Thanks Jamie. I think we could leave the "embedded object" string for now -
> is that the one you are referring to?
I've never seen "embedded object", only "embed" and "object" depending on the tag.
(In reply to alexander :surkov from comment #9)
> I lean towards to do nothing here because:
> # the behavior is in use
Arguably, it's only in use because Gecko doesn't expose IA2_ROLE_EMBEDDED_OBJECT sometimes when it should.
> # we can't suggest anything better for role mapping, that'll be either
> unknown role or generic role
True, but that's probably the case for many of the BSTR roles. Otherwise, the hack wouldn't have been introduced in the first place.
> # it doesn't really fix the bug 734983 since when 'xml-roles' attribute is
> standardized by IA2 group (I filed request a while ago and iirc nobody
> objected it) then it becomes a "standard role mechanism" and we break the
> spec again.
I should find that thread. Imo, xml-roles doesn't fit the IA2 spec, since it is HTML specific. I don't follow what you mean about breaking the spec again, though.
Comment 12•12 years ago
|
||
(In reply to David Bolter [:davidb] from comment #10)
> I think I understood and agree with the first two bullets, but not sure I
> understand the last one. Is it about the MSAA BSTR role hack or about object
> attributes (or both)? Can you explain a bit more?
I referred to 'xml-roles' object attributes what is I think you are agree is a role mechanism. If it would be a standard one then it means we shouldn't use it to expose abstract roles.
Comment 13•12 years ago
|
||
(In reply to James Teh [:Jamie] from comment #11)
> (In reply to alexander :surkov from comment #9)
> > I lean towards to do nothing here because:
> > # the behavior is in use
> Arguably, it's only in use because Gecko doesn't expose
> IA2_ROLE_EMBEDDED_OBJECT sometimes when it should.
it should be our bug and it should be fixed. Btw, would you mind to file a bug?
> > # it doesn't really fix the bug 734983 since when 'xml-roles' attribute is
> > standardized by IA2 group (I filed request a while ago and iirc nobody
> > objected it) then it becomes a "standard role mechanism" and we break the
> > spec again.
> I should find that thread. Imo, xml-roles doesn't fit the IA2 spec, since it
> is HTML specific.
I cannot find it. Maybe I was confused.
> I don't follow what you mean about breaking the spec
> again, though.
My point was is 'xml-roles' object attribute is a role mechanism. ARIA spec denies us to expose ARIA abstract roles via "standard role mechanism". I read that as any role mechanism of every AT API spec shouldn't be used to expose abstract roles. While xml-roles is a Firefox feature then probably we won't be pushed about changing existing behavior of xml-roles.
Refer to (http://www.w3.org/WAI/PF/aria-implementation/#mapping_role):
"For the standard role mechanism of the accessibility API, the user agent MUST use the first token in the sequence of tokens in the role attribute value which matches, on comparison, the name of any non-abstract WAI-ARIA role."
Assignee | ||
Comment 14•12 years ago
|
||
(In reply to alexander :surkov from comment #13)
> > Arguably, it's only in use because Gecko doesn't expose
> > IA2_ROLE_EMBEDDED_OBJECT sometimes when it should.
> it should be our bug and it should be fixed. Btw, would you mind to file a
> bug?
I could, but I haven't because I don't have any useful information at this point. It looks like this might have been a work around for Firefox 3.6, so it's possible this has been fixed since then.
Reporter | ||
Comment 15•12 years ago
|
||
(In reply to alexander :surkov from comment #12)
> (In reply to David Bolter [:davidb] from comment #10)
>
> > I think I understood and agree with the first two bullets, but not sure I
> > understand the last one. Is it about the MSAA BSTR role hack or about object
> > attributes (or both)? Can you explain a bit more?
>
> I referred to 'xml-roles' object attributes what is I think you are agree is
> a role mechanism. If it would be a standard one then it means we shouldn't
> use it to expose abstract roles.
As per IRC I'd like this bug to be scoped to the MSAA role string hack. Microsoft has asked us not to do this and if it is not going to horribly break AT then I'd like to try to remove it.
Reporter | ||
Comment 16•12 years ago
|
||
(In reply to James Teh [:Jamie] from comment #14)
> (In reply to alexander :surkov from comment #13)
> > > Arguably, it's only in use because Gecko doesn't expose
> > > IA2_ROLE_EMBEDDED_OBJECT sometimes when it should.
> > it should be our bug and it should be fixed. Btw, would you mind to file a
> > bug?
> I could, but I haven't because I don't have any useful information at this
> point. It looks like this might have been a work around for Firefox 3.6, so
> it's possible this has been fixed since then.
Hi Jamie, any update? It would be nice to remove the hack entirely.
Assignee | ||
Comment 17•12 years ago
|
||
(In reply to David Bolter [:davidb] from comment #16)
> > > > Arguably, it's only in use because Gecko doesn't expose
> > > > IA2_ROLE_EMBEDDED_OBJECT sometimes when it should.
> Hi Jamie, any update? It would be nice to remove the hack entirely.
I really don't remember how to reproduce this at all. I guess go ahead and remove it and I'll file a bug if I see the problem again.
Reporter | ||
Comment 18•12 years ago
|
||
[Note to self: one of the related w3 actions https://www.w3.org/WAI/PF/Group/track/actions/1175]
Reporter | ||
Updated•12 years ago
|
Whiteboard: Needs vendor outreach → Needs vendor outreach [update and land may 15 for test buffer]
Reporter | ||
Updated•12 years ago
|
Flags: needinfo?(dbolter)
Reporter | ||
Comment 19•12 years ago
|
||
Clean try run: https://tbpl.mozilla.org/?tree=Try&rev=22cb1df5ef89
Attachment #670002 -
Attachment is obsolete: true
Reporter | ||
Updated•12 years ago
|
Whiteboard: Needs vendor outreach [update and land may 15 for test buffer]
Assignee | ||
Comment 20•12 years ago
|
||
(In reply to David Bolter [:davidb] from comment #19)
> Clean try run: https://tbpl.mozilla.org/?tree=Try&rev=22cb1df5ef89
I don't understand how to get from these URLs to the actual builds.
Comment 21•12 years ago
|
||
(In reply to James Teh [:Jamie] from comment #20)
> (In reply to David Bolter [:davidb] from comment #19)
> > Clean try run: https://tbpl.mozilla.org/?tree=Try&rev=22cb1df5ef89
> I don't understand how to get from these URLs to the actual builds.
under the heading dbolter@mozilla.com or similar there should be link with text "b" click on that then area should up with link to "build directory" which should include firefox.zip I believe.
Reporter | ||
Comment 22•12 years ago
|
||
Builds are here http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/dbolter@mozilla.com-22cb1df5ef89/
Flags: needinfo?(dbolter)
Reporter | ||
Comment 23•12 years ago
|
||
Jamie, note I wasn't expecting you to test these builds - do debug builds work for you?
Assignee | ||
Comment 24•12 years ago
|
||
(In reply to David Bolter [:davidb] from comment #23)
> Jamie, note I wasn't expecting you to test these builds - do debug builds
> work for you?
They normally don't. Let me know if/when you want me to test a normal build.
Reporter | ||
Comment 25•12 years ago
|
||
Thanks. Non-debug build will show up here: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/dbolter@mozilla.com-fa56af7cd553
Reporter | ||
Comment 26•12 years ago
|
||
Comment on attachment 787643 [details] [diff] [review]
kill_bstr_hack
Let me know what you think of the mappings. I think it makes sense to try to keep close to IE since MSAA is less useful (thank IA2) for most of these cases anyway. The other good thing is that we already expose the tag as an object attr anyways.
Hopefully this brings us into ARIA spec compliance.
Attachment #787643 -
Flags: review?(surkov.alexander)
Comment 27•12 years ago
|
||
It seems it something new with me. Didn't we talk to stop ARIA roles mapping into BSTR only?
Comment 28•12 years ago
|
||
(In reply to alexander :surkov from comment #27)
> It seems it something new with me. Didn't we talk to stop ARIA roles mapping
> into BSTR only?
maybe it shouldn't be new with me per my comments in this bug :) but I completely missed that we wanted to go further than ARIA roles removing. Can you remind me details please?
Reporter | ||
Comment 29•12 years ago
|
||
I can't remember. I know we talked about both options. We can limit to aria only at least initially. I'll update.
Reporter | ||
Updated•12 years ago
|
Attachment #787643 -
Flags: review?(surkov.alexander)
Reporter | ||
Comment 30•11 years ago
|
||
Alexander finally looked at doing this and it would be a less nice patch, which reminds me of a chat where I think I got your approval on going further here. Want to chat again?
Comment 31•11 years ago
|
||
(In reply to David Bolter [:davidb] from comment #30)
> Alexander finally looked at doing this and it would be a less nice patch,
removing ARIA only you mean? it should be a simple patch
> which reminds me of a chat where I think I got your approval on going
> further here. Want to chat again?
yep, btw does Chrome copy us here?
Reporter | ||
Updated•7 years ago
|
Assignee: dbolter → nobody
Priority: -- → P3
Updated•2 years ago
|
Severity: normal → S3
Assignee | ||
Updated•2 years ago
|
Assignee: nobody → jteh
Assignee | ||
Comment 34•2 years ago
|
||
This is a hack that was implemented a long time ago before IAccessible2.
However, it violates the MSAA API, breaks Microsoft's Inspect tool and violates the Core/HTML AAM specs.
In terms of backwards compatibility, anyone who wants to really access web content will be using IAccessible2 anyway.
Also, Chromium has never implemented this hack.
The mappings were largely taken from the Core and HTML AAM specs.
Where those specs didn't specify an MSAA role, ROLE_SYSTEM_GROUPING has been used, which is the closest we can get to a generic mapping and is also used by Chromium for these cases.
Comment 35•2 years ago
|
||
Pushed by jteh@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/8a84e76f7bb0
Don't return BSTR from IAccessible::get_accRole. r=nlapre
Comment 36•2 years ago
|
||
bugherder |
Status: NEW → RESOLVED
Closed: 2 years ago
status-firefox117:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 117 Branch
You need to log in
before you can comment on or make changes to this bug.
Description
•