886208 - "ASSERTION: No accessible parent" emptying a textbox

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Jesse Ruderman]

Attachment: testcase

With accessibility enabled, the testcase hits:

###!!! ASSERTION: No accessible parent?!: 'parent', file accessible/src/generic/DocAccessible.cpp, line 1864

Comment 1

[Jesse Ruderman]

Attachment: stack (gdb)

Comment 2

[Trevor Saunders (:tbsaunde)]

Attachment: bug 886208 - don't force editor creation in HyperTextAccessible::NativeState()

Comment 3

[alexander :surkov (:asurkov)]

Comment on attachment 8350662 [details] [diff] [review]
bug 886208 - don't force editor creation in HyperTextAccessible::NativeState()

Review of attachment 8350662 [details] [diff] [review]:
-----------------------------------------------------------------

::: accessible/src/generic/HyperTextAccessible.cpp
@@ +103,5 @@
>  {
>    uint64_t states = AccessibleWrap::NativeState();
>  
> +  nsCOMPtr<nsITextControlElement> textControl = do_QueryInterface(mContent);
> +  bool editable = !!textControl;

is it necessary, don't GetNode()->IsEditable() return true for text controls?

Comment 4

[Trevor Saunders (:tbsaunde)]

(In reply to alexander :surkov from comment #3)
> Comment on attachment 8350662 [details] [diff] [review]
> bug 886208 - don't force editor creation in
> HyperTextAccessible::NativeState()
> 
> Review of attachment 8350662 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: accessible/src/generic/HyperTextAccessible.cpp
> @@ +103,5 @@
> >  {
> >    uint64_t states = AccessibleWrap::NativeState();
> >  
> > +  nsCOMPtr<nsITextControlElement> textControl = do_QueryInterface(mContent);
> > +  bool editable = !!textControl;
> 
> is it necessary, don't GetNode()->IsEditable() return true for text controls?

no, that only deals with contenteditable

Comment 5

[Trevor Saunders (:tbsaunde)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/2bf05c015b49

Comment 6

[:Benjamin Peterson]

Backed out for oth orange:
https://tbpl.mozilla.org/php/getParsedLog.php?id=32448847&tree=Mozilla-Inbound

https://hg.mozilla.org/integration/mozilla-inbound/rev/01245f2216d2

Comment 7

[alexander :surkov (:asurkov)]

it seems presence of ** name (and thus presence of text leaf) depends on whether the editor is initialized or not, it shouldn't be important part and can be removed from the test I guess.

another thing worries me if AT's behavior depends on it

Comment 8

[Trevor Saunders (:tbsaunde)]

(In reply to alexander :surkov from comment #7)
> it seems presence of ** name (and thus presence of text leaf) depends on
> whether the editor is initialized or not, it shouldn't be important part and
> can be removed from the test I guess.

that sounds weird and awful, that said I don't understand why we didn't used to create text leaf and now do...

> another thing worries me if AT's behavior depends on it

Well, I don't understand how this patch effects the text leaf creation in the first place, it seems like it really shouldn't.  So I'm really not sure what changed, and so if it might effect people.

Comment 9

[alexander :surkov (:asurkov)]

(In reply to Trevor Saunders (:tbsaunde) from comment #8)
> (In reply to alexander :surkov from comment #7)
> > it seems presence of ** name (and thus presence of text leaf) depends on
> > whether the editor is initialized or not, it shouldn't be important part and
> > can be removed from the test I guess.
> 
> that sounds weird and awful, that said I don't understand why we didn't used
> to create text leaf and now do...

afaik text node is created when editor is initialized

> > another thing worries me if AT's behavior depends on it
> 
> Well, I don't understand how this patch effects the text leaf creation in
> the first place,

you used to get an editor and that created a text node, now you don't do so if nobody else triggers it then there's no text node

Comment 10

[Trevor Saunders (:tbsaunde)]

actually, when I look at the log it looks like the problem is different, there is a text node, but its text is "<bullet><bullet>" not "<black circle><black circle>" which is also odd, but maybe a font issue or something?

Comment 11

[alexander :surkov (:asurkov)]

(In reply to Trevor Saunders (:tbsaunde) from comment #10)
> actually, when I look at the log it looks like the problem is different,
> there is a text node, but its text is "<bullet><bullet>" not "<black
> circle><black circle>" which is also odd, but maybe a font issue or
> something?

ah, quite possibly, double check with Ehsan/Roc? skip name checks? add a possibility to test two scenarios?

Comment 12

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/5ebb4c3f51e8