And cleanup similar code in nsXULTooltipListener. That code shouldn't
need to deal with zoom since the target and the tooltip are in the same
document.
Differential Revision: https://phabricator.services.mozilla.com/D139235
"Send Video to Device" feature is gone in desktop and mobile, and also,
we removed Presentation API implementation, so this is unnecessary now.
Differential Revision: https://phabricator.services.mozilla.com/D132330
This commit does a couple of things:
- move whereToOpenLink and getRootEvent implementations into BrowserUtils,
so they can be used from the child process.
- forward callers in utilityOverlay.js to the BrowserUtils ones
(bug 1742889 will get rid of the forwarding and update all the callers;
we might be able to get this and bug 1739929 into beta if risk is low
enough, and touching a bunch of extra files really doesn't help with
that)
- move the lazy-load of BrowserUtils from browser.js to utilityOverlay.js
This is safe because everywhere that loads browser.js also loads
utilityOverlay.js. It's needed because there are some places that use
utilityOverlay.js but not browser.js, and so now they need access to
BrowserUtils.jsm.
- use whereToOpenLink to determine if we should avoid consuming the transient
user gesture activation in the child click handling code.
- add an automated test based on the testcase in the bug.
When working on this, I initially put the check using whereToOpenLink in
the toplevel of the function, and then when I ran places test to check that
I hadn't broken any places consumers of whereToOpenLink or getRootEvent,
realized that I had broken `browser_markPageAsFollowedLink.js`, because it
relies on "normal" (ie no modifier key, left button) link clicks making it
to ClickHandlerParent.jsm . I filed bug 1742894 about this. I've not tried
to fix that here, instead I've tried to ensure that paths through this
function are as untouched as possible while still fixing bug 1739929 and
bug 1742801.
Differential Revision: https://phabricator.services.mozilla.com/D132102
It might fire before styles are invalidated, so it might cache the wrong
styles.
Instead, fire an event on the window once everything in that window has
been invalidated, not just the global theme.
This is causing failures with the patch in bug 1740089, since after that
patch `browser_ext_browserAction_theme_icons` trigger the theme changes
when switching from dark to default mode or similar.
Differential Revision: https://phabricator.services.mozilla.com/D131396
This does a couple of things:
* Instead of using the `not_now` telemetry event object for the cases where the
dialog is closed by the Escape key or some other atypical way, reserve
`not_now` -- renamed `not_now_link` -- specifically for clicks on the "Not
now" link and add two new objects: `dismissed_escape_key` and
`dismissed_other`. That should give us a little better understanding of how
the dialog is being dismissed. The new `not_now_link` name is to avoid
conflation with the previous meaning of `not_now`.
* Add a new `browser.urlbar.quicksuggest.onboardingDialogChoice` pref that
stores exactly the same values as the telemetry event. e.g., if the dialog is
accepted, then we'll record a telemetry event whose object is `accept` and
we'll also store `accept` in the pref.
I figure if we decide to show the onboarding again for people who have already
seen it, (1) we'll use this pref to decide the flow for any given user, and (2)
we'll need to add another pref for the user's response to the "v2" dialog, or
maybe we could morph this one into an array of responses or something more
complex like that.
Differential Revision: https://phabricator.services.mozilla.com/D127354
This load was causing a process switch after the changes in this patch.
This caused the view-source load to also process-switch back when loaded
and confused some view-source machinery. The load isn't necessary, and
if skipped the process switch due to navigation will not occur.
Differential Revision: https://phabricator.services.mozilla.com/D120736
After the changes in this bug, about:blank loads triggered by chrome will
finish in a "web" content process, as they have an untrusted null principal
without a precursor. In a few places throughout the codebase, however, we
perform about:blank loads with the explicit expectation that they do not change
processes. This new remoteTypeOverride option allows the intended final process
to be explicitly specified in this situation.
For security & simplicity reasons, this new attribute is limited to only be
usable on system-principal triggered loads of about:blank in toplevel browsing
contexts.
Differential Revision: https://phabricator.services.mozilla.com/D120671
The bug was that the tooltip was only being shown for reader-mode-button-icon. The tooltip would show if you hovered right over the icon, and it would be undefined otherwise. This patch shows the tooltip regardless of the hover target. The other items on nodeToTooltipMap and nodeToShortcutMap are toolbarbuttons, so their icons are added in CSS and event handling always sees the parent node as the hover target. The reader mode button icon, however, is an <image> child of its parent. Either it or its parent could be hover targets. I considered added some handling in GetDynamicShortcutTooltipText along the lines of checking node.closest(reader-mode-button). I settled on just adding more entries to nodeToTooltipMap and nodeToShortcutMap since it's safer and easier to uplift.
Differential Revision: https://phabricator.services.mozilla.com/D122126
This load was causing a process switch after the changes in this patch.
This caused the view-source load to also process-switch back when loaded
and confused some view-source machinery. The load isn't necessary, and
if skipped the process switch due to navigation will not occur.
Differential Revision: https://phabricator.services.mozilla.com/D120736
After the changes in this bug, about:blank loads triggered by chrome will
finish in a "web" content process, as they have an untrusted null principal
without a precursor. In a few places throughout the codebase, however, we
perform about:blank loads with the explicit expectation that they do not change
processes. This new remoteTypeOverride option allows the intended final process
to be explicitly specified in this situation.
For security & simplicity reasons, this new attribute is limited to only be
usable on system-principal triggered loads of about:blank in toplevel browsing
contexts.
Differential Revision: https://phabricator.services.mozilla.com/D120671
This load was causing a process switch after the changes in this patch.
This caused the view-source load to also process-switch back when loaded
and confused some view-source machinery. The load isn't necessary, and
if skipped the process switch due to navigation will not occur.
Differential Revision: https://phabricator.services.mozilla.com/D120736
After the changes in this bug, about:blank loads triggered by chrome will
finish in a "web" content process, as they have an untrusted null principal
without a precursor. In a few places throughout the codebase, however, we
perform about:blank loads with the explicit expectation that they do not change
processes. This new remoteTypeOverride option allows the intended final process
to be explicitly specified in this situation.
For security & simplicity reasons, this new attribute is limited to only be
usable on system-principal triggered loads of about:blank in toplevel browsing
contexts.
Differential Revision: https://phabricator.services.mozilla.com/D120671
This load was causing a process switch after the changes in this patch.
This caused the view-source load to also process-switch back when loaded
and confused some view-source machinery. The load isn't necessary, and
if skipped the process switch due to navigation will not occur.
Differential Revision: https://phabricator.services.mozilla.com/D120736
After the changes in this bug, about:blank loads triggered by chrome will
finish in a "web" content process, as they have an untrusted null principal
without a precursor. In a few places throughout the codebase, however, we
perform about:blank loads with the explicit expectation that they do not change
processes. This new remoteTypeOverride option allows the intended final process
to be explicitly specified in this situation.
For security & simplicity reasons, this new attribute is limited to only be
usable on system-principal triggered loads of about:blank in toplevel browsing
contexts.
Differential Revision: https://phabricator.services.mozilla.com/D120671
This load was causing a process switch after the changes in this patch.
This caused the view-source load to also process-switch back when loaded
and confused some view-source machinery. The load isn't necessary, and
if skipped the process switch due to navigation will not occur.
Differential Revision: https://phabricator.services.mozilla.com/D120736
After the changes in this bug, about:blank loads triggered by chrome will
finish in a "web" content process, as they have an untrusted null principal
without a precursor. In a few places throughout the codebase, however, we
perform about:blank loads with the explicit expectation that they do not change
processes. This new remoteTypeOverride option allows the intended final process
to be explicitly specified in this situation.
For security & simplicity reasons, this new attribute is limited to only be
usable on system-principal triggered loads of about:blank in toplevel browsing
contexts.
Differential Revision: https://phabricator.services.mozilla.com/D120671
Depends on D114970
With this change, the title text of the robot icon now reads "Browser is under remote control by { $component }"
With component being one of DevTools, Marionette or RemoteAgent.
Note that if several components are listening at the same time, only the first one we checked is displayed.
Having several remote control tools running at the same time is considered as an edge case here.
The main goal of the feature is to help users identify what triggered remote control in case they are confused by the icon showing up.
Differential Revision: https://phabricator.services.mozilla.com/D115195
Luminance goes from 0 to 255, so using 127 makes sense, and allows all
disabled titlebar colors that I found in various GTK themes to still be
considered dark enough (for those, 110 was too low).
Differential Revision: https://phabricator.services.mozilla.com/D114876
I noticed while testing the previous patch on various gtk themes that
the cache wasn't cleared / sytem colors weren't recomputed properly when
the native theme changes. This trivial patch fixes it.
Differential Revision: https://phabricator.services.mozilla.com/D114879
Mixing the XUL and CSS box models is always a source of interesting glitches like
the one that this patch tries to fix. The animation for closing a Proton-y infobar
involves setting a negative margin on an element using CSS box, which has a parent
and siblings that are using XUL box.
Interestingly, it seems that only the high priority notification box hits this issue,
as the per-tab notification box is contained within a <named-deck>, which uses CSS
box - this observation was what led me to the solution in this patch: when constructing
the high priority notification box, we now place it inside of a <div>, which uses
CSS box, which allows us to sidestep this glitch.
The irony of fixing this CSS vs XUL box glitch by adding another CSS box amongst a
bunch of XUL boxes is not lost on me.
Differential Revision: https://phabricator.services.mozilla.com/D114552
There are a few disparate changes in this commit that combine to fix the bug.
In no particular order:
- set a min-height on windows with toolbars. This extends the minimum
content size from toolbarless windows to ones with toolbars, on the
assumption that the overhead from the toolbar and tabs is always
going to be at least 25px, even in compact mode (it's significantly
more at the moment). This is also conveniently *just* enough for
dialogs with a title, body and checkbox, at the default OS font size,
to be usable (though the bottom can still get a little cut-off).
- stop assuming there's 30px frame overhead on top of the size of the
browser in which the dialog is displayed in SubDialog.jsm. This is
perhaps true in prefs where we display a titlebar outside of the
browser, but we don't do this for content/tab/window-modal dialogs
shown in browser.xhtml so the code shouldn't assume. Without this,
when the window starts off not being tall enough to fit, we were
losing an additional 30px for no reason.
- instead of subtracting the 1em padding on the <dialog> that the
default styling provides (https://searchfox.org/mozilla-central/rev/2f109387cc6886859d3f985ed9aca352fff653b8/layout/style/res/html.css#815 ) just reset it to 0 and stop subtracting it.
- remove the CSS rule for tab and window-modal dialogs that depends on
`--doc-height-px`. It is never set, because it is only set for the
`limitheight` sizeto value in SubDialog.jsm, and the only
consumer that sets that is at
https://searchfox.org/mozilla-central/rev/2f109387cc6886859d3f985ed9aca352fff653b8/browser/base/content/browser.js#8988
for content dialogs.
- set the margin-top for the window-modal-dialog element from CSS
instead of from the gDialogBox code in browser.css (now without the 1em
subtraction, see above).
- expose the height of the dialog to the parent of the dialog overlay
from SubDialog.jsm as --inner-height
- use CSS to ensure the dialog is off-set to be just below chrome
when its size allows this, and otherwise move it up until it
fits. There's a code comment explaining this.
Differential Revision: https://phabricator.services.mozilla.com/D114292
There are a few disparate changes in this commit that combine to fix the bug.
In no particular order:
- set a min-height on windows with toolbars. This extends the minimum
content size from toolbarless windows to ones with toolbars, on the
assumption that the overhead from the toolbar and tabs is always
going to be at least 25px, even in compact mode (it's significantly
more at the moment). This is also conveniently *just* enough for
dialogs with a title, body and checkbox, at the default OS font size,
to be usable (though the bottom can still get a little cut-off).
- stop assuming there's 30px frame overhead on top of the size of the
browser in which the dialog is displayed in SubDialog.jsm. This is
perhaps true in prefs where we display a titlebar outside of the
browser, but we don't do this for content/tab/window-modal dialogs
shown in browser.xhtml so the code shouldn't assume. Without this,
when the window starts off not being tall enough to fit, we were
losing an additional 30px for no reason.
- instead of subtracting the 1em padding on the <dialog> that the
default styling provides (https://searchfox.org/mozilla-central/rev/2f109387cc6886859d3f985ed9aca352fff653b8/layout/style/res/html.css#815 ) just reset it to 0 and stop subtracting it.
- remove the CSS rule for tab and window-modal dialogs that depends on
`--doc-height-px`. It is never set, because it is only set for the
`limitheight` sizeto value in SubDialog.jsm, and the only
consumer that sets that is at
https://searchfox.org/mozilla-central/rev/2f109387cc6886859d3f985ed9aca352fff653b8/browser/base/content/browser.js#8988
for content dialogs.
- set the margin-top for the window-modal-dialog element from CSS
instead of from the gDialogBox code in browser.css (now without the 1em
subtraction, see above).
- expose the height of the dialog to the parent of the dialog overlay
from SubDialog.jsm as --inner-height
- use CSS to ensure the dialog is off-set to be just below chrome
when its size allows this, and otherwise move it up until it
fits. There's a code comment explaining this.
Differential Revision: https://phabricator.services.mozilla.com/D114292
Now that I finally wrote a test, I also noticed that we were trying to write the
checkbox permission value when the dialog gets aborted (ie removed because the
page disappears due to another page loading or the tab/window being closed),
which then threw an exception because the event target is the window rather than
the dialog element, and dialog.querySelector in maybeSetAllowTabSwitchPermission
fails.
Differential Revision: https://phabricator.services.mozilla.com/D114023
