Now that we're subclassing nsTextControlFrame we can use the regular replaced
element intrinsic sizing, rather than just faking it in the UA sheet with a
suspicious width declaration.
Differential Revision: https://phabricator.services.mozilla.com/D59981
--HG--
extra : moz-landing-system : lando
Now that we're subclassing nsTextControlFrame we can use the regular replaced
element intrinsic sizing, rather than just faking it in the UA sheet with a
suspicious width declaration.
Differential Revision: https://phabricator.services.mozilla.com/D59981
--HG--
extra : moz-landing-system : lando
Instead, subclass nsTextControlFrame. This simplifies the code and avoids
correctness issues.
I kept the localization functionality though it is not spec compliant. But I
filed a bug to remove it in a followup.
Differential Revision: https://phabricator.services.mozilla.com/D57193
--HG--
extra : moz-landing-system : lando
Instead, subclass nsTextControlFrame. This simplifies the code and avoids
correctness issues.
I kept the localization functionality though it is not spec compliant. But I
filed a bug to remove it in a followup.
Differential Revision: https://phabricator.services.mozilla.com/D57193
--HG--
extra : moz-landing-system : lando
Simply remove "max-block-size: 100%" for -moz-column-set and
-moz-column-content breaks abspos-breaking-dynamic-{001,002,003}.html.
We need to reflow ColumnSetWrapper's children whenever
ColumnSetWrapper's block-size or max-block-size is changed because both
size affect the available block-size for ColumnSetWrapper's children.
We set `NS_FRAME_CONTAINS_RELATIVE_BSIZE` for ColumnSetWrapperFrame so
that it will set itself dirty in `selfDirty` in
`nsBlockFrame::ReflowDirtyLines`, and mark its lines dirty if
`aState.mReflowInput.IsBResize()` is true.
Differential Revision: https://phabricator.services.mozilla.com/D58731
--HG--
extra : moz-landing-system : lando
Simply remove "max-block-size: 100%" for -moz-column-set and
-moz-column-content breaks abspos-breaking-dynamic-{001,002,003}.html.
We need to reflow ColumnSetWrapper's children whenever
ColumnSetWrapper's block-size or max-block-size is changed because both
size affect the available block-size for ColumnSetWrapper's children.
We set `NS_FRAME_CONTAINS_RELATIVE_BSIZE` for ColumnSetWrapperFrame so
that it will set itself dirty in `selfDirty` in
`nsBlockFrame::ReflowDirtyLines`, and mark its lines dirty if
`aState.mReflowInput.IsBResize()` is true.
Differential Revision: https://phabricator.services.mozilla.com/D58731
--HG--
extra : moz-landing-system : lando
This is covered by existing tests, via the removal of the rule in forms.css
Differential Revision: https://phabricator.services.mozilla.com/D56355
--HG--
extra : moz-landing-system : lando
The #text-overlay and #image child divs were "position: absolute" under
the main AccessibleCaret div. However, they don't necessary need to be
position:absolute to achieve the desired layout. We can make them normal
in-flow elements to simplify the frame structure. There should not be
any perceivable change to the user.
Also, AccessibleCaret's position can made more accurate by using float
CSS pixels when converting it from app unit.
Differential Revision: https://phabricator.services.mozilla.com/D51349
--HG--
extra : moz-landing-system : lando
We expect ColumnSet and -moz-column-content to be block outside.
If ColumnSets' display style is inherit from ColumnSetWrapper, then a
multicol with "display: inline-block" is going to wrap ColumnSet in a
inline nsLineBox when ColumnSet is added to ColumnSetWrapper, which is
not what we want.
This change fixed [.multicol 4] and [.multicol 6] in
multicol-gap-percentage-001.html with column-span disable, but it can
also fix [.multicol 5] in multicol-gap-percentage-001.html when
column-span is enabled (bug 1489298), so I go ahead and enable the pref
in that test.
Differential Revision: https://phabricator.services.mozilla.com/D39997
--HG--
extra : moz-landing-system : lando
Anonymous text node in password field has `NS_MAYBE_MASKED` flag and
`TextEditor` managing the node has range of unmasking. This patch makes
`BuildTextRunsScanner::BuildTextRunForFrames()` treat text frame in
password field as `text-transform` applied. For recording the unmask range,
this patch creates `nsTransformedCharStyle::mMaskPassword` and treats unmask
range start/end edges as different style boundary. Therefore,
`nsCaseTransformTextRunFactory::TransformString()` can replace each character
with a password mask character with the information.
Note that we need to kill bidi algorithm in password fields with forms.css
because caret position will tell everybody whether the typing character is
an RTL or an LTR character.
Differential Revision: https://phabricator.services.mozilla.com/D38009
--HG--
extra : moz-landing-system : lando
This is a potential fix that I thought it was worth doing rather than
implementing Blink's platform-dependent silliness. This ensures that the display
frame always has enough space to display itself.
Note that it may still get clipped, if there's no room for both the display
frame and the button.
Differential Revision: https://phabricator.services.mozilla.com/D37922
--HG--
extra : moz-landing-system : lando
This is a potential fix that I thought it was worth doing rather than
implementing Blink's platform-dependent silliness. This ensures that the display
frame always has enough space to display itself.
Note that it may still get clipped, if there's no room for both the display
frame and the button.
Differential Revision: https://phabricator.services.mozilla.com/D37922
--HG--
extra : moz-landing-system : lando
Inheriting block-size is just plain wrong in presence of calc or percentages.
The layout without these rules also matches other browsers, so I see no reason
not to do this.
Differential Revision: https://phabricator.services.mozilla.com/D37746
--HG--
extra : moz-landing-system : lando
And remove some of the ::placeholder and ::cue hacks where we need to use
!important to make the property not apply for content but apply on UA sheets.
The comment about the white-space property was wrong, we don't enforce it with
!important in the UA stylesheets for <input> (we do for <textarea> though), so
I've kept the flag since it really applies.
Differential Revision: https://phabricator.services.mozilla.com/D37717
--HG--
extra : moz-landing-system : lando
Inheriting block-size is just plain wrong in presence of calc or percentages.
The layout without these rules also matches other browsers, so I see no reason
not to do this.
Differential Revision: https://phabricator.services.mozilla.com/D37746
--HG--
extra : moz-landing-system : lando
Looks like some users use it, and it's not too much effort to support. This is
somewhat simpler, and IMO better than what existed before bug 1514655 because:
* It doesn't regress bidi rendering when the pref is disabled (before, the pref
would prevent plaintext.css from applying altogether).
* It's consistent with the way view-source docs work.
* It doesn't use non-standard stylesheet APIs to toggle the stylesheet
(bug 1260720).
Differential Revision: https://phabricator.services.mozilla.com/D37742
--HG--
extra : moz-landing-system : lando
Looks like some users use it, and it's not too much effort to support. This is
somewhat simpler, and IMO better than what existed before bug 1514655 because:
* It doesn't regress bidi rendering when the pref is disabled (before, the pref
would prevent plaintext.css from applying altogether).
* It's consistent with the way view-source docs work.
* It doesn't use non-standard stylesheet APIs to toggle the stylesheet
(bug 1260720).
Differential Revision: https://phabricator.services.mozilla.com/D37742
--HG--
extra : moz-landing-system : lando
It caused rendering issues just like a reftest in this commit. We don't know
the reason but fixing it will be some amount of work which couldn't be uplifted
to 68. So we just revert the change here now. Probably we should revisit the
problem once we got a bug report that the lack of the `transform-style: inherit`
causes rendering issues.
Differential Revision: https://phabricator.services.mozilla.com/D35946
--HG--
extra : moz-landing-system : lando
- Follow Gtk and get theme button text color directly from "button" CSS node instead of "button label"
- Provide new -moz-gtk-buttonactivetext color for active/pressed button text color
- Replace ButtonText color with -moz-gtk-buttonactivetext when it's appropriate
Differential Revision: https://phabricator.services.mozilla.com/D30566
--HG--
extra : moz-landing-system : lando