1378141 - a11y crashes | PBrowserParent::RecvPDocAccessibleConstructor Constructing a top-level PDocAccessible with null COM

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[roxleitan]

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0
Build ID: 20170704030203

NonVisual Desktop Access (NVDA)
Version: 2017.2
URL: http://www.nvaccess.org

[Steps to reproduce]:
1. Open NVDA
2. Launch Firefox with a new profile
3. Set security.sandbox.content.level=3 and restart the browser
4. Navigate to a web page ( e.g. facebook.com)

[Expected results]:
NVDA should read the text displayed in the Nightly window.

[Actual results]:
Nightly crashes over and over. 
https://crash-stats.mozilla.com/report/index/3af96738-e3f1-412c-9bef-d45520170704

[Note]:
The crash is not reproducible with security.sandbox.content.level=2 (default)

Comment 1

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

This signature is pretty frequent. I don't see sandbox info in the aggregate data unfortunately. Aaron any thoughts on sandbox interaction here?

Comment 2

[(No longer employed by Mozilla) Aaron Klotz]

Based on the annotations in the crash reports, I need to make some improvements to the criteria that we use to select the appropriate manifest on 32-bit builds. I'm not sure why some builds of Windows 10 use a typelib while others don't. Maybe some kind of A/B testing? Anyway, I have a solution in mind.

Comment 3

[(No longer employed by Mozilla) Aaron Klotz]

Another theory I have is that new installs used the proxy/stub but upgrades continued to use the typelib.

Comment 4

[(No longer employed by Mozilla) Aaron Klotz]

Attachment: More sophisticated checks for 32-bit manifest

This patch makes us smarter about how we choose a manifest.

If the current registry configuration clearly points to using a proxy/stub instead of a typelib, we use the 64-bit manifest.

Comment 5

[(No longer employed by Mozilla) Aaron Klotz]

Attachment: More sophisticated checks for 32-bit manifest (r2)

Whoops, fixed a typo in comments.

Comment 6

[(No longer employed by Mozilla) Aaron Klotz]

Attachment: More sophisticated checks for 32-bit manifest (r3)

...and more fixes to eliminate my nonsense...

Comment 7

[Eitan Isaacson [:eeejay]]

Comment on attachment 8883414 [details] [diff] [review]
More sophisticated checks for 32-bit manifest (r3)

Review of attachment 8883414 [details] [diff] [review]:
-----------------------------------------------------------------

::: accessible/windows/msaa/Compatibility.cpp
@@ +282,5 @@
> +{
> +  // If IAccessible's Proxy/Stub CLSID is kUniversalMarshalerClsid, then any
> +  // external a11y clients are expecting to use a typelib.
> +  NS_NAMED_LITERAL_STRING(kUniversalMarshalerClsid,
> +      "{00020424-0000-0000-C000-000000000046}");

I think this, and other obscure IDs should be macros at the top of the file somewhere. Assuming they will never change, but still. There are already a bunch embedded elsewhere, so I don't feel strongly about that.

Comment 8

[(No longer employed by Mozilla) Aaron Klotz]

https://hg.mozilla.org/integration/mozilla-inbound/rev/105fb51de2ab37498e3d7ff5c1dc66a740a823a1
Bug 1378141: Make 32-bit a11y builds make more thorough checks to determine which manifest to load; r=eeejay

Comment 9

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/105fb51de2ab

Comment 10

[roxleitan]

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0
Build ID: 20170707030206

The crash is still reproducible using the latest Nightly 56.0a1 (Build ID: 20170707030206).

https://crash-stats.mozilla.com/report/index/413d6f9a-fc3f-4e31-9a4e-330910170707

Comment 11

[(No longer employed by Mozilla) Aaron Klotz]

(In reply to [e-mail] from comment #10)
> The crash is still reproducible using the latest Nightly 56.0a1 (Build ID:
> 20170707030206).

That doesn't really surprise me -- unfortunately this crash may still result from certain unique configurations that we have not had a chance to troubleshoot.

The good news is that so far crash stats looks much better; I only see two unique installations that this is still happening on. Let's file a new bug for any follow-up work instead of reopening bug 1354077 or this one.

Comment 12

[roxleitan]

I filed bug 1379951.

Comment 13

[Ting-Yu Chou [:ting] (away)]

Bug 1379951 isn't with the signature here, filed bug 1380214.

Comment 14

[ovidiu boca[:Ovidiu]]

I encountered this issue on Windows 7 x32 with FF Nightly 56.0a1(2017-07-20) x32, when I was testing nvaccess https://www.nvaccess.org/download/ to see if screen reader is working with debugger. Every time a have a crash.