Last Comment Bug 571613 - Pass accessibility tests (mochitest-a11y) without assertion failures
: Pass accessibility tests (mochitest-a11y) without assertion failures
Status: NEW
: meta
Product: Core
Classification: Components
Component: Disability Access APIs (show other bugs)
: Trunk
: All All
-- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: alexander :surkov
Mentors:
Depends on: 434681 498015 556004 571609 571610 571611 571612 613174 614369 637898 654770
Blocks: 855375 918246 404077 571530
  Show dependency treegraph
 
Reported: 2010-06-11 15:52 PDT by Jesse Ruderman
Modified: 2014-09-18 11:57 PDT (History)
5 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description User image Jesse Ruderman 2010-06-11 15:52:33 PDT

    
Comment 1 User image David Bolter [:davidb] 2010-06-14 06:32:13 PDT
If there is urgency for bug 404077, we should probably immediately quiet these via preprocessor. Thoughts?
Comment 2 User image Jesse Ruderman 2010-06-14 06:46:47 PDT
There isn't urgency for bug 404077.  I don't think it's happening immediately, and it's likely to work the same way as reftests, where each test is annotated with the number of assertions it currently triggers.
Comment 3 User image Jesse Ruderman 2013-03-15 14:37:41 PDT
Bug 404077 has landed, with initial annotations.  mochitest-a11y wasn't the worst:

http://mxr.mozilla.org/mozilla-central/search?string=expectAssertions&find=accessible
Comment 4 User image Jesse Ruderman 2013-03-15 14:52:46 PDT
And those all seem to be for a small number of assertions, which I can tell my fuzzer to ignore.

###!!! ASSERTION: Can't create an accessible for the document!: 'parentDocAcc', file accessible/src/base/DocManager.cpp, line 389

###!!! ASSERTION: Flush during accessible tree update!: '!accService->IsProcessingRefreshDriverNotification()', file ../../../layout/base/nsPresShell.cpp, line 3817

###!!! ASSERTION: Incorrect results for GetTextHelper: '(finalStartOffset < aOffset && finalEndOffset >= aOffset) || aType != eGetBefore', file accessible/src/generic/HyperTextAccessible.cpp, line 970

###!!! ASSERTION: Incorrect results for GetTextHelper: '(finalStartOffset <= aOffset && finalEndOffset > aOffset) || aType == eGetBefore', file accessible/src/generic/HyperTextAccessible.cpp, line 971

###!!! ASSERTION: Event other than SHOW and HIDE fired for plain text leaves: 'type == nsIAccessibleEvent::EVENT_SHOW || type == nsIAccessibleEvent::EVENT_HIDE', file accessible/src/atk/AccessibleWrap.cpp, line 945
Comment 5 User image Jesse Ruderman 2013-03-15 14:56:44 PDT
It would be nice to have bugs on all of those.  It looks like bug 850973 will take care of a few.
Comment 6 User image Trevor Saunders (:tbsaunde) 2013-03-15 15:29:00 PDT
> ###!!! ASSERTION: Can't create an accessible for the document!:
> 'parentDocAcc', file accessible/src/base/DocManager.cpp, line 389

bug 847636 should probably fix all of those.

> ###!!! ASSERTION: Flush during accessible tree update!:
> '!accService->IsProcessingRefreshDriverNotification()', file
> ../../../layout/base/nsPresShell.cpp, line 3817

that might well be bug 809871.  I haven't checked, but if those are all from bug 809871 you might well be able to not ignore that one for fuzzing now so long as you don't try and fuz xul.

> ###!!! ASSERTION: Incorrect results for GetTextHelper: '(finalStartOffset <
> aOffset && finalEndOffset >= aOffset) || aType != eGetBefore', file
> accessible/src/generic/HyperTextAccessible.cpp, line 970
> 
> ###!!! ASSERTION: Incorrect results for GetTextHelper: '(finalStartOffset <=
> aOffset && finalEndOffset > aOffset) || aType == eGetBefore', file
> accessible/src/generic/HyperTextAccessible.cpp, line 971

surkov's working on cleaning up text crap now, so I'm tempted to see where these assertions stand after that atleast forthe ones not fixed by bug 850973.

> ###!!! ASSERTION: Event other than SHOW and HIDE fired for plain text
> leaves: 'type == nsIAccessibleEvent::EVENT_SHOW || type ==
> nsIAccessibleEvent::EVENT_HIDE', file accessible/src/atk/AccessibleWrap.cpp,
> line 945

I seem to remember looking into that at some point, but don't really remember the details.  In any case that's not a terribly worrying assertion.

(In reply to Jesse Ruderman from comment #5)
> It would be nice to have bugs on all of those.  It looks like bug 850973

I'm sort of afraid such bugs won't be terribly useful for the same reason its not terribly useful to file warning bugs that you don't intend to fix.
Comment 7 User image Jesse Ruderman 2013-06-18 01:22:11 PDT
On Mac at least, it's down to this pair:

###!!! ASSERTION: Incorrect results for GetTextHelper: '(finalStartOffset <= offset && finalEndOffset > offset) || aType == eGetBefore', file accessible/src/generic/HyperTextAccessible.cpp, line 989

###!!! ASSERTION: Incorrect results for GetTextHelper: '(finalStartOffset < offset && finalEndOffset >= offset) || aType != eGetBefore', file accessible/src/generic/HyperTextAccessible.cpp, line 988

And two assertions outside of accessible/:

###!!! ASSERTION: GetElementById had some kind of spasm.: 'Error', file content/xul/content/src/nsXULPopupListener.cpp, line 383

###!!! ASSERTION: Uh, IsInModalState() called w/o a reachable top window?: 'Error', file dom/base/nsGlobalWindow.cpp, line 7345
Comment 8 User image Trevor Saunders (:tbsaunde) 2013-06-18 05:51:00 PDT
(In reply to Jesse Ruderman from comment #7)
> On Mac at least, it's down to this pair:

I saw the same on linux locally a couple days ago.

a couple weeks ago there was still a assert in states/test_frames.html but it was also outside accessible/ though I don't remember what it was about off hand.
Comment 9 User image David Bolter [:davidb] 2014-09-18 11:23:16 PDT
We done here?
Comment 10 User image alexander :surkov 2014-09-18 11:30:06 PDT
technically no I believe, we just put them into "law", however I'm not sure if we need this bug, might be handy as meta one though.
Comment 11 User image David Bolter [:davidb] 2014-09-18 11:57:09 PDT
If we intend to file bugs (or have them already) to hang off this one then it makes sense to keep it -- otherwise not.

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