Last Comment Bug 765110 - TextLeafAccessibleWrap is never instanciated
: TextLeafAccessibleWrap is never instanciated
Status: RESOLVED FIXED
[qa-]
:
Product: Core
Classification: Components
Component: Disability Access APIs (show other bugs)
: Trunk
: x86 All
: -- normal (vote)
: mozilla16
Assigned To: Mark Capella [:capella]
:
: alexander :surkov
Mentors:
Depends on:
Blocks: 745428
  Show dependency treegraph
 
Reported: 2012-06-14 18:12 PDT by Hubert Figuiere [:hub]
Modified: 2012-08-14 08:27 PDT (History)
5 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
fixed


Attachments
Patch (v1) (1.47 KB, patch)
2012-06-27 06:15 PDT, Mark Capella [:capella]
tbsaunde+mozbugs: review+
akeybl: approval‑mozilla‑aurora+
Details | Diff | Splinter Review

Description Hubert Figuiere [:hub] 2012-06-14 18:12:25 PDT
TextLeafAccessibleWrap is never instanciated. Only the MSAA backend define the class, but the nsAccessibilityService implementation will not instanciate it, sticking to TextLeafAccessible.
Comment 1 Mark Capella [:capella] 2012-06-27 06:15:40 PDT
Created attachment 637091 [details] [diff] [review]
Patch (v1)

I imagine this is just this small change ... coidng is simple, but how do I test it / see the before and after effects for myself? I'm tinkering around with DOMInspector and ACCProbe ... but they're relatively new tools to me, and maybe I just don't know where to look ....
Comment 2 Mark Capella [:capella] 2012-06-27 08:59:46 PDT
(regression from bug 745428 - my bad!)

Push to TRY:
https://tbpl.mozilla.org/?tree=Try&rev=161957dc4af5
Comment 3 Hubert Figuiere [:hub] 2012-06-27 10:37:40 PDT
Now I filed the bug but never tested anything. I just found it out trying to do stuff on Mac.

Does it really have an impact on Windows?
Comment 4 Mark Capella [:capella] 2012-06-27 19:55:15 PDT
Dang ... other people 
https://tbpl.mozilla.org/?tree=Try&rev=da6c03ac176f
Comment 5 alexander :surkov 2012-06-27 21:50:43 PDT
(In reply to Mark Capella [:capella] from comment #1)
> Created attachment 637091 [details] [diff] [review]
> Patch (v1)
> 
> I imagine this is just this small change ... coidng is simple, but how do I
> test it / see the before and after effects for myself? I'm tinkering around
> with DOMInspector and ACCProbe ... but they're relatively new tools to me,
> and maybe I just don't know where to look ....

This class implements ISimpleDOMText interface, I don't think we have tools to test it. 

Please make sure to get an approval for aurora where we regressed since this interface is used by AT.

Hub, thanks for the catch.
Comment 6 Mark Capella [:capella] 2012-06-28 02:38:13 PDT
https://tbpl.mozilla.org/?tree=Mozilla-Inbound&rev=dcf8693ba5e1
Comment 7 Ed Morley [:emorley] 2012-06-29 03:38:39 PDT
Sorry, this merged yesterday, but I completely forgot to do the bug marking:
https://hg.mozilla.org/mozilla-central/rev/dcf8693ba5e1
Comment 8 Trevor Saunders (:tbsaunde) 2012-07-05 13:52:42 PDT
Comment on attachment 637091 [details] [diff] [review]
Patch (v1)

[Approval Request Comment]
Bug caused by (feature/regressing bug #):  745428
User impact if declined:  certain assistive technology on windows may have trouble accessing text of web page elements.
Testing completed (on m-c, etc.): yes
Risk to taking this patch (and alternatives if risky): extremely low.  it changes nothing on platforms other than windows.  On windows there nothing is removed, but an interface that we stopped exposing to screen readers will be exposed again.  nothing has changed in the implementation, so it should be very safe.
String or UUID changes made by this patch:  none
Comment 9 Alex Keybl [:akeybl] 2012-07-08 17:55:33 PDT
Comment on attachment 637091 [details] [diff] [review]
Patch (v1)

[Triage Comment]
Low risk a11y fix for a FF15 regression. Approved for Aurora 15.

Note You need to log in before you can comment on or make changes to this bug.