Android-components listens to the GeckoView callback onFirstContentfulPaint to
track whether a contentful paint has occured, in order to decide when to
thumbnail a tab. Currently this gets fired once per tab.
However, when the GeckoSession is paused, we clear cached resources in the
compositor. This means that when the session is resumed, the compositor does not
have the necessary information to render the page (such as painted content
buffers, or the webrender display list). Because android-components attempts to
capture a new thumbnail immediately upon resuming, it ends up capturing a blank
thumbnail.
To fix this, add a new callback onPaintStatusReset() which is invoked when the
cached resources are cleared. Android-components can listen for this to be
informed when the contentful paint is no longer visible. It can then wait until
the subsequent contentful paint occurs before capturing the thumbnail.
Differential Revision: https://phabricator.services.mozilla.com/D87341
After moving to actors it will be common to define both a onInit phase and a
onEnable phase for actors. We don't handle having both phases contain a
main-process script so we should check that.
Differential Revision: https://phabricator.services.mozilla.com/D87119
This commit splits the `GeckoViewContent` actor in two parts:
- `GeckoViewContent` proper, which runs unconditionally and handles code that
needs to run regardless of whether we have a delegate installed or not.
- `ContentDelegate` which runs only when a delegate is first installed.
This emulates the previous paradigm of installing some listeners only when the
delegate is installed.
I discussed it briefly with :nika and she thinks that splitting modules in two
should not affect performance in a measurable manner.
Note that actors cannot be registered per-window, so we will get messages from
all windows as long as one content delegate is registered.
Differential Revision: https://phabricator.services.mozilla.com/D86776
This commit splits the `GeckoViewContent` actor in two parts:
- `GeckoViewContent` proper, which runs unconditionally and handles code that
needs to run regardless of whether we have a delegate installed or not.
- `ContentDelegate` which runs only when a delegate is first installed.
This emulates the previous paradigm of installing some listeners only when the
delegate is installed.
I discussed it briefly with :nika and she thinks that splitting modules in two
should not affect performance in a measurable manner.
Note that actors cannot be registered per-window, so we will get messages from
all windows as long as one content delegate is registered.
Differential Revision: https://phabricator.services.mozilla.com/D86776
This avoids problems where a foreground tab tries to communicate with a background
tab via `window.opener`, but is unable to because the background tab
is suspended.
Differential Revision: https://phabricator.services.mozilla.com/D83693
Reinstate customUserAgent interface for nsIDocShell. This is so it can be used
as a choke-point to catch setting values on docshells which are in the process
of changing process. We don't want to send changes which will be rejected on the
parent side.
This code should be removed once callers setting customUserAgent are refactored
to only occur from parent process.
Differential Revision: https://phabricator.services.mozilla.com/D75006
When you type in a textarea, and zoom to position the caret, then click, we'll
scroll all the way to the top of the textarea, via:
IMEStateManager::OnClickInEditor -> SetIMEState -> SetInputContext -> mEditable->NotifyIME(EditableListener::NOTIFY_IME_OPEN_VKB);
Even if the keyboard was already displayed. In this case, we're not moving
focus, and panning to the start causes more issues than it fixes. Prevent
zooming to the start of the input in this case, but still do it if we get the
resize event (and thus toggle the keyboard).
Differential Revision: https://phabricator.services.mozilla.com/D67222
--HG--
extra : moz-landing-system : lando
That data is not the right one anyway, since it comes from the previous page
rather than the current one.
Note: this is also broken on desktop too. It will be fixed once we move to main
process history (hopefully?).
Differential Revision: https://phabricator.services.mozilla.com/D67392
--HG--
extra : moz-landing-system : lando
The extension background page should be loaded when either an event needs
to be sent to it or after the browser has started up. When an extension
is updated the special startup event listeners do not appear to be built
yet and GeckoView was not sending browser started notification, which meant the
background page never being loaded.
Differential Revision: https://phabricator.services.mozilla.com/D66717
--HG--
extra : moz-landing-system : lando
We won't need these suspend states anymore which were used for media control and audio focus on Fennec.
Differential Revision: https://phabricator.services.mozilla.com/D65265
--HG--
extra : moz-landing-system : lando
History is kept locally on the content process (or main process for main
process pages), so when going from one process to the other we need to restore
history. This will eventually be superseded by moving all history to the main
process, but we don't know when that's going to happen so we need to add this
workaround here. Desktop has the same workaround in place and this patch is
based on that code.
There are two places where we need to restore history:
- App navigates to page directly using `loadURI` or similar: in this case we
need to pass down the load details to the content process alongside the
history information so that we can restore and immediatelly navigate to the
new page. This also avoids an extra history reloading that ordinarely happens
when restoring history.
- App calls `goBack`, `goForward`, etc: in this case we don't need to reload a
page but just restore the history and adjust the `historyIndex`. I'm not
entirely sure why we need to add `1` to the `historyIndex` but that's what
Desktop does and it seems to work correctly so I just did it.
This patch changes `updateRemoteTypeForURI` to `updateRemoteAndNavigate` which
more closely matches what that method is doing now, this is similar to what
happens on desktop.
This patch also adds a `window.moduleManager` that can be used in Actors to
access the current `moduleManager`. I expect this to go away when we fully
migrate all modules to actors.
Differential Revision: https://phabricator.services.mozilla.com/D62970
--HG--
extra : moz-landing-system : lando
This patch is doing two things.
1. Make GeckoView directly gets the ContentBlockingLog in the parent
process when it gets the bundle event 'ContentBlocking:RequestLog'. It
will get the top-level browsingContext and get the log from the
WindowGlobal of this browsingContext.
2. Remove the GeckoViewContentBlockingChild. The child module of
ContentBlocking is no longer needed since it serves nothing after we move
the functionality of getting log to the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D57464
--HG--
extra : moz-landing-system : lando
Private browsing data kept getting cleared each time a new tab was created
since gecko thought there were no more private windows. Also, fixes a typo
in the case of "windowtype".
Differential Revision: https://phabricator.services.mozilla.com/D60330
--HG--
extra : moz-landing-system : lando
Private browsing data kept getting cleared each time a new tab was created
since gecko thought there were no more private windows. Also, fixes a typo
in the case of "windowtype".
Differential Revision: https://phabricator.services.mozilla.com/D60330
--HG--
extra : moz-landing-system : lando
This patch is doing two things.
1. Make GeckoView directly gets the ContentBlockingLog in the parent
process when it gets the bundle event 'ContentBlocking:RequestLog'. It
will get the top-level browsingContext and get the log from the
WindowGlobal of this browsingContext.
2. Remove the GeckoViewContentBlockingChild. The child module of
ContentBlocking is no longer needed since it serves nothing after we move
the functionality of getting log to the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D57464
--HG--
extra : moz-landing-system : lando
`viewport-fit` is hint that browser application can use cutout area. So we should expose it to GeckoView application to set `layoutInDisplayCutoutMode`.
When meta element is found or changed, `ContentDelegate.onMetaviewportFitChange` is called. Even if nothing, it will be called after DOMContentLoaded is fired.
Depends on D57398
Differential Revision: https://phabricator.services.mozilla.com/D55610
--HG--
extra : moz-landing-system : lando
The GeckoView is listening OnContentBlockingEvent in the content process.
As we move the event into the parent process, we have to change it to
listen the event in the parent process.
This patch also adds a workaround in the test
ContentBlockingControllerTest#getLog(). This workaround adds a 500ms
delays before we check the ContentBlockingLog. This is needed because there
is a delay between the notification of OnContentBlockingEven in the parent
process and the actual recording of the log in the content process. This
workaround will be no longer needed once we move the log entirely to the
parent process (Bug 1599046).
Differential Revision: https://phabricator.services.mozilla.com/D56749
--HG--
extra : moz-landing-system : lando
Since bug 1514429 window.inner{Width,Height} don't return the visual viewport
size so once after the content scale changed, i.e. the visual viewport size
doesn't match window inner size, GeckoView::ScrollBy and ScrollTo don't work
as expected. This commit has JUnit tests to generate the situation by calling
nsIDOMWindowUtils.setResolutionAndScaleTo.
Differential Revision: https://phabricator.services.mozilla.com/D56321
--HG--
extra : moz-landing-system : lando
The GeckoView is listening OnContentBlockingEvent in the content process.
As we move the event into the parent process, we have to change it to
listen the event in the parent process.
This patch also adds a workaround in the test
ContentBlockingControllerTest#getLog(). This workaround adds a 500ms
delays before we check the ContentBlockingLog. This is needed because there
is a delay between the notification of OnContentBlockingEven in the parent
process and the actual recording of the log in the content process. This
workaround will be no longer needed once we move the log entirely to the
parent process (Bug 1599046).
Differential Revision: https://phabricator.services.mozilla.com/D56749
--HG--
extra : moz-landing-system : lando
also freeze the presshell when setActive(false) is called to stop requestAnimationFrames
Differential Revision: https://phabricator.services.mozilla.com/D55343
--HG--
extra : moz-landing-system : lando
Do not dispatch SELECT_ALL selection action if the input is empty or all the text is already selected.
Differential Revision: https://phabricator.services.mozilla.com/D53828
--HG--
extra : moz-landing-system : lando
Do not dispatch SELECT_ALL selection action if the input is empty or all the text is already selected.
Differential Revision: https://phabricator.services.mozilla.com/D53828
--HG--
extra : moz-landing-system : lando
Remove mobile/android/extensions/ and /mobile/android/chrome/content from mozilla-central (Fennec leftovers)
Differential Revision: https://phabricator.services.mozilla.com/D51194
--HG--
extra : moz-landing-system : lando
This patch removes the use of UserAgentOverrides from browser.js
The UA change when in desktop mode now uses nsIDocShell.customUserAgent, while the feature landed in bug 838332 that is only performed for t.co URLs is removed, as it landed 4 years ago and was limited to Nightly.
Differential Revision: https://phabricator.services.mozilla.com/D14749
--HG--
extra : moz-landing-system : lando
This patch removes the use of UserAgentOverrides from browser.js
The UA change when in desktop mode now uses nsIDocShell.customUserAgent, while the feature landed in bug 838332 that is only performed for t.co URLs is removed, as it landed 4 years ago and was limited to Nightly.
Differential Revision: https://phabricator.services.mozilla.com/D14749
--HG--
extra : moz-landing-system : lando
This patch removes the use of UserAgentOverrides from browser.js
The UA change when in desktop mode now uses nsIDocShell.customUserAgent, while the feature landed in bug 838332 that is only performed for t.co URLs is removed, as it landed 4 years ago and was limited to Nightly.
Differential Revision: https://phabricator.services.mozilla.com/D14749
--HG--
extra : moz-landing-system : lando
Agi Sferro
Jamie Nicol
Eugen Sawin
Razvan Maries
Dorel Luca
Mihai Alexandru Michis
James Willcox
Kris Maglione
Dan Glastonbury
Emilio Cobos Álvarez
Brendan Dahl
Sebastian Hengst
Alastor Wu
Cosmin Sabou
Matt Woodrow
Thomas Wisniewski
Mark Banner
Tim Huang
Brendan Dahl
Bogdan Tara
Narcis Beleuzu
Oana Pop Rus
Makoto Kato
Tim Nguyen
Hiroyuki Ikezoe
Brian Grinstead
Emma Malysz
Gurzau Raul
Imanol Fernandez
Dylan Roeh
Noemi Erli
Eugen Sawin
Andreea Pavel
Csoregi Natalia
Neil Deakin
Eitan Isaacson
Randall E. Barker
arthur.iakab
Valentin Gosu
Paul Zuehlcke
Coroiu Cristina