Calling window.restore will return the window to its previous
dimensions. Prior to this patch, extension windows transitioning to
normal state would add a second step where they would forcibly resize
the window to content. The motivating reason for this additional step is
some kind of difficulty with macOS windows restoring from other states.
Those issues were handled comprehensively in Bug 1631735, and now the
extra step is unnecessary and surprising to users. Since the call was
being made potentially during a deminimization native transition, the
window is at a very small size and expanding it to fit the content is
resizing it to a strange small size. Window.restore will do the right
thing, so this patch stops calling sizeToContent.
Differential Revision: https://phabricator.services.mozilla.com/D189972
Calling window.restore will return the window to its previous
dimensions. Prior to this patch, extension windows transitioning to
normal state would add a second step where they would forcibly resize
the window to content. The motivating reason for this additional step is
some kind of difficulty with macOS windows restoring from other states.
Those issues were handled comprehensively in Bug 1631735, and now the
extra step is unnecessary and surprising to users. Since the call was
being made potentially during a deminimization native transition, the
window is at a very small size and expanding it to fit the content is
resizing it to a strange small size. Window.restore will do the right
thing, so this patch stops calling sizeToContent.
Differential Revision: https://phabricator.services.mozilla.com/D189972
And make callers rely on that instead of allowInheritPrincipal when
creating lazy tabs.
Unlike allowInheritPrincipal, skipLoad sets the nodefaultsrc attribute.
This avoids a load instead of falling back to about:blank.
One consequence of that is that switching to a lazy about:blank tab will
not notify invoke listeners registered with addTabsProgressListener
(listeners registered with addProgressListener will still be invoked).
Thus test browser_open_in_lazy_tab.js needs to be updated.
Differential Revision: https://phabricator.services.mozilla.com/D166012
Before my previous patch, the widget code lied, and always returned the
requested window state before it had actually happened. Instead, teach
the extension code to wait if necessary for the window state to be
effective.
Differential Revision: https://phabricator.services.mozilla.com/D152394
- Remove unsupported tabs API definitions that are gone in MV3.
- Mark content script APIs (superseded by scripting APIs) as MV2-only.
- Re-enable extension.getBackgroundPage in MV2 since it makes sense with
event pages, and we enabled runtime.getBackgroundPage in bug 1759308.
- Add tests that verify API availability in MV3.
Differential Revision: https://phabricator.services.mozilla.com/D143721
Read this as a first step. It's the easiest first step I could think of to
both reduce the quantity of stuff we serialize and ship to the worker as
well as to spread it out over multiple messages.
Anyway, the motivation is pretty simple. Taking a look at a session store
file on disk, a giant chunk of it is base64 encoded tab icons. I suspect
that in many cases these are not distinct. For my session store it's about
90% the same repeated searchfox icon over and over.
So what I did was I changed the "image" property of the tab to be a reference
into a deduplicated cache of objects (in this case strings). Whenever the tab
icon changes, we drop a reference to its cache entry and add a reference to a
new or existing entry. Each time a cache entry is added or deleted, we send
a message to the worker to update its own copy of the cache. This does
represent a memory hit, since the cache is maintained on the worker as well as
the main thread, but I think it's going to be minor, and it's only in one
process. Given the deduplication there is the possibility of an overall
reduction in memory use? This needs more testing.
Once it comes time to write the session data to disk, we send the payload with
"image" entries referencing IDs in the cache. When the worker gets the message
to write, it adds its internal cache to the object, which it then serializes
to JSON and writes to disk as usual.
When reading the data off disk, we take the cache items that had been written
and we slowly populate the worker's internal cache with them (to not overload
during startup with a giant message). And when populating tab icons of tabs in
the tab strip, we look up the image in the main thread copy of the cache. Also,
if we cannot find the entry, we assume that the image is just the raw
representation of the image. This ensures that we interpret a sessionstore file
from prior to this patch correctly.
Additionally, since we have the cache duplicated on both threads, if the worker
gets terminated for some reason, we rehydrate it with the snapshot of the cache
from when we noticed it was a problem.
I suspect some tests will need to be updated, or maybe many tests. However I
wanted to throw this patch past someone with more knowledge of the session
store's inner workings before throwing a bunch of time at that.
Differential Revision: https://phabricator.services.mozilla.com/D114196
