This patch adds a new context for the performance-new components. It's
eventually the only place where the settings will live, but for now
the components share the settings between the popup, the devtools panel,
and the about:profiling page.
This page uses the base styling that the preferences page uses. The styles
should obey the theming for the browser, and ignore the devtools theming
colors.
Differential Revision: https://phabricator.services.mozilla.com/D55010
--HG--
extra : moz-landing-system : lando
This commit is fairly trivial, but creates the about:profiler page to
start the new about:profiler work.
Differential Revision: https://phabricator.services.mozilla.com/D53729
--HG--
extra : moz-landing-system : lando
This patch adds a new context for the performance-new components. It's
eventually the only place where the settings will live, but for now
the components share the settings between the popup, the devtools panel,
and the about:profiling page.
This page uses the base styling that the preferences page uses. The styles
should obey the theming for the browser, and ignore the devtools theming
colors.
Differential Revision: https://phabricator.services.mozilla.com/D55010
--HG--
extra : moz-landing-system : lando
This commit is fairly trivial, but creates the about:profiler page to
start the new about:profiler work.
Differential Revision: https://phabricator.services.mozilla.com/D53729
--HG--
extra : moz-landing-system : lando
We might as well do this for now to keep the tests passing when modern config is turned on. It doesn't actually matter what order these particular parameters are listed in.
Differential Revision: https://phabricator.services.mozilla.com/D55641
--HG--
extra : moz-landing-system : lando
Added @rbarker as a reviewer to check if this will work well within GeckoView for FxR / Android.
Added @bzbarsky for test_interfaces.html. -- I'd like to re-land the secure origin requirement for WebVR as part of this patch, as it doesn't help to have UI that can't guarantee the identity of the origin. (This was backed out due to test failures originally, and since been fixed)
Differential Revision: https://phabricator.services.mozilla.com/D45951
--HG--
rename : browser/components/privatebrowsing/test/browser/browser_privatebrowsing_geoprompt.js => browser/components/privatebrowsing/test/browser/browser_privatebrowsing_rememberprompt.js
extra : moz-landing-system : lando
A couple of problems:
* `pickElement` gets the tip's URL (from `UrlbarUtils.getUrlFromResult`). As long as the picked element isn't the help button, we go ahead and use that URL even if the element is not the main button.
* Even after fixing the previous problem, `_on_mousedown` will "select" the tip row itself (not its buttons). If the tip button is already selected (because it's the heuristic for example), the selection goes away at that point.
So we need to ignore tip elements that aren't the buttons.
Differential Revision: https://phabricator.services.mozilla.com/D55758
--HG--
extra : moz-landing-system : lando
Users can opt out of automatic updates. In that case, when an update is available, we need to let the user download and install it and restart the browser. This case isn't covered in the interventions spec, but it's consistent with the intention to give the user a one-click way to continue on their upgrade path, so I think we should handle it.
This patch adds a `browser.experiments.urlbar.installBrowserUpdateAndRestart` function. At first I made it only install the update, and then the extension called our existing `restartBrowser` function once that finished. But it didn't work because `restartBrowser` must be called from a user-input handler, and apparently by awaiting the install function, any code running after the `await` isn't considered to be in the user-input handler.
Differential Revision: https://phabricator.services.mozilla.com/D55608
--HG--
extra : moz-landing-system : lando
Some of these were obvious typos. Others probably reflect once-correct components
that have been combined, split, or otherwise obsoleted; for these I've tried to
use the component associated with the bugs for recent changes to the affected files.
Differential Revision: https://phabricator.services.mozilla.com/D55756
--HG--
extra : moz-landing-system : lando
With DocumentChannel, the 'URI' of the channel that we proxy for RemoteWebProgress doesn't have the resolved URI, and reports the about: version instead.
All about: URIs are local these days, so we can just check for that scheme directly, and simplify the code.
Differential Revision: https://phabricator.services.mozilla.com/D54251
--HG--
extra : moz-landing-system : lando
Instead of trying to prevent the tip buttons from being focused in the first place, we can just listen for focus on the parent tip element and focus the input instead.
Differential Revision: https://phabricator.services.mozilla.com/D55595
--HG--
extra : moz-landing-system : lando
The event bufferer has 2 problems:
1. startDate is initialized to null and then compared to Cu.now(), that generates unexpected results
2. when the initial status is UNKNOWN events should not be deferred (down in a new window for example)
Differential Revision: https://phabricator.services.mozilla.com/D55700
--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
The original fix for Bug 287996 intended to store the url as userTypedValue when
it was confirmed in the UI and about to start loading, but it threw the baby out
with the bathwater. By storing any selection-completed and autofilled value as
userTypedValue, it made impossible to properly return to the typed text.
Currently, if autofill happens, switching back to the tab where it happened
shows the autofilled value instead of what the user typed.
This also makes impossible to reopen the view, because the search string changed.
Because now we properly set userTypedValue in _loadURL, we can remove this old
workaround.
Note though that this breaks selecting a url (without confirmation), switching tab,
then going back to the original tab and expecting the url to be set.
While it's possible to support that case, we think it's more important to go
back to what was typed, and eventually reopen the view. It's also less confusing
for the user, because the shown url has no relation with the currently loaded page.
For similar reasons, blurring the urlbar should restore the user typed value
if we autofilled a value, to avoid overriding the search string with our own.
And because of this, we should not clear the view every time set a value, or we
could clear valid cached results. It's better to do it on an actual input event.
Differential Revision: https://phabricator.services.mozilla.com/D52644
--HG--
extra : moz-landing-system : lando
With DocumentChannel, the 'URI' of the channel that we proxy for RemoteWebProgress doesn't have the resolved URI, and reports the about: version instead.
All about: URIs are local these days, so we can just check for that scheme directly, and simplify the code.
Differential Revision: https://phabricator.services.mozilla.com/D54251
--HG--
extra : moz-landing-system : lando
With DocumentChannel, the 'URI' of the channel that we proxy for RemoteWebProgress doesn't have the resolved URI, and reports the about: version instead.
All about: URIs are local these days, so we can just check for that scheme directly, and simplify the code.
Differential Revision: https://phabricator.services.mozilla.com/D54251
--HG--
extra : moz-landing-system : lando