This telemetry records, for each toplevel window, the relationship between the
actual fission-enabled status of the window, and the "fission.autostart" pref.
This takes the form of a categorized telemetry histogram with the following
keys:
* EnabledByAutostart: useRemoteSubframes == true fission.autostart == true
* EnabledByUser: useRemoteSubframes == true fission.autostart == false
* DisabledByAutostart: useRemoteSubframes == false fission.autostart == false
* DisabledByUser: useRemoteSubframes == false fission.autostart == true
'DisabledByUser' helps indicate useful information such as how often fission
testers need to open non-fission windows due to breakage, while
'EnabledByAutostart' and 'EnabledByUser' helps give a better image of how many
people are testing fission.
Differential Revision: https://phabricator.services.mozilla.com/D61927
--HG--
extra : moz-landing-system : lando
Added right click on new tab button to open containers menu.
Removed long press and added option to enable left click in preferences menu.
Renamed privacy.userContext.longPressBehavior to privacy.userContext.newTabContainer.enabled
Differential Revision: https://phabricator.services.mozilla.com/D58410
--HG--
extra : moz-landing-system : lando
This patch was started by Alex Vamvounis <a.vamvounis@gmail.com> and finished by
Mike Conley <mconley@mozilla.com>
Differential Revision: https://phabricator.services.mozilla.com/D53075
--HG--
extra : moz-landing-system : lando
focusAndSelectUrlbar can fire after isCustomizing() is false but before customizeMode is fully exited. This means the Urlbar is refocused but then quickly loses focus after the main browser window is focused. By adding this additional check we can be sure that the browser focus event occurs before the Urlbar is refocused.
Differential Revision: https://phabricator.services.mozilla.com/D59715
--HG--
extra : moz-landing-system : lando
Top Sites must be disabled for this to work correctly. This is because we haven't defined the behaviour for when two restricting providers are active. Bug 1607797 must be resolved before this is preffed on.
Differential Revision: https://phabricator.services.mozilla.com/D59351
--HG--
extra : moz-landing-system : lando
ContentBlockingEvents is now accessed via WindowGlobalActor::ContentBlockingEvents.
Updating and storing contentBlockingEvent in RemoteSecurityUI are no longer needed.
Depends on D55622
Differential Revision: https://phabricator.services.mozilla.com/D55623
--HG--
extra : moz-landing-system : lando
ContentBlockingEvent in RemoteSecurityUI is updated after receiving a notification from a child process.
Since contentBlockingEvent will be removed from the child, this patch removes the use of
contentBlockingEvent in RemoteSecurityUI and uses the API defined in WindowGlobalActor.
Depends on D55621
Differential Revision: https://phabricator.services.mozilla.com/D55622
--HG--
extra : moz-landing-system : lando
These events were sent excessively on onStateChange. This patch makes it so that:
- we only listen to top-level document changes (we used to send all events from iframes)
- we don't send events unless there's tracking content on the page
- we only send a single event on tab switch instead of multiple
Differential Revision: https://phabricator.services.mozilla.com/D57006
--HG--
extra : moz-landing-system : lando
If the user types a full url, confirms it, and then focuses the urlbar, we should
not
When focusing the address bar after typing and confirming a page, we end up reopening
the view because the search string is the same. This causes unexpected noise and
selection problems (the url is not selected anymore).
This patch changes the behavior so we don't reopen on valid pageproxystate, that
seems to make sense considering the feature scope of restoring an abandoned search.
Additionally, make the keyboard shortcut not trying to reopen the view if it's
already open, to avoid messing up with the selection.
Finally, restore the appropriate allowAutofill status from the last context.
This may still cause us to not autofill something that was previously autofilled,
if 2 tabs contain the same exact search, but that's an edge case, so acceptable.
Differential Revision: https://phabricator.services.mozilla.com/D56635
--HG--
extra : moz-landing-system : lando
Rather than clearing results on tab switch or deactivate, let's keep them, and
clean them on input change. On reopening the view run the query again, so results
are up to date and autofill works, but flickering is reduced.
Differential Revision: https://phabricator.services.mozilla.com/D52645
--HG--
extra : moz-landing-system : lando
Rather than clearing results on tab switch or deactivate, let's keep them, and
clean them on input change. On reopening the view run the query again, so results
are up to date and autofill works, but flickering is reduced.
Differential Revision: https://phabricator.services.mozilla.com/D52645
--HG--
extra : moz-landing-system : lando
These menu items are only visible in Nightly when Fission is enabled,
and they're only for testing, which is why I've opted to not use Fluent
for localization, and just hard-coded the strings and accesskeys. These
menu items will never ride to release.
Differential Revision: https://phabricator.services.mozilla.com/D55004
--HG--
extra : moz-landing-system : lando
We want to display a visual hint to the user that the browser session
is under control by a browser-external client when the remote agent
is listening. The hint is the same as for when Marionette is active.
Differential Revision: https://phabricator.services.mozilla.com/D54270
--HG--
extra : moz-landing-system : lando
This changes the event Marionette emits when it is running from
"remote-active" to "remote-listening".
The background for this change is that the forthcoming Chromium-based
remote protocol uses the same observer notification to indicate
when it listens for browser-external connections. This means that
with this change, the visual hint presented to the user will also
be applied when the remote agent starts its HTTPD listener.
Unlike Marionette however, the remote debugging protocol may be used
for browser-internal applications and it is not appropriate to signal
that the browser is under remote control under those circumstances,
hence the naming change away from "active".
Differential Revision: https://phabricator.services.mozilla.com/D54269
--HG--
extra : moz-landing-system : lando
