I'm not sure what information would be useful in other OSes, so ifdef
the row for GTK for now, but I made this trivial to show in Windows /
macOS / Android as soon as they return useful information.
Differential Revision: https://phabricator.services.mozilla.com/D120331
This avoids starting autoscroll on SVG links, and on HTML links that
contain SVG, by sharing the code that browser's ClickHandlerChild uses
to detect links into BrowserUtils, and using that from AutoScrollChild
to determine if the click happened on top of a link. It also adds a
test so we avoid regressing this in future.
When running the test, I noticed an error from ClickHandlerParent
when the browser for which we receive a click has gone away, and
fixed it by adding a nullcheck and early return.
Differential Revision: https://phabricator.services.mozilla.com/D120024
This avoids starting autoscroll on SVG links, and on HTML links that
contain SVG, by sharing the code that browser's ClickHandlerChild uses
to detect links into BrowserUtils, and using that from AutoScrollChild
to determine if the click happened on top of a link. It also adds a
test so we avoid regressing this in future.
When running the test, I noticed an error from ClickHandlerParent
when the browser for which we receive a click has gone away, and
fixed it by adding a nullcheck and early return.
Differential Revision: https://phabricator.services.mozilla.com/D120024
Now that the about:third-party page landed (bug 1695817), we can remove the predecessor.
This patch reverts the Part10 patch of bug 1669036 (d9f8cdf2877b), keeping the other patches
which are required for about:third-party page.
Differential Revision: https://phabricator.services.mozilla.com/D118382
Not setting mIsSrcdocEntry causes us to drop srcdoc data and not set
INTERNAL_LOAD_FLAGS_IS_SRCDOC in FillLoadInfo for srcdoc restores.
Differential Revision: https://phabricator.services.mozilla.com/D117479
It isn't immediately obvious that the hardcoded 30 pixel value this patch
replaces was meant to represent strictly the height of the dialog's title bar
(including border), but I do believe that is how it was intended, based on
these two things:
1) Using 0 instead of 30 when no titlebar is present at least appears to be the
correct behavior, or if nothing else it's a reasonable enough behavior that
it prevents anything looking broken.
2) 30 pixels is the exact height of the titlebar including border as it
actually appeared on in-content preferences dialog boxes at the time the
hardcoded value was originally introduced here in bug 1128237.
So, based on that, it looks like what's needed here is a value that is zero
when no titlebar exists, or if there is one, then its computed height including
border. As it turns out, we were already computing exactly that value for
another purpose, so this patch simply plugs that in here in place of the
hardcoded constant.
Differential Revision: https://phabricator.services.mozilla.com/D117374
Right now, we limit the type of a username field in username-only forms to be either text or email.
This is different from what the password manager currently support in LoginHelper.isUsernameFieldType.
This is because text and email type are the most common cases for a username field, and we want to focus
on the cases that are more likely a username field.
This patch adds "DOMFormHasPossibleUsername" event to notify the password manager when a form has a possible
username field (text or email). The event works similar to the existing "DOMFormHasPassword" event.
Depends on D113797
Differential Revision: https://phabricator.services.mozilla.com/D113798
- Move the decision logic for Win32k Lockdown to a common area where it can
be re-used
- Cache the Win32k Lockdown state, since the result will never change
- Add IDL to allow JavaScript to query it
- Add it to the "about:support" page
- Add an annotation to Crash Reporter after the first time it's read
Differential Revision: https://phabricator.services.mozilla.com/D114850
- Move the decision logic for Win32k Lockdown to a common area where it can
be re-used
- Cache the Win32k Lockdown state, since the result will never change
- Add IDL to allow JavaScript to query it
- Add it to the "about:support" page
- Add an annotation to Crash Reporter after the first time it's read
Differential Revision: https://phabricator.services.mozilla.com/D114850
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
This is based on feedback from Ed in https://phabricator.services.mozilla.com/D114292#3711919,
> One case that does behave inconsistently is that edit bookmark can become tall with tags open and directly updates the browser height
Indeed, moving this to use 'resizeBy', and setting the --inner-height property
that is used by the previous commit (D114292) to position window-modal dialogs
when we lack vertical space, elegantly solves this issue.
Differential Revision: https://phabricator.services.mozilla.com/D114480
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
This is based on feedback from Ed in https://phabricator.services.mozilla.com/D114292#3711919,
> One case that does behave inconsistently is that edit bookmark can become tall with tags open and directly updates the browser height
Indeed, moving this to use 'resizeBy', and setting the --inner-height property
that is used by the previous commit (D114292) to position window-modal dialogs
when we lack vertical space, elegantly solves this issue.
Differential Revision: https://phabricator.services.mozilla.com/D114480
Mike Kaply
Emilio Cobos Álvarez
Gijs Kruitbosch
Iulian Moraru
Harry Twyford
Sandor Molnar
Nika Layzell
Toshihito Kikuchi
Tarik Eshaq
Andrew Osmond
Henri Sivonen
Dorel Luca
Brindusan Cristian
Mark Banner
Anny Gakhokidze
Kashav Madan
Andrew Halberstadt
Ed Lee
Molly Howell
Luca Greco
Dimi Lee
Alexandru Michis
Csoregi Natalia
Christoph Kerschbaumer
Henrik Skupin
Chris Martin
Danilo Bargen
Andrei Oprea