This bug is for crash report bp-c9aae560-4139-4fa0-9172-d93720190628.

Top 10 frames of crashing thread:

0 xul.dll void mozilla::a11y::HyperTextProxyAccessibleWrap::GetNativeInterface accessible/windows/ProxyWrappers.h:49
1 xul.dll mozilla::a11y::AccessibleWrap::GetIAccessibleFor accessible/windows/msaa/AccessibleWrap.cpp:1374
2 xul.dll mozilla::a11y::AccessibleWrap::GetIAccessibleFor accessible/windows/msaa/AccessibleWrap.cpp:1374
3 xul.dll void mozilla::a11y::HyperTextProxyAccessibleWrap::GetNativeInterface accessible/windows/ProxyWrappers.h:49
4 xul.dll mozilla::a11y::AccessibleWrap::GetIAccessibleFor accessible/windows/msaa/AccessibleWrap.cpp:1374
5 xul.dll void mozilla::a11y::HyperTextProxyAccessibleWrap::GetNativeInterface accessible/windows/ProxyWrappers.h:49
6 xul.dll mozilla::a11y::AccessibleWrap::GetIAccessibleFor accessible/windows/msaa/AccessibleWrap.cpp:1374
7 xul.dll void mozilla::a11y::HyperTextProxyAccessibleWrap::GetNativeInterface accessible/windows/ProxyWrappers.h:49
8 xul.dll mozilla::a11y::AccessibleWrap::GetIAccessibleFor accessible/windows/msaa/AccessibleWrap.cpp:1374
9 xul.dll void mozilla::a11y::HyperTextProxyAccessibleWrap::GetNativeInterface accessible/windows/ProxyWrappers.h:49

Affected versions

• 69.0a1(2019-06-28)

Affected platforms

• Windows 10x64 aarch64

Steps to reproduce

1. Launch FF.
2. Go to about:config.
3. Set fission.autostart to True then restart the browser.
4. Go to any top website (eg: Netflix, Youtube, Reddit, Facebook, Pornhub, Twitter)

Expected result

• Reaching the website is done without any engine and stability issues( crashes and freezes)

Actual result*

• Reaching any website will render various behaviors as follows:

• After a while , the browser will enter a non responsive stat (Not Responding) and will ultimately crash.
• Sometimes, it will crash simply when reaching any website.

Regression range

• Will return with regression range ASAP

Another note:

• After a crash, when choosing to Restore, the page that will be loaded is the one previously accessed before the crash occurred.
• The frequency of crashes on this platform makes it impossible for us to properly test.

Bugbug thinks this bug is a regression, but please revert this change in case of error.

Jamie, can you look into this for Fission M4 target?

Previously, DocAccessibleParent::AddChildDoc used the presence of a BrowserBridgeParent to determine whether the child document was in a different process to the parent document.
While this is normally the case, there can be a point while the embedded document is loading where there is a temporary document in the same (embedder) process.
In this case, we tried to get the COM proxy for the child document.
For a child document in the same process, this isn't available yet, so this caused infinite recursion (stack overflow) in ProxyAccessible::GetCOMInterface.

Instead of using the presence of BrowserBridgeParent, first check whether the child document is at the top level of its content process.
If it isn't, the document is in the same process as its parent.

Also, add a DIAGNOSTIC_ASSERT to ProxyAccessible::GetCOMInterface which will fire if no COM proxy or MSAA child id has been set.
Previously, we just recursed infinitely and overflowed the stack in this case, which is painful to debug.

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

69=disabled since the fission pref is nightly only.

Confirming this issue as verified fixed on Nightly 70.0a1 (2019-07-16) on Windows 10 aarch64 .