These tests are excluded from android test runs in moz.build. Including
an explicit annotation in each manifest avoids scheduling confusion.
browser-chrome and plain-chrome tests in browser/ are of no concern,
since those test types are never scheduled on android.
Differential Revision: https://phabricator.services.mozilla.com/D125266
browser_ext_incognito_views.js is failing intermittently in optimized builds due to a race between
a browserAction popup being opened as part of the test task and the related window being closed at the
end of the same test task.
This patch moves the responsability of closing the browserAction popup and the window to the chrome-privileged
part of the test, and makes sure that we are explicitly waiting for the browserAction popup to be opened and
loaded and then completely closed before removing the related Firefox window.
Differential Revision: https://phabricator.services.mozilla.com/D124047
Also fix to actually call the correct requestLongerTimeout() method,
and shorten the timeout by half to see if That would be enough.
Differential Revision: https://phabricator.services.mozilla.com/D122052
Also fix to actually call the correct requestLongerTimeout() method,
and shorten the timeout by half to see if That would be enough.
Differential Revision: https://phabricator.services.mozilla.com/D122052
When an extension does call tabs.discard earlier in the tab creation (e.g. when the extension calls
tabs.discard from inside a tabs.onUpdated listener), when the tab is activated (e.g. by selecting
the non-currently active lazified tab) Firefox is expected to restore it to the webpage url that
was being loaded.
This was already working as expected on non-private tabs, where the expected tab url was stored
in the TabStateCache as the userTypedValue (which seems to be part of a fix also related to
tabs.discard and landed in Firefox 62 from Bug 1422588).
It didn't work yet for private tabs, because for a private tab we are storing `{isPrivate: true}`
into the TabStateCache as soon as we are creating the tab, and so the change to SessionStore
resetBrowserToLazyState applied from Bug 1422588 had no effect for the private tabs
(due to the check for an existing cached entry for the same tab).
This patch applies a small change to ensure we are caching the userTypedValue set on the browser
element if one is not already stored in the TabStateCache, and adds an additional test case
to browser_ext_tabs_discarded.js which cover the expected behavior (and fails as expected
without a fix for the underlying issue).
Differential Revision: https://phabricator.services.mozilla.com/D122370
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
Since this is testing undesired but previously consistent behavior, I'm just
relaxing the (sometimes) expected results with Fission SHIP.
Differential Revision: https://phabricator.services.mozilla.com/D120798
