Closed Bug 385326 Opened 13 years ago Closed 13 years ago

text content in MIDAS is not accessible

Categories

(Core :: Disability Access APIs, defect, major)

x86
Linux
defect
Not set
major

Tracking

()

RESOLVED FIXED

People

(Reporter: ginnchen+exoracle, Assigned: ginnchen+exoracle)

References

()

Details

(Keywords: access, regression)

Attachments

(2 files, 1 obsolete file)

Try http://www.mozilla.org/editor/midasdemo/

Enter something.

Check with accerciser.

In Firefox 2.0, it is
...
html container:Mozilla Rich Text Editing Demo
    panel:about:blank
        text:about:blank (impl text editable interface)
            text:some text

In Minefield, it is
...
document frame:Mozilla Rich Text Editing Demo
    panel:about:blank
        document frame:about:blank (not imple text/text editable interface)

The text in the editor is not exposed.
This would affect any rich text edit area including Thunderbird, right?
It doesn't affect composing mails in Thunderbird. Surprise.

Bug 356863 is related.
nsDocAccessible is created as readonly, and atkObj is created without EDITABLE interface,
When it becomes editable, we didn't recreate atkObj with EDITABLE interface.
We can set mAtkObject to nsnull to recreate.
Could we assume it has no child when it becomes editable?

It seems it can only go from NON_EDITABLE to EDITABLE since we only observe "obs_documentCreated".
Click the "Read only" checkbox doesn't make mEditor null. (and don't have READONLY state, another bug?)
We can't assume it has no children, unfortunately. Someone can load an <iframe src="somedocumenturl"> and then make it editable in JS. 

> Click the "Read only" checkbox doesn't make mEditor null. (and don't have
> READONLY state, another bug?)
Yes, sounds like another bug.
Attached patch patch (obsolete) — Splinter Review
Attachment #269837 - Flags: review?(aaronleventhal)
Comment on attachment 269837 [details] [diff] [review]
patch

Looks good to me. It's missing a \n at the end of nsDocAccessibleWrap.cpp
Attachment #269837 - Flags: review?(aaronleventhal) → review+
Attached patch patch v2Splinter Review
Aaron, do you think this one is better?
I think it's more straightforward.
Attachment #269980 - Flags: review?(aaronleventhal)
Comment on attachment 269980 [details] [diff] [review]
patch v2

Surkov can give a more complete review right now -- I am in all-day-long meetings.
Attachment #269980 - Flags: review?(aaronleventhal) → review?(surkov.alexander)
(In reply to comment #5)
> > Click the "Read only" checkbox doesn't make mEditor null. (and don't have
> > READONLY state, another bug?)
> Yes, sounds like another bug.
> 

Bug 386027 filed for this.
Comment on attachment 269980 [details] [diff] [review]
patch v2

r=me, looks ok
Attachment #269980 - Flags: review?(surkov.alexander) → review+
I think we'd better send children_changed:remove/add events when we recreate atkobject.
Since this bug blocks several bugs I'm working on, I committed patch v2, and I will give another patch to address the events.

Keep it open till we've a decision for children_changed:remove/add events.
We might want to just invalidate the entire nsDocAccessible when it changes it's editable property.

I think, according to the rules of COM, an object must support the same interfaces throughout its lifetime.

That means if it changes whether it supports nsIAccessibleEditableText or not, it should really be a new object, right?
Attached patch patchSplinter Review
I think it's a good place to emit these events, because we can emit with correct oldAtkObj and new mAtkObject here.
But I noticed EVENT_REORDER is also fired for this nsDocAccessible, it seems this patch is not necessary.

Alexander, what do you think?
Attachment #270567 - Flags: review?(surkov.alexander)
(In reply to comment #13)
> We might want to just invalidate the entire nsDocAccessible when it changes
> it's editable property.

Sounds good.

Not sure how to invalidate itself in nsDocAccessible::Observe()
(In reply to comment #14)
> Created an attachment (id=270567) [details]
> patch
> 
> I think it's a good place to emit these events, because we can emit with
> correct oldAtkObj and new mAtkObject here.
> But I noticed EVENT_REORDER is also fired for this nsDocAccessible, it seems
> this patch is not necessary.
> 
> Alexander, what do you think?
> 

If reorder event is fired then do you need previous patch? I though accessible object for reorder event should be recreated. Isn't it?
(In reply to comment #16)
> If reorder event is fired then do you need previous patch? I though accessible
> object for reorder event should be recreated. Isn't it?
> 

I still need patch v2, it could be a bug of the reorder event for nsDocAccessible.
Comment on attachment 270567 [details] [diff] [review]
patch

the patch looks ok
Attachment #270567 - Flags: review?(surkov.alexander) → review+
Attachment #269837 - Attachment is obsolete: true
patch for the events committed.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.