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
Ensure that our delay in firing the onCreated (TabOpen) event does not result
in other events happening prior to onCreated.
Differential Revision: https://phabricator.services.mozilla.com/D55865
and pageActions.
Before this change, browserActions and pageActions did not trigger
onClick events when middle-clicked, and no information on the button or
any modifiers were passed in the onClick event. With this change, middle
clicking triggers an event, and a clickData object is passed in the
onClick event, with the button and a list of modifiers.
Differential Revision: https://phabricator.services.mozilla.com/D41492
and pageActions.
Before this change, browserActions and pageActions did not trigger
onClick events when middle-clicked, and no information on the button or
any modifiers were passed in the onClick event. With this change, middle
clicking triggers an event, and a clickData object is passed in the
onClick event, with the button and a list of modifiers.
Differential Revision: https://phabricator.services.mozilla.com/D41492
and pageActions.
Before this change, browserActions and pageActions did not trigger
onClick events when middle-clicked, and no information on the button or
any modifiers were passed in the onClick event. With this change, middle
clicking triggers an event, and a clickData object is passed in the
onClick event, with the button and a list of modifiers.
Differential Revision: https://phabricator.services.mozilla.com/D41492
