These follow a few more simple patterns I was able to find:
- the testDispatcher is not used anywhere else: remove it
- the testDispatcher is used to set a main dispatcher: this is redundant
to the test rule so remove it both the dispatcher & the main dispatcher
- the testDispatcher is actually used elsewhere: for simplicity, change
the reference to point at the MainCoroutineRule.
This is redundant to the built-in TestCoroutineDispatcher() method.
TestCoroutineDispatcher is also preferred because it has enhanced
testing functionality including defining a context-specific
`runBlockingTest` function, the ability to control `delay` timings, etc.
This new property helps with separating the current responsibilities of
lastMediaAccess such that after this:
- lastMediaAccess is only updated when media starts playing allowing clients to
order media tabs and find the first / last tab with in progress media.
- lastHadMediaSessionActive indicates whether a MediaSession should be active
for this tab and serves as a backup for lastMediaUrl for the situations where a
website might allow media to continue playing even when the users accesses
another page (with another URL) in that same HTML document.
Renamed "BrowserState.updateTabState" to a more appropriate
"BrowserState.updateTabOrCustomTabState" signaling that it can be used to
update any tab or custom tab.
Created two new "BrowserState.updateTabState" and
"BrowserState.updateCustomTabState" extension methods to allow updating the
state of either tabs or custom tabs depending on the properties needing update.
By this we are forcing the clients to choose what type of SessionState they
want updated and in so limiting the situations in which the old API would try
to update any SessionState and could throw a ClassCastException if in the
"update" lambda parameter callers would try to update a property not existing
in one SessionState implementation but available in other.
LastMediaAccessState contains both
- lastMediaAccess - timestamp for the last time media started playing
(which is reset to 0 when GV deactivates the MediaSession)
- lastMediaUrl - tab url when media started playing
By combining this two properties we'll know that a tab has in progress media
even when:
- the user navigates to another page in the same document
but media continues to play, MediaSession exists, lastMediaAccess is not reset,
- media starts playing in another tab
but the previous media tab has the same url as lastMediaUrl.
After media starting to play in a tab only if
- user navigated to another website and
- MediaSession is deactivated (happens when navigating to another website or
when media starts playing in another tab)
will we consider that this tab doesn't anymore have in progress media.
This commented method seems to be a leftover from the previous refactoring.
"behavior.forceExpand(..)" now calls "expandWithAnimation" for which we already
have a test at line 450.
We need to wait until having a response from GeckoView on how it handled the
touch only after which we'll know whether to animate the toolbar or not.
The edgecase scenario of having pull to refresh enabled even before having a
response from GeckoView will still work because "canOverscrollTop()" only
checks for the touch to not be handled by the browser to pan the page.
Adds `showAddonsInMenu` in WebExtensionBrowserMenuBuilder to allow the option of removing `Add-ons`
item even if another extensions are displayed
Add unit tests to test if 'Add-ons' item visibility is updated properly
This new property will be a timestamp of the last time media started playing in
the current page or be 0 if media hadn't started playing or another page loaded
in this tab so media was stopped.
To observe the media changes and update this property LastMediaAccessMiddleware
will have to be set on BrowserStore.
