#52810: fix: load the PDF viewer in in-memory sessions
Description of Change
Closes #27121.
The PDF viewer showed only its grey background in in-memory sessions (partition without persist:): the viewer's extension frame loaded, then every chrome://resources script it depends on was refused, because renderers of an in-memory session were never told the component PDF extension exists. Electron already models an in-memory session as an off-the-record context whose original is the default session (GetOriginalContext(), and ExtensionRegistry/ProcessMap redirect there), but three places didn't follow that model since #22772: SiteInstanceGotProcessAndSite skipped off-the-record contexts, IsSameContext() compared pointers so the default session's RendererStartupHelper ignored those renderers, and the ExtensionSystem factory handed them a separate, never-initialized instance. Those three now agree with the rest, which is also how Chrome treats a profile and its incognito twin. Because that lookup also runs while contexts are torn down, DestroyAllContexts() now destroys the other contexts first and keeps the default one in the map meanwhile (it is still destroyed last), instead of extracting it up front where a teardown-time lookup would have created a second default context. User-loaded extensions stay out of in-memory sessions since they remain incognito-disabled.
Checklist
- PR description included and stakeholders cc'd
-
npm testpasses - tests are changed or added
- PR release notes describe the change in a way relevant to app developers
Release Notes
Notes: Fixed the built-in PDF viewer not rendering documents in in-memory sessions (partitions without the persist: prefix).
Backports
Semver Impact
Semantic Versioning helps users understand the impact of updates:
- Major (X.y.z): Breaking changes that may require code modifications
- Minor (x.Y.z): New features that maintain backward compatibility
- Patch (x.y.Z): Bug fixes that don't change the API
- None: Changes that don't affect using facing parts of Electron