We need one more panel in the doorhanger- one that is a user information panel per (rp, idp, account) tuple.
This just gives the privacy policy and ToS links to the user. It is implemented similarly to the other panels,
and would similarly be updated by Bug 1800695.
Similar to the original doorhanger patch (Bug 1782088 - Create account chooser doorhanger for IdentityCredential)
tests and fine polish are out of scope for this prototype.
Differential Revision: https://phabricator.services.mozilla.com/D162126
Implementations of nsIEmbeddingSiteWindow and nsIBaseWindow largely
overlap, and where they don't, the nsIEmbeddingSiteWindow implementation
of the otherwise shared interface is primarily stubbed out with the
exception of Get/SetDimensions().
This patch moves a reimplementation of Get/SetDimensions() from
nsIEmbeddingSiteWindow to nsIBaseWindow. The other methods of
nsIEmbeddingSiteWindow remain covered by nsIBaseWindow.
Get/SetDimensions() can be implemented as part of nsIWebBrowserChrome
where nsIBaseWindow is not necessary. This removes the need for
nsIEmbeddingSiteWindow.
Blur() has also been moved to nsIWebBrowserChrome, as only
nsContentTreeOwner has an actual implementation which we in theory also
want to call from BrowserChild/Parent, but the spec suggests to
"selectively or uniformly ignore calls".
GetVisibility() had an implementation in BrowserChild that pretended to
always be visible. Instead of providing an interface for that,
nsDocShell now handles the not implemented case for tree owners.
nsIEmbeddingSiteWindow::GetSiteWindow() used to call through to
nsIBaseWindow::GetParentNativeWindow().
The Get/SetDimensions() implementation has been replaced with a strongly
typed setter, which is now also used directly from nsGlobalWindowOuter
to avoid problems that come with autodetecting unchanged dimensions,
when the current dimensions are outdated (e.g. immediately reverting a
change can be ignored).
Differential Revision: https://phabricator.services.mozilla.com/D160260
Done:
- Provide the [ARIA Date picker dialog](https://www.w3.org/TR/wai-aria-practices/examples/dialog-modal/datepicker-dialog.html) keyboard navigation pattern
- Manage tab order of a daysView to prevent keyboard trap within a datepicker dialog
- Update default behavior on Datepicker's `this._closePopup()` method
- Spinner styling updated to provide appropriate focus indication when navigating with a keyboard
- Added functional and markup tests to ensure keyboard navigation is supported as expected, split existent datepicker tests to avoid test timeouts and provide better grouping and readability
Depends on D141175
Differential Revision: https://phabricator.services.mozilla.com/D142743
Done:
- Provide the [ARIA Date picker dialog](https://www.w3.org/TR/wai-aria-practices/examples/dialog-modal/datepicker-dialog.html) keyboard navigation pattern
- Manage tab order of a daysView to prevent keyboard trap within a datepicker dialog
- Update default behavior on Datepicker's `this._closePopup()` method
- Spinner styling updated to provide appropriate focus indication when navigating with a keyboard
- Added functional and markup tests to ensure keyboard navigation is supported as expected, split existent datepicker tests to avoid test timeouts and provide better grouping and readability
Depends on D141175
Differential Revision: https://phabricator.services.mozilla.com/D142743
This patch replaces the previous ContractID-based lookup system for protocol
handlers, and replaces it with a new custom system in nsIOService. It will be
pre-populated with non-overridable static protocol handlers using the
StaticComponents infrastructure added in the previous part, and callers can
also dynamically register new protocol handlers at runtime.
This new system is intended to provide access to the default port and
non-dynamic protocol flags off-main-thread, by requiring these values to be
provided up-front as constants, rather than getting them from the xpcom
interface. The data is then guarded by an RWLock.
Callers which look up specific handlers by their contractID are not changed, as
the contract IDs for existing handlers have not been changed, so the lookup
will still succeed.
This change as-implemented breaks the nsGIOProtocolHandler on Linux, as it
removes the special code which would try to use that handler for some
protocols. This will be fixed in a later part by making the
nsGIOProtocolHandler use the dynamic registration APIs to register and
un-register protocol handlers at runtime in response to the GIO pref.
Differential Revision: https://phabricator.services.mozilla.com/D162804
We need one more panel in the doorhanger- one that is a user information panel per (rp, idp, account) tuple.
This just gives the privacy policy and ToS links to the user. It is implemented similarly to the other panels,
and would similarly be updated by Bug 1800695.
Similar to the original doorhanger patch (Bug 1782088 - Create account chooser doorhanger for IdentityCredential)
tests and fine polish are out of scope for this prototype.
Differential Revision: https://phabricator.services.mozilla.com/D162126
Implementations of nsIEmbeddingSiteWindow and nsIBaseWindow largely
overlap, and where they don't, the nsIEmbeddingSiteWindow implementation
of the otherwise shared interface is primarily stubbed out with the
exception of Get/SetDimensions().
This patch moves a reimplementation of Get/SetDimensions() from
nsIEmbeddingSiteWindow to nsIBaseWindow. The other methods of
nsIEmbeddingSiteWindow remain covered by nsIBaseWindow.
Get/SetDimensions() can be implemented as part of nsIWebBrowserChrome
where nsIBaseWindow is not necessary. This removes the need for
nsIEmbeddingSiteWindow.
Blur() has also been moved to nsIWebBrowserChrome, as only
nsContentTreeOwner has an actual implementation which we in theory also
want to call from BrowserChild/Parent, but the spec suggests to
"selectively or uniformly ignore calls".
GetVisibility() had an implementation in BrowserChild that pretended to
always be visible. Instead of providing an interface for that,
nsDocShell now handles the not implemented case for tree owners.
nsIEmbeddingSiteWindow::GetSiteWindow() used to call through to
nsIBaseWindow::GetParentNativeWindow().
The Get/SetDimensions() implementation has been replaced with a strongly
typed setter, which is now also used directly from nsGlobalWindowOuter
to avoid problems that come with autodetecting unchanged dimensions,
when the current dimensions are outdated (e.g. immediately reverting a
change can be ignored).
Differential Revision: https://phabricator.services.mozilla.com/D160260
This patch replaces the previous ContractID-based lookup system for protocol
handlers, and replaces it with a new custom system in nsIOService. It will be
pre-populated with non-overridable static protocol handlers using the
StaticComponents infrastructure added in the previous part, and callers can
also dynamically register new protocol handlers at runtime.
This new system is intended to provide access to the default port and
non-dynamic protocol flags off-main-thread, by requiring these values to be
provided up-front as constants, rather than getting them from the xpcom
interface. The data is then guarded by an RWLock.
Callers which look up specific handlers by their contractID are not changed, as
the contract IDs for existing handlers have not been changed, so the lookup
will still succeed.
This change as-implemented breaks the nsGIOProtocolHandler on Linux, as it
removes the special code which would try to use that handler for some
protocols. This will be fixed in a later part by making the
nsGIOProtocolHandler use the dynamic registration APIs to register and
un-register protocol handlers at runtime in response to the GIO pref.
Differential Revision: https://phabricator.services.mozilla.com/D162804
We need one more panel in the doorhanger- one that is a user information panel per (rp, idp, account) tuple.
This just gives the privacy policy and ToS links to the user. It is implemented similarly to the other panels,
and would similarly be updated by Bug 1800695.
Similar to the original doorhanger patch (Bug 1782088 - Create account chooser doorhanger for IdentityCredential)
tests and fine polish are out of scope for this prototype.
Differential Revision: https://phabricator.services.mozilla.com/D162126
Propagate the ability to pass triggeringRemoteType through the desktop frontend
in various places, such that it is set when using the context menu or content
click handler.
Differential Revision: https://phabricator.services.mozilla.com/D161834
This is a completely redesign based on mconley's idea to use `deck`.
That removes a lot of code and makes things a lot better.
Depends on D163077
Differential Revision: https://phabricator.services.mozilla.com/D162390
It looks like this used to be possible by chance when we didn't check
the event in `togglePanel()`. Now that we do this (to prevent
context-click to open the panel for example), we need to check the event
type and which button or key is clicked/pressed.
Differential Revision: https://phabricator.services.mozilla.com/D163076
This makes alert take the same area as the status panel, partially
backing out the regressing bug.
.browserStack is also relatively-positioned, so this works too. I think
I didn't realize this while writing bug 1791972 because the rule was in
a UA sheet (all <stack>s are relatively positioned, apparently).
This restores the behavior when devtools is toggled vertically. On
responsive mode this still covers the top toolbar, but that was the
pre-existing behavior. Could be fixed in a follow-up with some z-index
tweaking...
Differential Revision: https://phabricator.services.mozilla.com/D162739
It doesn't do much now that we're not using XUL layout, and it's
unnecessary because the tab throbber animation uses CSS transforms
nowadays anyways.
Depends on D162850
Differential Revision: https://phabricator.services.mozilla.com/D162851
This fixes the snap layouts feature on Windows 11.
Instead of using a content attribute (which is somewhat expensive to
look up) use the default appearance and do this where we deal with other
appearance hacks (before building themed backgrounds).
Consolidate this inside a DealWithWindowsAppearanceHacks function along
with the glass stuff.
Differential Revision: https://phabricator.services.mozilla.com/D162757
