Make it a bit easier to read and less prone to race conditions. Remove a
setTimeout referencing bug 103197 which I'm pretty sure it's not an
issue.
Differential Revision: https://phabricator.services.mozilla.com/D156543
Make it a bit easier to read and less prone to race conditions. Remove a
setTimeout referencing bug 103197 which I'm pretty sure it's not an
issue.
Differential Revision: https://phabricator.services.mozilla.com/D156543
Most of the display: block stuff isn't needed anymore because we changed
the blockification behavior in bug 1789123.
.tab-stack, and stacks in general now uses CSS grid so doesn't need that
anymore.
DevTools is the only consumer of <xul:iframe> and width/height was
getting ignored in XUL because flexibility takes precedence, so just
remove the relevant declarations.
Differential Revision: https://phabricator.services.mozilla.com/D157070
I haven't spotted any UI regression from this, and this should generally
make the XUL -> modern flex transition easier, and simplify some
of the relevant code.
This does fix a few layout issues with emulated flexbox.
For the most part, this shouldn't change behavior without that. This
changes behavior if you have mixed inline/non-inline content in the same
XUL box (before they'd get a single item, now you'd get the flexbox /
grid behavior of one item per inline run), and multiple inline-elements
(which would become their own flex items). But I pushed a patch with
some asserts and they didn't fire on our browser mochitests, so I think
we're good.
The UA rule refactoring (removing the inherit from xul anon blocks)
shouldn't matter in practice, since we only have one item (so
box-ordinal is irrelevant) and they have overflow: visible (so
text-overflow and overflow-clip-box shouldn't have an effect).
Differential Revision: https://phabricator.services.mozilla.com/D156375
When these panels had arrows, I guess the bottomcenter topleft alignment
made sense so that you could precisely align the arrow, but that's not
what we do now.
Don't use bottomcenter / leftcenter / rightcenter, since we really want
the sides to align.
This shouldn't change behavior on any platform except Linux + Wayland,
where the alignment looks good now in the case of bug 1784876.
Differential Revision: https://phabricator.services.mozilla.com/D156099
When these panels had arrows, I guess the bottomcenter topleft alignment
made sense so that you could precisely align the arrow, but that's not
what we do now.
Don't use bottomcenter / leftcenter / rightcenter, since we really want
the sides to align.
This shouldn't change behavior on any platform except Linux + Wayland,
where the alignment looks good now in the case of bug 1784876.
Differential Revision: https://phabricator.services.mozilla.com/D156099
Except for the close-notification-message, all of the notification.dtd
strings are only used by popupnotification.js. Accordingly, the strings
are migrated to two different FTL files.
Differential Revision: https://phabricator.services.mozilla.com/D154890
As the widget requires the individual fields' placeholder values to
be known during their build, the DOMLocalization instance used here
needs to have sync methods enabled. For the same reason, the
placeholder strings need to be separate messages, rather than
attributes on the same message as the corresponding label.
Differential Revision: https://phabricator.services.mozilla.com/D154448
This makes it easier to get parity between legacy and regular flex
without having to either have tons of arbitrary attribute selectors in
the xul sheet, nor adding attribute lookup hacks to the html flexbox
layout.
Also, reimplement the remaining supported flex attribute-values (0 and 1)
purely in terms of CSS rules in xul.css (regardless of whether
emulate-moz-box-with-flex is enabled).
In practice these are pretty uncommon and the style attribute does the
trick in every case I've tried.
Add a debug-only assertion to ensure we preserve behavior for now.
Add a new test with another behavior difference between flexbox
emulation and old xul layout because the old reftest now passes. Use
replaced elements, which in modern flex are treated differently.
Differential Revision: https://phabricator.services.mozilla.com/D154394
This makes it easier to get parity between legacy and regular flex
without having to either have tons of arbitrary attribute selectors in
the xul sheet, nor adding attribute lookup hacks to the html flexbox
layout.
Also, reimplement the remaining supported flex attribute-values (0 and 1)
purely in terms of CSS rules in xul.css (regardless of whether
emulate-moz-box-with-flex is enabled).
In practice these are pretty uncommon and the style attribute does the
trick in every case I've tried.
Add a debug-only assertion to ensure we preserve behavior for now.
Add a new test with another behavior difference between flexbox
emulation and old xul layout because the old reftest now passes. Use
replaced elements, which in modern flex are treated differently.
Differential Revision: https://phabricator.services.mozilla.com/D154394
This is a follow-up to bug 1783500. The existing expansion for the
screen area works great on Windows and so on, but on macOS it can
conceptually cause a menulist to go off-screen, because of this margin
used to move menulists to the left:
https://searchfox.org/mozilla-central/rev/f655bdf6b4bf01b42609750ab94fc37635397260/toolkit/themes/osx/global/popup.css#85
Instead we should do the same as that bug did, and use the
input-region-margin, which is the amount of space that has no content
(that is, that contains the shadow and so on) and is zero on macOS
(because shadows on macOS are drawn by the OS unlike on Windows /
Linux).
This required extra test changes so it was worth getting it reviewed
separately.
Differential Revision: https://phabricator.services.mozilla.com/D154401
This is a follow-up to bug 1783500. The existing expansion for the
screen area works great on Windows and so on, but on macOS it can
conceptually cause a menulist to go off-screen, because of this margin
used to move menulists to the left:
https://searchfox.org/mozilla-central/rev/f655bdf6b4bf01b42609750ab94fc37635397260/toolkit/themes/osx/global/popup.css#85
Instead we should do the same as that bug did, and use the
input-region-margin, which is the amount of space that has no content
(that is, that contains the shadow and so on) and is zero on macOS
(because shadows on macOS are drawn by the OS unlike on Windows /
Linux).
This required extra test changes so it was worth getting it reviewed
separately.
Differential Revision: https://phabricator.services.mozilla.com/D154401
This code will most likely be removed, but for now I am putting it
behind a pref so that it won't be activated when the modal is being
created.
See Bug 1782582 for the removal of the code.
Differential Revision: https://phabricator.services.mozilla.com/D153393
