Remove code to support out-of-process iframes in Firefox which is no longer necessary.#16746
Conversation
…longer necessary.
WalkthroughThe changes in Changes
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (invoked as PR comments)
Additionally, you can add CodeRabbit Configration File (
|
See test results for failed build of commit 55fbf64eb2 |
|
Thanks for the code style fix. I did run this by the linter and it didn't pick this up. Is that something worth fixing if this is the preferred style? |
|
we'll be working on automated linting using ruff in the next week so I won't worry about it. soon manual linting will mostly be a thing of the past 😄 |
Link to issue number:
Reverts #10707.
Summary of the issue:
Firefox moved most iframes into different processes (AKA out-of-process iframes or project "Fission") in 2020. This necessitated some changes to NVDA because with Firefox's older multi-process architecture, objects in one process were unaware of objects in another. However, with the new "Cache the World" architecture released in Firefox 113 (just over a year ago in May 2023), this special handling is no longer necessary, since all objects are served from the parent process and the parent process is aware of all of them.
While removing this code likely doesn't have any discernible user benefit, I think it's worthwhile to remove unnecessary complexity.
There is no supported version of Firefox (even ESR) which depends on this code.
Description of user facing changes
None. There might be a slight performance benefit, but I doubt this is perceivable.
Description of development approach
Reverted #10707, adjusting for non-substantive changes that were made since #10707 was merged (code style, moved constants, etc.).
Note that this moves back to using accChild instead of getNVDAObjectFromEvent. At the time, there didn't appear to be a performance benefit to using accChild and using getNVDAObjectFromEvent made it easier to implement #10707. However, I have since then discovered (through Firefox profiling) that at least in-process, AccessibleObjectFromWindow can be rather slow relative to direct COM calls. This probably isn't noticeable for NVDA's use case, especially given that we're doing this across processes, but any performance boost is probably worthwhile here.
I didn't add a change log entry because there is no user visible change here.
Testing strategy:
Tested pages with and without iframes in both Firefox and Chrome. Everything worked as expected.
Known issues with pull request:
None.
Code Review Checklist:
Summary by CodeRabbit