This patch removes the wait button on the slow script warning, on the suspicion
that it is confusing to the user since it's redundant with the close button. It
also changes the text of the notification to blame the hanging tab.
Differential Revision: https://phabricator.services.mozilla.com/D106015
This patch removes the wait button on the slow script warning, on the suspicion
that it is confusing to the user since it's redundant with the close button. It
also changes the text of the notification to blame the hanging tab.
Differential Revision: https://phabricator.services.mozilla.com/D106015
This patch removes the wait button on the slow script warning, on the suspicion
that it is confusing to the user since it's redundant with the close button. It
also changes the text of the notification to blame the hanging tab.
Differential Revision: https://phabricator.services.mozilla.com/D106015
The telemetry is triggered either when the user is shown the tab crashed page, or when the subframe notification is displayed and the crash occurs in an active tab, or when the user switches to a tab that has a subframe crash notification displayed. The telemetry only applies the first time the tab is switched to. The unsubmitted crashes notification bar appears after 10 minutes or so and is shown in the top-most browser window, if one exists, and telemetry applies once when this occurs.
Differential Revision: https://phabricator.services.mozilla.com/D100349
The urls where an OpenSearch engine can be loaded from are already limited in LinkHandlerChild. This is cleaning up and simplifying what the OpenSearchEngine allows, and as a result allows the load path handling to be greatly simplified.
The test changes are due to no longer allowing chrome or file protocols. For future, we probably want to move away from OpenSearch for most of these, but the changes will make it easier to find the places to update.
Differential Revision: https://phabricator.services.mozilla.com/D104010
Introduce a new `browser.urlbar.showSearchSuggestionsFirst` boolean pref that
determines whether search suggestions are shown before general results.
This keeps the `matchBuckets` pref. I could have removed it since the only thing
we're using it for right now is to tell whether suggestions are shown first. The
reason I didn't remove it is because ultimately we do want a `matchBuckets` or
`resultBuckets` pref so we can experiment with different results compositions
using simple pref-flip studies. Hopefully bug 1676469 will land soon and we'll
replace `matchBuckets` with `resultBuckets`, but in the meantime I think we
should keep `matchBuckets` around.
This also removes some `browser.urlbar.matchBuckets` assignments in tests that
don't actually depend on it. For tests that do depend on it, I changed them so
they set `showSearchSuggestionsFirst` now.
Differential Revision: https://phabricator.services.mozilla.com/D103137
This is a minimal set of changes to allow us to run the weather experiment. By splitting campaign IDs from the attributionURL pref, the weather extension can read the attributionURL pref and append its own CID. I didn't make any changes to the design of search engines or top sites; we met today and decided those needed more careful consideration before we make major changes to PartnerLinkAttribution.
Differential Revision: https://phabricator.services.mozilla.com/D100055
This is a minimal set of changes to allow us to run the weather experiment. By splitting campaign IDs from the attributionURL pref, the weather extension can read the attributionURL pref and append its own CID. I didn't make any changes to the design of search engines or top sites; we met today and decided those needed more careful consideration before we make major changes to PartnerLinkAttribution.
Differential Revision: https://phabricator.services.mozilla.com/D100055
buttonCount has a different value depending on whether or not the build is MOZ_DEV_EDITION or
not, since we show an extra Debug button for script hangs in Developer Edition.
We do not show that extra button for plugin hangs, regardless of the build type, so we
shouldn't use buttonCount here.
Differential Revision: https://phabricator.services.mozilla.com/D98793
* Add prefs for each local search shortcut
* Remove the `update2.localOneOffs` pref since it's not necessary with the three
new prefs
* Modify preferences UI by adding a new row in the engines tree for each local
shortcut
* Add `UrlbarUtils.LOCAL_SEARCH_MODES` so we have a single place where local
search modes and their properties are defined
* Add a new test file for the preferences UI
* Modify browser_oneOffs.js to test the three new preferences
Differential Revision: https://phabricator.services.mozilla.com/D97376
This method only is async in order to allow callers to wait for a process switch
triggered by the call to `loadURI` to be finished before resolving. With
DocumentChannel, we should never trigger a process switch eagerly like this
again, so we don't need any of the async behaviour here anymore.
This part is largely mechanical changes to tests, removing the `await` calls on
`loadURI`, and a follow-up part will remove the actual async logic from
`BrowserTestUtils.loadURI`.
Differential Revision: https://phabricator.services.mozilla.com/D94641
This method only is async in order to allow callers to wait for a process switch
triggered by the call to `loadURI` to be finished before resolving. With
DocumentChannel, we should never trigger a process switch eagerly like this
again, so we don't need any of the async behaviour here anymore.
This part is largely mechanical changes to tests, removing the `await` calls on
`loadURI`, and a follow-up part will remove the actual async logic from
`BrowserTestUtils.loadURI`.
Differential Revision: https://phabricator.services.mozilla.com/D94641
This converts FX_URLBAR_SELECTED_RESULT_TYPE_2, FX_URLBAR_SELECTED_RESULT_INDEX
and the correlation between them FX_URLBAR_SELECTED_RESULT_INDEX_BY_TYPE_2 to
keyed scalars, that are nicer to use and analyze.
They are converted to one keyed scalar per result type, tracking the number
of times that type was picked per urlbar index.
The sums (count per type or per index) can still be derived from this structure.
Differential Revision: https://phabricator.services.mozilla.com/D94498
This adds the ability to force the bookmarks toolbar to appear on all pages. The checkbox in the toolbar context menu will reflect if the toolbar will appear outside of the newtab page. The toolbar will always appear on the newtab page. Profiles that already had the toolbar showing will have a migration to keep their experience unchanged.
Differential Revision: https://phabricator.services.mozilla.com/D89222
This adds the ability to force the bookmarks toolbar to appear on all pages. The checkbox in the toolbar context menu will reflect if the toolbar will appear outside of the newtab page. The toolbar will always appear on the newtab page. Profiles that already had the toolbar showing will have a migration to keep their experience unchanged.
Differential Revision: https://phabricator.services.mozilla.com/D89222
This adds the ability to force the bookmarks toolbar to appear on all pages. The checkbox in the toolbar context menu will reflect if the toolbar will appear outside of the newtab page. The toolbar will always appear on the newtab page. Profiles that already had the toolbar showing will have a migration to keep their experience unchanged.
Differential Revision: https://phabricator.services.mozilla.com/D89222
This adds tab-to-search telemetry, both for the new tabtosearch search mode entry point and for tabtosearch results in our usual Urlbar result-selection scalars. I also added a subtest in browser_urlbar_event_telemetry, but realized as I was writing it that it was not useful. We don't consider entering search more as the end of an engagement, so tab-to-search results will not appear in event telemetry. We already considered this in bug 1654680 and resolved it by adding detailed urlbar.searchmode.* scalars, so I don't consider it a blocker. I left the new subtest in since it was mostly done anyways and it can't hurt.
Differential Revision: https://phabricator.services.mozilla.com/D91469
This patch calls setSearchMode directly from search(). This sets up a solution for the problem in the bug and also fixes the issue where a call to search() with a restriction token would flicker the token before it was replaced with the search mode indicator. I added new tabmenu and bookmarkmenu entry points to take advantage of this new functionality.
This also fixes the issues with handoff. Besides the problem of search() recording typed for handoff, `handoff` wasn't even registered as a Telemetry probe! That was my mistake. I added a test for handoff telemetry. It was only practical to test it in PBM since it uses a different implementation than about:home that's easier to test. I wrote a lengthy comment above the subtest about why I think this is okay.
Differential Revision: https://phabricator.services.mozilla.com/D91076
- always show search suggestions first in search mode
- use restyleSearches only in search mode, to get cleaner history results and dedupe against search history
- filter redirects differently depending on restyleSearches
Differential Revision: https://phabricator.services.mozilla.com/D90719
Summary of major changes:
* Bookmarks, history, and tabs restriction chars now enter search mode. I added
a method to UrlbarProviderHeuristicFallback to return a result with a keyword
when one of these is used.
* This fixes other bugs like recognizing aliases that are entered at the
beginning of non-empty search strings, and not quasi-re-entering search mode
when search mode is already entered and you type another alias.
* The heuristic now determines whether we enter search mode, similar to how it
also determines whether we autofill. When the heuristic has a keyword but no
keyword offer, and the keyword is one of the recognized search mode keywords,
then we enter search mode, cancel the current query, and start a new query
with the remainder of the search string after the keyword.
* I slightly changed how we detect an alias, but only when update2 is
enabled. Now, an alias must be followed by a space; otherwise, the alias is
not recognized and instead just remains part of the seach string. Because if
we don't do that, then you end up in a strange situation after typing an alias
but before pressing space: The heuristic says "Search with <engine with the
alias>", but we haven't entered search mode yet because you haven't typed a
space yet. This is true for both @aliaes and non-@aliases.
* A consequence of the previous point is that we can still autofill @aliases
with a trailing space, which IMO is important. Then, once the user types any
char (space or not), we immediately enter search mode with the query being
whatever char they typed. This is less important after bug 1658605 landed, but
it's still good to have.
* Previously, `UrlbarView.onQueryResults` called UrlbarInput in order to
autofill after the first result is received. This is circuitous becaue the
input already has an `onFirstResult` method, which I now use to enter search
mode when appropriate. So I moved the autofill call from UrlbarView to
`UrlbarInput.onFirstResult`.
* As I mentioned, I improved some test framework and simplified some related
product (non-test) code. For example:
* I removed `UrlbarUtils.KEYWORD_OFFER.NONE` in favor of just leaving
`keywordOffer` as `undefined`.
* `tailOffsetIndex` can now be `undefined` if it's not relevant.
* I removed empty-string `icon` properties from payloads in favor of
`undefined`.
* In tests, I ignore `undefined` but present properties in payloads so they
don't count when comparing payloads with `deepEqual`.
* We weren't previously comparing `result.source` and `result.type` in
xpcshell tests, and that's important IMO, so I added checks for those and
updated tests.
* `isSearchHistory` is redundant, so I removed it. For form history, we
should be checking `result.source == HISTORY` and `result.type == SEARCH`.
* A bunch of tests needed to be updated for this new behavior.
Differential Revision: https://phabricator.services.mozilla.com/D87944
Summary of changes:
1. Adds an `entry` property to the searchMode object to tag how search mode was entered.
2. Introduces `urlbar.searchmode.*` scalars. These scalars are suffixed with an entry point into search mode, for example `urlbar.searchmode.oneoff`, or `urlbar.searchmode.topsites_urlbar`. Those entry points tell us how search mode is entered most often. The keys for these scalars are strings describing what kind of search mode was entered. In most cases, this will be the name of a search engine, like "Google", or "DuckDuckGo". It may also be one of "history", "bookmarks", or "tabs". We only collect the names of engines that are bundled with Firefox. If the user enters search mode with an engine they installed themselves, we record "other" as the key.
3. Adds a urlbar-searchmode SAP to SEARCH_COUNTS.
4. Adds a browser.engagement.navigation.urlbar_searchmode probe.
5. Adds a urlbar_searchmode SAP to the navigation.search event.
Differential Revision: https://phabricator.services.mozilla.com/D87510
Whenever a top level document load finishes, if it has been five minutes since
the last time we have done so, we record telemetry about the ratio of unique
site origins loaded to the number of loaded tabs. This telemetry is split
across several different histograms, so that it can be used to approximate a
unique origins vs loaded tab count curve.
Differential Revision: https://phabricator.services.mozilla.com/D85072
This is done because the test always suffers from shutdown leaks after the changes in Bug 1619953, which make the stream acquired during the test asynchronous.
Differential Revision: https://phabricator.services.mozilla.com/D81861
This commit adds a new ecosystem client ID to `ClientID.jsm`. It's
handled the same way as a regular telemetry client ID, in that it's a
random UUID that's persisted to disk, and reset together with the
client ID. Unlike the main client ID, we don't cache it in prefs.
Additionally:
* `setClientID` has been renamed to `setCanaryClientIDs`, and
automatically sets the main and ecosystem client IDs to the canary
(known) ID. It's no longer possible to set either client ID to a
specific value, but only test code did this.
* `resetClientID` has been renamed to `removeClientIDs`, and clears
both client IDs. It no longer returns the new ID; instead, consumers
should call `getClientID` or `getEcosystemClientID` after.
* The ecosystem client ID is included in the `deletion-ping`.
Differential Revision: https://phabricator.services.mozilla.com/D84233
This commit adds a new ecosystem client ID to `ClientID.jsm`. It's
handled the same way as a regular telemetry client ID, in that it's a
random UUID that's persisted to disk, and reset together with the
client ID. Unlike the main client ID, we don't cache it in prefs.
Additionally:
* `setClientID` has been renamed to `setCanaryClientIDs`, and
automatically sets the main and ecosystem client IDs to the canary
(known) ID. It's no longer possible to set either client ID to a
specific value, but only test code did this.
* `resetClientID` has been renamed to `removeClientIDs`, and clears
both client IDs. It no longer returns the new ID; instead, consumers
should call `getClientID` or `getEcosystemClientID` after.
* The ecosystem client ID is included in the `deletion-ping`.
Differential Revision: https://phabricator.services.mozilla.com/D84233
This is done because the test always suffers from shutdown leaks after the changes in Bug 1619953, which make the stream acquired during the test asynchronous.
Differential Revision: https://phabricator.services.mozilla.com/D81861
Also cleans up some test boilerplate:
1. avoid waitForFocus passing in urlbar tests
2. avoid useless window.gSomething
3. avoid useless UrlbarTestUtils imports
Differential Revision: https://phabricator.services.mozilla.com/D80082
It turns out that we sometimes do not get a `OnLocationChange` event from the
BrowserChild when navigating to an `about:blank` document from an initial
`about:blank`. We then would not have the `innerWindowID` set on the
`<xul:browser>`. Now we retrieve the `innerWindowId` from the `<browser>`'s
current window global.
Additionally, we were running into some timeouts due to intermittently not
receiving a `OnStateChange` event for `STATE_STOP`. Because we waiting for this
event, the test would time out sometimes.
Differential Revision: https://phabricator.services.mozilla.com/D79199
Creates a new pref, "...activity-stream.feeds.system.topsites" to control whether TopSitesFeed is enabled. The existing "...activity-stream-feeds.topsites" pref is kept to allow users to downgrade and to ensure that people who disabled Top Sites in the past will continue to not see Top Sites on the New Tab Page -- the difference being that Top Sites will now be generated for those users.
Differential Revision: https://phabricator.services.mozilla.com/D75603
The private search result is shown in Nightly but not otherwise. The test is
failing because it expects the private search result to be at index 1 and the
form history result to be at index 2, but the form history is actually at index 1.
The test just needs to get the right index. There's another part of the test
that clicks a remote suggestion, but it's not affected because the search
happens to match a couple of history results, so the private search result isn't
shown even on Nightly.
Differential Revision: https://phabricator.services.mozilla.com/D76585
Top-level content WindowGlobalParents now keep track of the site origins of the
documents in their document tree. When the WindowGlobalParent is torn down, the
maximum of the number of unique site origins is submitted for telemetry.
Differential Revision: https://phabricator.services.mozilla.com/D71493
CLOSED TREE
Backed out changeset b0ef46ae3853 (bug 1611914)
Backed out changeset f93685e544c5 (bug 1605494)
--HG--
extra : amend_source : 0e196a48b4b196268ddae92af2fa00067bb6dc0b
This was causing subsequent tests to fail when a pref was set via browser.ini.
Differential Revision: https://phabricator.services.mozilla.com/D61750
--HG--
extra : moz-landing-system : lando
This was causing subsequent tests to fail when a pref was set via browser.ini.
Differential Revision: https://phabricator.services.mozilla.com/D61750
--HG--
extra : moz-landing-system : lando
The telemetry session ID annotation is only used to correlate crash pings with
main pings, it does not need to be sent along with crash reports as we have no
use for it there.
Differential Revision: https://phabricator.services.mozilla.com/D65446
--HG--
extra : moz-landing-system : lando
Separators are technically actions, so we should ignore them when deciding whether to open the context menu.
Differential Revision: https://phabricator.services.mozilla.com/D65050
--HG--
extra : moz-landing-system : lando
