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
ATK, Windows and XPCOM expect aria attribute keys to be stripped of
their aria- prefix. We should still store the item using the aria_ atom
and then strip the prefix when converting the key to a string.
Differential Revision: https://phabricator.services.mozilla.com/D116786
I'm not sure in what markup/style scenario a list item accessible
wouldn't have a frame, but would have a bullet. Apparently that can
happen in the wild. Added an assertion, hopefully we can trip it on
something reproducable in the future.
Differential Revision: https://phabricator.services.mozilla.com/D117347
This isn't used and thus isn't necessary.
Also, we can currently only support 127 content processes because of this id allocation, so avoiding this removes that restriction.
Differential Revision: https://phabricator.services.mozilla.com/D116206
Sending these doesn't really do any harm, as we already disregard them in the parent process.
However, it's certainly unnecessary and wasteful.
Differential Revision: https://phabricator.services.mozilla.com/D116204
Eitan Isaacson
Paul Bone
Doug Thayer
Narcis Beleuzu
Morgan Reschenberg
Butkovits Atila
Hiroyuki Ikezoe
Dorel Luca
James Teh
Kagami Sascha Rosylight
Ryan VanderMeulen
Marian-Vasile Laza
Csoregi Natalia
Mats Palmgren
Ed Lee
Masayuki Nakano