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)

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

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.

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

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.

Whoops, fixed a typo in comments.

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

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.

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

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

(In reply to roxana.leitan@softvision.ro 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.

I filed bug 1379951.

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

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.