This patch re-lands the Delegated Credentials experiment, with an expiration date of 1 May, 2020.
This experiment already ran in Fx 73, but the underlying TLS implementation has been updated and we now plan to enable by default in Nightly. Out of an abundance of caution, the experiment will be repeated for 1-2 weeks to confirm the previous results (i.e., lack of any breakage) before enabling.
See prior bug https://bugzilla.mozilla.org/show_bug.cgi?id=1580053 - only changes to the expiration date and method of loading of the experiment (necessary to rebase) have been made here .
Differential Revision: https://phabricator.services.mozilla.com/D71202
I didn't remove the `allowSearchSuggestions` assignment even though it's not necessary due to the `defaultValue` addition. And I already queued the main patch for landing.
Differential Revision: https://phabricator.services.mozilla.com/D71249
DownloadsSubview and DownloadsView do not inherit from custom elements and cannot rely on the static getFragment method.
The individual download list items all need to be cloned in order to display.
Differential Revision: https://phabricator.services.mozilla.com/D71204
* Add a new `allowSearchSuggestions` property to the query context. It defaults to true.
* `UrlbarInput` sets this property when it starts a query. If the event that started the query is a paste event and the pasted string's length is larger than maxChars, then don't allow suggestions. Otherwise do.
* `UrlbarProviderSearchSuggestions.isActive` returns false when `!context.allowSearchSuggestions`.
* `UrlbarProviderSearchSuggestions` doesn't truncate the query anymore.
* Keep the `browser.urlbar.maxCharsForSearchSuggestions` pref but use it only for pastes, and increase it from 20 to 100. I considered making a new pref but this way if a user changed it, then it still applies to pastes at least. I'm not sure it's important though.
Differential Revision: https://phabricator.services.mozilla.com/D70956
DownloadsSubview and DownloadsView do not inherit from custom elements and cannot rely on the static getFragment method.
The individual download list items all need to be cloned in order to display.
Differential Revision: https://phabricator.services.mozilla.com/D71204
This also fixes a bug where we weren't recording the telemetry probe clicks on breached password learn more links due to the refactoring and renaming of the .alert-link class. A test has been added that would have caught that mistake in automation.
Differential Revision: https://phabricator.services.mozilla.com/D70142
This also fixes a bug where we weren't recording the telemetry probe clicks on breached password learn more links due to the refactoring and renaming of the .alert-link class. A test has been added that would have caught that mistake in automation.
Differential Revision: https://phabricator.services.mozilla.com/D70142
This patch introduces a new tab modal system prompt type. It can be opened via the nsIPromptService
with a destination BrowsingContext. These tab system prompts overlap slightly with the upper
chrome UI to differentiate them from content prompts (previously called tab prompts).
- Extended nsIPromptService and nsIPrompt to accept 3 types of modal prompts:
- Window prompts
- Tab (system) prompts
- Content prompts (the old tab prompts)
- Removed prompt code from Prompter.jsm, always call PromptParent window actor instead
- Added PromptChild window actor to forward pagehide events to parent actor
- Created additional prompt methods in nsIPromptService to prompt by browsingContext and modalType
- Backwards compatibility is maintained, consumers can still open content prompts calling nsIPrompt with a content window
Differential Revision: https://phabricator.services.mozilla.com/D66446
Before 1496578, URIFixup::keywordToURI used to do a synchronous IPC call to be
able to access search engines from the content process. Consumers of URIFixup
didn't care. Bug 1496578 moved the IPC messaging to the callers, in particular
nsDocShell, but assumed nsDocShellLoadState wasn't loading from content.
It looks like in some cases it does, so this adds another sync IPC call for
GetFixupURIInfo.
The total numer of sync IPCs should not change from before Bug 1496578, URIFIxup
was just doing it internally, while now it happens at the call point.
Note the long term plan would be for these docshell objects callers to just
handle URIs, while the UI code should do fixup.
Bug 1375244 tracks the removal of these sync IPC messages.
Differential Revision: https://phabricator.services.mozilla.com/D70607
