Removes NPAPI plugin features from tests outside of dom/plugins. Some tests are updated to avoid NPAPI behavior and others are deleted if they no longer offer anthing useful.
Differential Revision: https://phabricator.services.mozilla.com/D107134
Removes NPAPI plugin features from tests outside of dom/plugins. Some tests are updated to avoid NPAPI behavior and others are deleted if they no longer offer anthing useful.
Differential Revision: https://phabricator.services.mozilla.com/D107134
The widget is only added if screenshots are enabled (similar behavior to the fxa
toolbar button).
Button must take into account onLocationChange due to the fact that screenshots
extension is not available on about pages.
Adds a test for the disabled state, with more screenshot tests intended in the future
Differential Revision: https://phabricator.services.mozilla.com/D107727
The IDs of actions pinned to the urlbar are kept in
`PageActions._persistedActions.idsInUrlbar`. To pin all actions to the urlbar,
theoretically all we need to do is add all action IDs to this array, and things
should just work. PageActions already has a migration mechanism that could check
if Proton is enabled and add all the action IDs if it is. However, that would
mean that if Proton were subsequently disabled, or if the user downgraded to a
Firefox without Proton, they'd end up with all their actions still in the
urlbar. They could remove them one by one so it's not a big problem, but it
would be annoying.
Instead, this patch keeps two arrays of urlbar IDs. One stashes the user's
original pinned actions and PageActions never touches it as long as Proton is
enabled, and the other is the usual array that happens to have the IDs of all
the actions when Proton is enabled.
Depends on D107763
Differential Revision: https://phabricator.services.mozilla.com/D107600
See bug for more details, but effectively the decision is to show the same
notification which we would normally show for hung pages if an iframe hangs,
but only do so if the user is trying to interact with content hung by that
iframe. This should accomplish that.
Differential Revision: https://phabricator.services.mozilla.com/D107933
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
