The min-width / contain are as usual to allow elements to shrink under
their intrinsic size. You can only see its effects with relatively thin
windows (or with a very large number of tabs in the tabstrip case).
Differential Revision: https://phabricator.services.mozilla.com/D157216
The interaction of legacy flexbox (menupopup) with block is a bit nicer
than with flex.
I'm going to update menupopup with modern flexbox as soon as I fix all
the browser-chrome tests and the soft freeze is over, but this is
harmless and fixes the bug both with and without modern flexbox.
Remove -moz-box-flex: 0; from search-panel-tree since it's now useless
(there's no flexing to do since parent isn't a flex container).
Differential Revision: https://phabricator.services.mozilla.com/D159407
<menulist> still uses legacy XUL layout (for reasons, I plan to fix it
but it can take a little bit).
The issue here is a poor interaction between one of the wrapping hboxes
and the xul layout. But we can simplify the code and fix the bug at the
same time, so do that.
Differential Revision: https://phabricator.services.mozilla.com/D159254
This can be easily tested shrinking the viewport width with the previous
patch applied and the accented locale. Text overlaps without this patch
when two adjacent radios wrap.
Differential Revision: https://phabricator.services.mozilla.com/D159279
The min-width / contain are as usual to allow elements to shrink under
their intrinsic size. You can only see its effects with relatively thin
windows (or with a very large number of tabs in the tabstrip case).
Differential Revision: https://phabricator.services.mozilla.com/D157216
This fixes bug 1792881 in a way that actually preserves behavior from
before bug 1790307.
The main difference between modern flexbox and XUL is that size of
contents outside of the scroller (main-content) affect the size of the
scroller, preventing it from flexing if they're bigger than the
available size.
Instead, preserve the previous behavior (flex the scroller) by
preventing the minimum size from being taken into account, by using
contain. While at it, merge two selectors that were spread out.
Differential Revision: https://phabricator.services.mozilla.com/D158630
Following a suggestion from :mkmelin, this seems like an optimal solution: the overriding/duplication in m-c is removed, and all users get a more powerful default choice that they're still able to override with their own, should they so wish.
For clarity and to match other `about:` pages, the shared code is placed under `toolkit/content/`, and all content under `docshell/resources/` is removed.
Differential Revision: https://phabricator.services.mozilla.com/D156478
To support and enable the migration, quite a bit of refactoring is needed.
Many of the localised error messages are in fact fragments of HTML, including messages with nesting not supported by Fluent. In the FTL, these have each been split up into multiple messages using a custom migration transform (included directly in the script). This allows for localisers to work with the messages without HTML syntax, but does require the messages' structures to be maintained elsewhere. To that effect, the JS file represents messages as arrays of `[tagName, l10nId, l10nArgs]` tuples from which it builds the messages' elements. This fixex bug 1621895.
Though extensive, the refactoring done here is for the most part limited to what's required by the Fluent migration. For instance, not all issues raised in bug 1722896 are resolved here. Places where the structure was sufficiently messy to have introduced bugs or dead code have been cleaned up a bit, though.
This variant of netError that's used by the browser is not itself overridden by anyone else, which allows for it to be tackled first and independently of the docshell and mobile variants. As a part of its content is still passed in as a query parameter, it's possible that later refactors of the rest of the netError system will allow for further clean-up here.
Differential Revision: https://phabricator.services.mozilla.com/D155951
In addition to adding messages for origin controls, this patch slightly
changes the UI to account for long l10n strings. As a result, the name
of the extension is no longer truncated with CSS (ellipsis). This isn't
a big problem as these names cannot exceed 45 characters (max 2 lines of
text). This allows us to better handle long permission messages and
(Windows) scrollbars. UX is OK with that at the moment.
We also retain the "default" height of the message below the name of an
extension (using the `min-height` property) to avoid flickering as per
UX guidelines.
Differential Revision: https://phabricator.services.mozilla.com/D156808
In addition to adding messages for origin controls, this patch slightly
changes the UI to account for long l10n strings. As a result, the name
of the extension is no longer truncated with CSS (ellipsis). This isn't
a big problem as these names cannot exceed 45 characters (max 2 lines of
text). This allows us to better handle long permission messages and
(Windows) scrollbars. UX is OK with that at the moment.
We also retain the "default" height of the message below the name of an
extension (using the `min-height` property) to avoid flickering as per
UX guidelines.
Differential Revision: https://phabricator.services.mozilla.com/D156808
Pass down the zap_gradient experimental theme property to pages that
load contentTheme.js, and use it to set the zap gradient value in
Firefox View (with a generic fallback color for themes that don't set
this experimental property)
Differential Revision: https://phabricator.services.mozilla.com/D158278
XUL honored the flex over explicit width. We need to set the width in
dialog code to properly keep the preferred width behavior.
Looking at min-width isn't needed for this patch but will be needed for
the next patch to preserve behavior.
Differential Revision: https://phabricator.services.mozilla.com/D158283
That was presumably the intention of the explicit width in the CSS but
that wasn't working.
While at it, use a proper deck rather than a hand-rolled one.
Differential Revision: https://phabricator.services.mozilla.com/D158223
Gijs for front-end bits, layout for the new CSS properties and the
removal of nsDeckFrame / nsStackLayout, Jamie and Morgan for the a11y
changes.
As discussed in the bug, the main tricky part here is handling a11y
correctly. For <deck>, that's trivial (just use `visibility: hidden` to
hide the panels visually, while removing the unselected panels from the
a11y tree).
For <tabpanels> however we need to do something special. We do want to
hide stuff visually, but we want to preserve the contents in the a11y
tree.
For that, the easiest fix is introducing a new privileged CSS property
(-moz-subtree-hidden-only-visually), which takes care of not painting
the frame, but marks stuff offscreen in the accessibility tree. This is
not intended to be a property used widely.
Other than that, the changes are relatively straight-forward, though
some of the accessible/mac changes I could get a sanity-check on.
Differential Revision: https://phabricator.services.mozilla.com/D157875
