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
