The fade-out animation is kept.
To work around the bug, the first paint of the panel window needs to be done at
full window opacity. Reducing the window opacity after the shadow has been
computed works correctly.
Differential Revision: https://phabricator.services.mozilla.com/D97863
The protections.css declaration is not needed, because you're setting
backgrounds and borders anyways so native appearance is disabled.
The button.css change needs to turn into a -moz-default-appearance +
appearance combo, but since it's in three different places, just put it
in xul.css instead.
Differential Revision: https://phabricator.services.mozilla.com/D89469
Uses of `-moz-appearance: none` are changed to `appearance: none`.
Uses of other values that are simply reverting the appearance back to
its default are changed to `appearance: auto`.
Uses of values in UA sheets that are defining the inherent appearance of
widgets are changed to:
appearance: auto;
-moz-default-appearance: <value>;
since those values are either no longer supported on (-moz-)appearance,
or are still supported but only in some limited form.
There are some uses of `-moz-appearance: textfield` on <input
type=number> elements that are renamed to `appearance: textfield`.
Differential Revision: https://phabricator.services.mozilla.com/D83430
This unifies toolbarbutton-text and toolbarbutton-multiline-text. We now
always use toolbarbutton-text for the button's text, but can either use
textContent or the value attribute, depending on the value of the wrap
attribute. This reduces DOM size and consumer complexity, at the cost of
adding some logic to toolbarbutton.js itself.
Differential Revision: https://phabricator.services.mozilla.com/D76383
This makes dropmarkers 'optional extras', effectively, and opts the existing
consumers I could find (the places window on macOS, and the 'more engines'
item in the search field popup) into these dropmarkers.
This allows removing all the CSS that was hiding these items in various
places.
We deliberately do not support adding dropmarkers at runtime. I also noticed
that the 'more engines' item already adds the 'badged' attribute after
connecting the node to the DOM, which may result in it not applying properly,
and fixed this.
Differential Revision: https://phabricator.services.mozilla.com/D76382
This both allows proper CSS sizing (it respects max-width), and allows for hidden overflow for long badges.
Using xul:label with textContent fixes the former but doesn't support the latter, so an html:label is used instead.
Differential Revision: https://phabricator.services.mozilla.com/D57652
--HG--
extra : moz-landing-system : lando
<xul:description> doesn't respect `display` and effectively behaves like
`display: flow-root` unless it has the `value` attribute.
<xul:label> and <xul:button> are expected to be inline level when in HTML
blocks.
The former fixes the about dialog. The later fixes the session restore page,
which in today's nightly shows the two buttons in different lines.
I could try to write more targeted fixes if you want, and probably switching to
html layout while at it.
<label> can be display: inline, at least in the about dialog. And the
<xul:button> in the restore session page can be <html:buttons> (inline-blocks).
But then again the involved elements always create specific layout boxes
disregarding display, so this patch does effectively the same.
Differential Revision: https://phabricator.services.mozilla.com/D59093
--HG--
extra : moz-landing-system : lando
After bug 1598841, they don't inherit `direction` from the root, so we need to
explicitly style the default toltip.
Differential Revision: https://phabricator.services.mozilla.com/D58367
--HG--
extra : moz-landing-system : lando
This patch also includes necessary JS changes to support this. Most commonly, the dialog was accessed with document.documentElement, which needed to be changed now that the dialog is not the top level element.
Differential Revision: https://phabricator.services.mozilla.com/D52411
--HG--
extra : moz-landing-system : lando