1218762 - [E10S] crash in mozilla::a11y::ia2Accessible::scrollTo

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Marco Zehe (:MarcoZ)]

This bug was filed from the Socorro interface and is 
report bp-75f62c7d-d1b5-4127-8b0a-e82b12151027.
=============================================================

This happens any time NVDA tries to scroll to something like a link, when downarrowing through a page. Happens on the Firefox First Run page and other pages. Reliably reproducible.

Comment 1

[David Bolter [:davidb] (NeedInfo me for attention)]

Is Document() failing?

Comment 2

[David Bolter [:davidb] (NeedInfo me for attention)]

Alex can you take or help find an owner?

Comment 3

[alexander :surkov (:asurkov)]

(In reply to David Bolter [:davidb] from comment #2)
> Alex can you take or help find an owner?

you may add Document() check to fix a crash but then it likely means you should add it to all other paths. I'm not sure how that thing can get out of sync with IsDefunct state, but since it's e10s thing then Trevor or you may have some ideas on it. Maybe the reason of the crash is the method wasn't proxied yet.

Comment 4

[David Bolter [:davidb] (NeedInfo me for attention)]

OK thanks. Trevor said he'd get to it this week.

Comment 5

[Trevor Saunders (:tbsaunde)]

Attachment: proxy ia2Accessible::scrollTo{,Point}()

Comment 6

[Trevor Saunders (:tbsaunde)]

Attachment: proxy ia2Accessible::scrollTo{,Point}()

Comment 7

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/6c9566ca9ed1

Comment 8

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/6c9566ca9ed1

Comment 9

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Starting with this push, Android 4.3 API11+ debug started perma-failing: https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&tochange=14bd25c63912&fromchange=be035c256991&selectedJob=17630542&filter-searchStr=R%28C2%29

14:20:14     INFO -  REFTEST TEST-START | http://10.0.2.2:8854/tests/gfx/tests/crashtests/408754-1.html
14:20:14     INFO -  REFTEST TEST-LOAD | http://10.0.2.2:8854/tests/gfx/tests/crashtests/408754-1.html | 118 / 738 (15%)
14:20:26     INFO -  REFTEST TEST-PASS | http://10.0.2.2:8854/tests/gfx/tests/crashtests/408754-1.html | (LOAD ONLY)
14:20:26     INFO -  REFTEST INFO | Loading a blank page
14:20:26     INFO -  REFTEST TEST-UNEXPECTED-FAIL | http://10.0.2.2:8854/tests/gfx/tests/crashtests/408754-1.html | assertion count 1 is more than expected 0 assertions

Failing test: https://dxr.mozilla.org/mozilla-central/rev/7883e81f3c305078353ca27a6b1adb8c769d5904/gfx/tests/crashtests/408754-1.html

Please fix it or back it out.

Comment 10

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/1a8bc262190e

Comment 11

[Phil Ringnalda (:philor)]

Heh, fix a Fennec assertion failure. As I explained to them, red faced and screaming, when they insisted on running debug tests, the only way to fix a Fennec assertion failure is to remove every single assertion from the tree, because they do not log what assertion failed.

Annotated, instead.

Comment 12

[Phil Ringnalda (:philor)]

Ah, I'd forgotten in the year since there was last any activity around Fennec assertions that it actually is possible to find what failed, you just have to know of the existence of a separate log, and then match up timestamps between the two logs because the log with the assertions in it doesn't have anything to say what test is running except for tests which happen to hit a JS error in a timely manner and thus report the test name via the file which hit the error.

So the assertion failure is (most likely, almost certainly) "ASSERTION: didn't subtract all that we added: '(space == 0 || space == nscoord_MAX) && ((l2t == FLEX_PCT_LARGE) ? (-0.001f < basis.f && basis.f < 0.001f) : (basis.c == 0 || basis.c == nscoord_MAX))', file /builds/slave/m-in-and-api-11-d-000000000000/build/src/layout/tables/BasicTableLayoutStrategy.cpp, line 1073".

Comment 13

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/1a8bc262190e

Comment 14

[Trevor Saunders (:tbsaunde)]

(In reply to Phil Ringnalda (:philor) from comment #11)
> Heh, fix a Fennec assertion failure. As I explained to them, red faced and
> screaming, when they insisted on running debug tests, the only way to fix a
> Fennec assertion failure is to remove every single assertion from the tree,
> because they do not log what assertion failed.
> 
> Annotated, instead.

heh thanks.  I actually have no idea how this changed any behavior on !windows so that seems reasonablish to me.