| cursor |
|
|
| CustomContentRequestInterceptor.kt |
[RequestInterceptor] implementation to inject custom content for firefox:* pages.
|
2471 |
| EngineViewLifecycleFragment.kt |
Initializes and manages the lifecycle of an [EngineView] instance inflated by the super class.
It was originally inspired by Android's WebViewFragment.
To use this class, override it with a super-class that inflates a layout with an [EngineView] with
@id=webview.
Notes on alternative implementations: while composability is generally preferred over
inheritance, there are too many entry points to use this with composition (i.e. all lifecycle
methods) so it's more error-prone and we stuck with this implementation. Composability was
tried in PR #428.
|
5476 |
| ErrorPage.java |
|
2793 |
| FirefoxProgressBar.kt |
|
2053 |
| FocusedDOMElementCache.kt |
|
660 |
| FocusedDOMElementCacheInterface.kt |
When using spatial navigation (i.e. no Cursor) and the WebView loses and regains focus,
it fails to focus the previously focused DOMElement: this class provides functionality to
cache that focused DOMElement (in the DOM) and restore it. The chromium bug for WebView focus
is https://bugs.chromium.org/p/chromium/issues/detail?id=826577 Curiously, VoiceView doesn't
have this problem.
youtube.com/tv does custom focus handling and keyboard navigation: when the WebView fails
to restore the focused element, dpad navigation is entirely broken (#393): that is
why this class is necessary.
It is important that this value be cached just before the WebView regains focus. Otherwise
edge cases present themselves where a DOM element is cached, a new element is focused by a
site, and then we return focus to the earlier (now incorrect) element (see #1830). This
strategy alone does not cover all cases. Focus must also be cached (see #1850) when the
app is backgrounded, or pressing the home button or sleeping will lead to the wrong element
receiving focus when the app is resumed.
NB: if you create an Android View which steals focus from the WebView and it refreshes the
DOM state (e.g. page reload), *you must add custom handling to that view* in order to cache
the focused DOMElement: on your view that returns (and maybe takes) focus to the WebView,
right before you call [View.setVisibility] (or overriding that method and right before calling
super), call [cache]. See [BrowserNavigationOverlay.setVisibility] for an example.
Unfortunately, there are no hooks to generically guarantee we cache the DOMElement the page
will finally set focus on so we require the view implementer to add cache the DOMElement at
the last possible moment before the WebView regains Android focus and loses the focused
DOMElement, which is in [View.setVisibility].
|
2822 |
| LocalizedContent.kt |
Load the content for firefox:about
|
3701 |
| NullSession.kt |
Helper class for migrating to browser-session component. Eventually this class should get
refactored away. It only exists to make code depending on a "NullSession" easier to migrate.
At the latest when introducing the browser-engine component this should not be needed anymore.
|
741 |
| UserAgent.kt |
A collection of user agent functionality. |
3800 |
| VideoVoiceCommandMediaSession.kt |
An encapsulation of a [MediaSession] instance to allow voice commands on videos; we
handle some hardware keys here too: see [MediaSessionCallbacks].
Before use, callers should:
- Add this as a [LifecycleObserver]
- Add [dispatchKeyEvent] to KeyEvent handling
- Call [onCreateEngineView] and [onDestroyEngineView] for fragment lifecycle handling.
To save time, we don't handle audio through either voice or the remote play/pause button: we don't
explicitly handle playback changes ourselves and we mute play/pause events from being received
by the page (see [dispatchKeyEvent]).
When a MediaSession is active, it is available to receive MediaController commands (e.g. Alexa
voice commands). MediaSessions begin inactive. They become active when they go to the playing or
buffering states. They are inactivated when they go to stopped, none, or error states.
For simplicity, we keep our MediaSession active (buffering, playing, paused) while Firefox is
in the foreground and deactivate it (stopped) in the background. If we wanted to be more accurate,
we could add a state (none) when there are no videos present in the DOM (#955).
The constructor should be called from the UiThread because of [mediaSession].
[1]: If the initial playback state is PAUSED or NONE, a music selection voice conversation
overrides our voice commands.
|
17118 |
| VisibilityLifeCycleCallback.java |
This ActivityLifecycleCallbacks implementations tracks if there is at least one activity in the
STARTED state (meaning some part of our application is visible).
Based on this information the current task can be removed if the app is not visible.
|
2588 |
| WebRenderFragment.kt |
Fragment for displaying the browser UI.
|
13726 |
| WebRenderHintViewModel.kt |
Contains business logic for, and exposes data to the hint bar.
See comment on [OverlayHintViewModel] for why this is split into two classes.
|
3843 |
| WebRenderViewModel.kt |
|
898 |
| YouTubeBackHandler.kt |
youtube/tv does not handle their back stack correctly. Going back in history visits redirects
which do not alter the UI. Users must navigate back by pressing ESC. To deal with this,
we remap BACK presses to ESC. When the top of YouTube's back stack is reached, or we are in
an unexpected state, we back all the way out of YouTube.
If YouTube guide-list element is focused or we are in an unexpected state:
- Suppress the DOWN,BACK key event
- Change the UP,BACK key event to go back in history before YouTube
Else:
- Dispatch ESC key event
|
3327 |
| YoutubeGreyScreenWorkaround.kt |
Workaround fix for intermittent grey screen that shows instead of WebView when returning to
YouTube from the home screen, see #1865. Follow-up investigation in #1940.
This fix sends navigation key events on the UI thread to dispel the grey screen.
Other failed attempted workarounds:
- Calling engineView.resume to trigger the webview to "load" from grey screen
- Scrolling webview
- Sending non-view-changing key events
|
1264 |