All users were logged out of Bugzilla on October 13th, 2018

"ASSERTION: No accessible parent" emptying a textbox

RESOLVED FIXED in mozilla29

Status

()

RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: jruderman, Assigned: tbsaunde)

Tracking

(Blocks: 2 bugs, {assertion, testcase})

Trunk
mozilla29
x86_64
Mac OS X
assertion, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

5 years ago
Created attachment 766520 [details]
testcase

With accessibility enabled, the testcase hits:

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

Comment 1

5 years ago
Created attachment 766521 [details]
stack (gdb)
(Assignee)

Updated

5 years ago
Blocks: 888531
(Assignee)

Comment 2

5 years ago
Created attachment 8350662 [details] [diff] [review]
bug 886208 - don't force editor creation in HyperTextAccessible::NativeState()
Attachment #8350662 - Flags: review?(surkov.alexander)
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?
Attachment #8350662 - Flags: review?(surkov.alexander) → review+
(Assignee)

Comment 4

5 years ago
(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
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
(Assignee)

Comment 8

5 years ago
(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.
(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
(Assignee)

Comment 10

5 years ago
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?
(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?
https://hg.mozilla.org/mozilla-central/rev/5ebb4c3f51e8
Assignee: nobody → trev.saunders
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla29
Depends on: 961818
You need to log in before you can comment on or make changes to this bug.