Now that ProxyWrappers (RemoteAccessibleWrap and friends) are gone, IsProxy() can never be true, so checking it is pointless.
Differential Revision: https://phabricator.services.mozilla.com/D117536
Previously, when the cache was disabled, we had a RemoteAccessibleWrap for every RemoteAccessible.
This is no longer necessary and now only serves as an extra level of indirection and memory waste.
We still keep the stub MsaaAccessible to hold the id sent up from content.
Differential Revision: https://phabricator.services.mozilla.com/D117528
In a subsequent patch, we want to call it with a RemoteAccessible instead of a RemoteAccessibleWrap.
As an instance method of AccessibleWrap, this wouldn't be possible because AccessibleWrap is a subclass of LocalAccessible.
Strictly speaking, there's no good reason for this to be part of AccessibleWrap at all any more, but I'm not dealing with that here.
Differential Revision: https://phabricator.services.mozilla.com/D117527
This was previously used to wrap the COM proxy for the document child of an OOP iframe in a content process.
It was returned by OuterDocAccessible::LocalChildAt*.
Instead, BrowserBridgeChild now directly holds the COM proxy and MsaaAccessible traversal methods have specific code paths to return that as appropriate.
Since we no longer need the Windows OuterDocAccessible traversal overrides for OOP iframes nor remote top level documents, they have been removed entirely.
Differential Revision: https://phabricator.services.mozilla.com/D117526
It still can't handle being called on a RemoteAccessible because Bounds isn't unified yet.
However, this allows it to be called on a local OuterDoc (a XUL browser element) and return a remote document child.
Previously, this was handled by the RemoteAccessibleWrap returned from OuterDocAccessible::LocalChildAt, but that will go away in a subsequent patch.
Differential Revision: https://phabricator.services.mozilla.com/D117525
UnifiedComplete must stick around to serve as an mozIPlacesAutoComplete implementation for XUL consumers like search.js and privacy.js.
Differential Revision: https://phabricator.services.mozilla.com/D119306
This implements Jamie's suggested fixes for a screenreader issue when the
skeleton UI is enabled. Most of the work here is just pulling out pieces from the
files we needed to include in mozglue so that any references to, say, nsString
or other pieces from libxul either no longer exist or are only included when
building libxul. In a few cases this meant creating whole files to house single
functions, which isn't so pretty, but it was the best I could come up with to
get the job done.
Differential Revision: https://phabricator.services.mozilla.com/D117663
This implements Jamie's suggested fixes for a screenreader issue when the
skeleton UI is enabled. Most of the work here is just pulling out pieces from the
files we needed to include in mozglue so that any references to, say, nsString
or other pieces from libxul either no longer exist or are only included when
building libxul. In a few cases this meant creating whole files to house single
functions, which isn't so pretty, but it was the best I could come up with to
get the job done.
Differential Revision: https://phabricator.services.mozilla.com/D117663
We are going to disallow having any remote <browser>s or <iframe>s inside
nsDeckFrame, so this test is no longer necessary.
Differential Revision: https://phabricator.services.mozilla.com/D119066
This implements Jamie's suggested fixes for a screenreader issue when the
skeleton UI is enabled. Most of the work here is just pulling out pieces from the
files we needed to include in mozglue so that any references to, say, nsString
or other pieces from libxul either no longer exist or are only included when
building libxul. In a few cases this meant creating whole files to house single
functions, which isn't so pretty, but it was the best I could come up with to
get the job done.
Differential Revision: https://phabricator.services.mozilla.com/D117663
For OOP iframes, a doc load complete event on the embedder document doesn't necessarily mean the iframe document has finished loading yet.
We already checked for the busy state on the nested iframe doc and waited for a doc load complete event in that case.
However, depending on timing, it might be possible there is no document at all (even a busy one), so we should wait for doc load complete in that case too.
This is a speculative fix; I wasn't able to reproduce this myself.
Differential Revision: https://phabricator.services.mozilla.com/D118123
Returning E_NOINTERFACE for IUnknown at least is probably bad form.
Also, mscom::Interceptor seems to expect IDispatch to always be available and asserts if it isn't.
We're seeing some weird COM crashes in the wild, and while I don't know if this will fix them, correctness seems like a good place to start.
Differential Revision: https://phabricator.services.mozilla.com/D117967
This speeds up reflows on pages like view source that have a single
giant container. But this maybe slows down other cases? I'm not 100%
sure.
Differential Revision: https://phabricator.services.mozilla.com/D117948
This speeds up reflows on pages like view source that have a single
giant container. But this maybe slows down other cases? I'm not 100%
sure.
Differential Revision: https://phabricator.services.mozilla.com/D117948
An OuterDocAccessible can be recreated, causing the embedder accessible for a BrowserBridgeParent (OOP iframe) to change.
However, changing the src of an iframe can also cause a new BrowserBridgeParent to be created.
Previously, if addition of the child document was still pending when this occurred (because the OuterDocAccessible hadn't been sent to the parent yet), this pending addition could remain, causing problems if the id was reused later.
To fix this (and to hopefully make this more robust given the continued problems we're seeing in the wild with this area of the code), I've completely refactored the way we handle these pending child doc additions.
Rather than tracking the pending additions by their accessible id and child doc, we track them by their BrowserBridgeParent.
This way, we're closest to a single source of truth.
We also remove a pending addition when an associated BrowserBridgeParent is destroyed.
Differential Revision: https://phabricator.services.mozilla.com/D117889
An OuterDocAccessible can be recreated, causing the embedder accessible for a BrowserBridgeParent (OOP iframe) to change.
However, changing the src of an iframe can also cause a new BrowserBridgeParent to be created.
Previously, if addition of the child document was still pending when this occurred (because the OuterDocAccessible hadn't been sent to the parent yet), this pending addition could remain, causing problems if the id was reused later.
To fix this (and to hopefully make this more robust given the continued problems we're seeing in the wild with this area of the code), I've completely refactored the way we handle these pending child doc additions.
Rather than tracking the pending additions by their accessible id and child doc, we track them by their BrowserBridgeParent.
This way, we're closest to a single source of truth.
We also remove a pending addition when an associated BrowserBridgeParent is destroyed.
Differential Revision: https://phabricator.services.mozilla.com/D117889
James Teh
Florian Quèze
Morgan Reschenberg
Eitan Isaacson
Tooru Fujisawa
Harry Twyford
Butkovits Atila
Paul Bone
Doug Thayer
Narcis Beleuzu
Hiroyuki Ikezoe
Dorel Luca
Kagami Sascha Rosylight
Ryan VanderMeulen
Marian-Vasile Laza
Csoregi Natalia
Mats Palmgren
Ed Lee