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.

Is Document() failing?

Alex can you take or help find an owner?

(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.

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

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.

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.

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".

(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.