1337983 - Intermittent accessible/tests/browser/e10s/browser_treeupdate_visibility.js | application crashed [@ mozilla::a11y::DocAccessibleParent::SetCOMProxy(RefPtr<IAccessible> const &)]

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Treeherder Bug Filer]

Filed by: wkocher [at] mozilla.com

https://treeherder.mozilla.org/logviewer.html#?job_id=75682098&repo=mozilla-inbound

https://archive.mozilla.org/pub/firefox/tinderbox-builds/mozilla-inbound-win64-debug/1486588405/mozilla-inbound_win8_64-debug_test-mochitest-e10s-browser-chrome-5-bm119-tests1-windows-build27.txt.gz

Comment 1

[Trevor Saunders (:tbsaunde)]

So it looks like Manager() is returning null while within RecvPDocAccessibleConstructor.  That doesn't seem right, is there some odd case it can happen?

Comment 2

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

It looks to me like GetOwnerElement() is returning null from OuterDocOfRemoteBrowser(). I think that can happen while the <browser> is being constructed. I'm guessing this happens on the window.open path while we're processing a nested event loop. Fixing this so that GetOwnerElement() never returns null would be pretty tricky I think.

If you can deal with GetOwnerElement() returning null in a way that makes sense, that would be the easiest fix. Otherwise, you could try to avoid sending the PDocAccessible constructor until window.open() has finished.

Comment 3

[Trevor Saunders (:tbsaunde)]

(In reply to Bill McCloskey (:billm) from comment #2)
> It looks to me like GetOwnerElement() is returning null from
> OuterDocOfRemoteBrowser(). I think that can happen while the <browser> is
> being constructed. I'm guessing this happens on the window.open path while
> we're processing a nested event loop. Fixing this so that GetOwnerElement()
> never returns null would be pretty tricky I think.

err, I should have noticed the message was different, I was kind of in a hurry and just matched line numbers.  That said we don't see the NS_ASSERTION() about frame in OuterDocOfRemoteBrowser() so I would suspect the browser element doesn't yet have an accessible.  Which seems possible.

> If you can deal with GetOwnerElement() returning null in a way that makes
> sense, that would be the easiest fix. Otherwise, you could try to avoid
> sending the PDocAccessible constructor until window.open() has finished.

hmm, I'm not sure how hard it would be to deal with not having a accessible for the browser element at this point.  Its probably easier than blocking PDocAccessibleConstructor though.  We'd need to figure out somethingelse for the com proxy stuff, but that's the only thing that needs it.

Comment 4

[Trevor Saunders (:tbsaunde)]

Attachment: remove incorrect assert

the outer doc of a top level content document does not necessarily exist when
we recieve the PDocAccessibleConstructor message for it.  So we shouldn't asser
there is an outer doc here.


We need to fix this more, but for now lets just remove the assert because its pretty clearly bogus.

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/b2b78a5b4015
remove incorrect assert r=aklotz

Comment 6

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/b2b78a5b4015

Comment 7

[Intermittent Failures Robot]

14 failures in 836 pushes (0.017 failures/push) were associated with this bug in the last 7 days.  
Repository breakdown:
* mozilla-inbound: 6
* autoland: 5
* try: 1
* mozilla-central: 1
* graphics: 1

Platform breakdown:
* windows8-64: 9
* windows7-32-vm: 5

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1337983&startday=2017-02-06&endday=2017-02-12&tree=all

Comment 8

[Ryan VanderMeulen [:RyanVM]]

Looks like this assertion goes back to Fx52. Does this need to be backported?