The regressing bug accidentally swapped the foreground / bg colors in a
way such that it doesn't look like there's an outline.
Do some adjacent clean-up while at it, and add a test.
Differential Revision: https://phabricator.services.mozilla.com/D156947
When there is size containment, if the contain-intrinsic-size is not none,
we need to use the available contain-intrinsic-size to determine the
intrinsic inline and block sizes.
This patch also updates and adds a couple of sub-tests in contain-intrinsic-size-009.html.
Differential Revision: https://phabricator.services.mozilla.com/D155051
This patch doesn't change behavior but I had it lying around in my
machine, and makes the code a bit easier to follow, so no reason not
to land it IMO.
Differential Revision: https://phabricator.services.mozilla.com/D154886
In the description of the mTruncated bit, its purpose is the same as calling
SetInlineLineBreakBeforeAndReset(). We've removed all its usages in previous
patches, so the bit is no longer needed.
Differential Revision: https://phabricator.services.mozilla.com/D151461
And remove one unused caller.
This might change behavior of some selection contrast checks and backplating
which will potentially use the right background-color after this patch. The
next patch ensures this is also accounted for for scrollbars.
Unfortunately selection contrast checks are non-trivial to test because we only
do the contrast check with system colors, and we'd need a default selection
color close to the highlight color to do this.
Differential Revision: https://phabricator.services.mozilla.com/D151017
This patch is based on Mats Palmgren's idea bug 1599159 comment 0.
When a child block frame reports inline-break-before status after being
reflowed, its size in the returned reflow output shouldn't matter because the
parent is expected to push it to the next page/column [1].
Here is the detail of the debug assertion if the workaround in fieldset frame is
removed. In nsBlockReflowContext::ReflowBlock(), it sets mReflowOutput::BSize()
to 0xdeadbeef, which is a negative number in 32-bits integer. Without the early
break of the loop in nsBlockFrame::ReflowBlockFrame(), then later in the loop we
are going to pass the negative block-size to
BlockReflowState::GetFloatAvailableSpaceForBSize(), which triggers a `aBSize>=0`
assertion further down in the callstack in nsFloatManager::GetFlowArea().
layout/reftests/pagination/fieldset-00G.html can trigger the above assertion
after removing the workaround in fieldset frame.
I don't expect this patch will change the behavior even if there are some float
elements interacting with this block. Without the early breaking out of the
loop, we still end up in [1].
[1] https://searchfox.org/mozilla-central/rev/ace2c59e6c56b2dcba25af1aa8903a5e7f9a5857/layout/generic/nsBlockFrame.cpp#4026-4035
Differential Revision: https://phabricator.services.mozilla.com/D148815
Add a dom/base/rust crate called just "dom" where we can share these.
Most of the changes are automatic:
s/mozilla::EventStates/mozilla::dom::ElementState/
s/EventStates/ElementState/
s/NS_EVENT_STATE_/ElementState::/
s/NS_DOCUMENT_STATE_/DocumentState::/
And so on. This requires a new cbindgen version to avoid ugly casts for
large shifts.
Differential Revision: https://phabricator.services.mozilla.com/D148537
Not a fan of this, I'd rather not do this... A potential, maybe less
hacky alternative, would be to resolve text-indent by truncating rather
than rounding. That would effectively round down the 0.01px to zero.
Differential Revision: https://phabricator.services.mozilla.com/D146993
The non-native theme draws the button arrow nowadays always, so these
backgrounds never really get painted.
No behavior change.
Depends on D145713
Differential Revision: https://phabricator.services.mozilla.com/D145714
Don't generate the button if the combobox doesn't need it anyways (if the
appearance is not menulist).
While at it improve the code that reframes on appearance: textfield changes so
that it only applies to number inputs as it should.
This shouldn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D145712
In bug 1744009[1] I changed some code that looked like:
* Get the dropdown frame intrinsic size.
* If there's overlay scrollbars, add the non-overlay scrollbar size.
That code came from bug 869314. I misread the "if there's overlay
scrollbars" bit.
There's no need to explicitly add the scrollbar width to the intrinsic
size anymore. The dropdown frame no longer exists, and the button size
is split out from the scrollbar size nowadays. There's no reason
to artificially add any size to the content frame.
[1]: https://hg.mozilla.org/integration/autoland/rev/78130d73ca75#l24.652
Differential Revision: https://phabricator.services.mozilla.com/D142834
We switch the open state storage to the element rather than the frame,
to be able to preserve it across reframes.
The code is loosely based on nsHideViewer in nsSubDocument.cpp, but it's
simpler because we don't need to do restoration shenanigans.
Differential Revision: https://phabricator.services.mozilla.com/D138689
This fixes the following build errors:
layout/forms/nsRangeFrame.cpp:135:42: error: member access into incomplete type 'const nsIFrame::nsDisplayListSet' (aka 'const mozilla::nsDisplayListSet')
layout/forms/nsRangeFrame.cpp:363:19: error: incomplete type 'nsLayoutUtils' named in nested name specifier
Differential Revision: https://phabricator.services.mozilla.com/D138202
The old code operates in the CSS pixel coordinate, so we should use the type
system to express that. With this patch, nsImageControlFrame, nsImageFrame, and
nsImageMap now have no usage of nsIntPoint.
Differential Revision: https://phabricator.services.mozilla.com/D136647
The pseudo-class and nsContextMenu context attribute were using reveal,
the pseudo-element and webidl attribute were using "show".
Use reveal consistently and update the accesskey so that there aren't
conflicts with existing commands. Also enable the feature in
browser_contextmenu_input.js so that this change is tested.
Differential Revision: https://phabricator.services.mozilla.com/D136086
In terms of the C++ code, this patch does basically one thing, which is
allowing creating option / optgroup accessibles without a frame for
comboboxes, and tracking mutations like layout does.
It seems this should be straight-forward, but handling mutations got a
bit complicated. We don't want to forcibly re-create accessibles, so we
want to re-use the PruneOrInsertSubtree logic that ContentInserted uses.
But determining whether we need to create the accessible requires
having flushed styles, so I added a ScheduleAccessibilitySubtreeUpdate
API to trigger that from WillRefresh once style and layout are
up-to-date.
The rest of the test updates should be sort of straight-forward. They
reflect two changes:
* <option> accessibles are leaves now (so they don't have text
children). Note that we still have the right native name and so on,
using the same logic we use to render the label.
* In 1proc tests, the focus no longer goes to the <option>, and uses
the same code-path that e10s does (moving focus to a <menulist> in
the parent process). Since that wasn't easy to test for (afaict) and
we have browser tests to cover that
(browser_treeupdate_select_dropdown.js, etc), I've decided to just
remove the tests that relied on the previous code-path, as they were
testing for a codepath that users weren't hitting anyways.
I've tested this with JAWS and Orca and behavior seems unchanged to my
knowledge.
Differential Revision: https://phabricator.services.mozilla.com/D133098
With this patch on its own we get some a11y tests failures, but those
are fixed on a later patch.
Combobox select no longer creates frames for its <options>, nor an
nsListControlFrame. Instead, it computes its right intrinsic size using
the largest size of the options. This is better, because we render the
option text using the select style so if the select and option styles
are mismatched it'd cause changes in the size of the select when text
changes. See the following in a build without the patch, for example:
<select>
<option>ABC</option>
<option style="font-size: 1px">Something long</option>
</select>
This seems like a rather obscure case, but it's important to get it
right, see bug 1741888.
With this patch we use the same setup in content and parent processes
(this needs bug 1596852 and bug 1744152). This means we can remove a
bunch of the native view and popup code in nsListControlFrame. A couple
browser_* tests are affected by this change and have been tweaked
appropriately (the changes there are trivial).
Not creating an nsListControlFrame for dropdown select means that we
need to move a bunch of the event handling code from nsListControlFrame
to a common place that nsComboboxControlFrame can also use. That place
is HTMLSelectEventListener, and I think the setup is much nicer than
having the code intertwined with nsListControlFrame. It should be
relatively straight-forward to review, mostly moving code from one part
to another.
Another thing that we need to do in HTMLSelectEventListener that we
didn't use to do is listening for DOM mutations on the dropdown. Before,
we were relying on changes like text mutations triggering a reflow of
the listcontrolframe, which also triggered a reflow of the
comboboxcontrolframe, which in turn updated the text of the anonymous
content. Now we need to trigger that reflow manually.
There are some further simplifications that can be done after this
lands (cleanup naming of openInParentProcess and so on, among others),
but I'd rather land this first (after the merge of course) and work on
them separately.
Differential Revision: https://phabricator.services.mozilla.com/D132719
In terms of the C++ code, this patch does basically one thing, which is
allowing creating option / optgroup accessibles without a frame for
comboboxes, and tracking mutations like layout does.
It seems this should be straight-forward, but handling mutations got a
bit complicated. We don't want to forcibly re-create accessibles, so we
want to re-use the PruneOrInsertSubtree logic that ContentInserted uses.
But determining whether we need to create the accessible requires
having flushed styles, so I added a ScheduleAccessibilitySubtreeUpdate
API to trigger that from WillRefresh once style and layout are
up-to-date.
The rest of the test updates should be sort of straight-forward. They
reflect two changes:
* <option> accessibles are leaves now (so they don't have text
children). Note that we still have the right native name and so on,
using the same logic we use to render the label.
* In 1proc tests, the focus no longer goes to the <option>, and uses
the same code-path that e10s does (moving focus to a <menulist> in
the parent process). Since that wasn't easy to test for (afaict) and
we have browser tests to cover that
(browser_treeupdate_select_dropdown.js, etc), I've decided to just
remove the tests that relied on the previous code-path, as they were
testing for a codepath that users weren't hitting anyways.
I've tested this with JAWS and Orca and behavior seems unchanged to my
knowledge.
Differential Revision: https://phabricator.services.mozilla.com/D133098
With this patch on its own we get some a11y tests failures, but those
are fixed on a later patch.
Combobox select no longer creates frames for its <options>, nor an
nsListControlFrame. Instead, it computes its right intrinsic size using
the largest size of the options. This is better, because we render the
option text using the select style so if the select and option styles
are mismatched it'd cause changes in the size of the select when text
changes. See the following in a build without the patch, for example:
<select>
<option>ABC</option>
<option style="font-size: 1px">Something long</option>
</select>
This seems like a rather obscure case, but it's important to get it
right, see bug 1741888.
With this patch we use the same setup in content and parent processes
(this needs bug 1596852 and bug 1744152). This means we can remove a
bunch of the native view and popup code in nsListControlFrame. A couple
browser_* tests are affected by this change and have been tweaked
appropriately (the changes there are trivial).
Not creating an nsListControlFrame for dropdown select means that we
need to move a bunch of the event handling code from nsListControlFrame
to a common place that nsComboboxControlFrame can also use. That place
is HTMLSelectEventListener, and I think the setup is much nicer than
having the code intertwined with nsListControlFrame. It should be
relatively straight-forward to review, mostly moving code from one part
to another.
Another thing that we need to do in HTMLSelectEventListener that we
didn't use to do is listening for DOM mutations on the dropdown. Before,
we were relying on changes like text mutations triggering a reflow of
the listcontrolframe, which also triggered a reflow of the
comboboxcontrolframe, which in turn updated the text of the anonymous
content. Now we need to trigger that reflow manually.
There are some further simplifications that can be done after this
lands (cleanup naming of openInParentProcess and so on, among others),
but I'd rather land this first (after the merge of course) and work on
them separately.
Differential Revision: https://phabricator.services.mozilla.com/D132719
This is the main patch for the bug. It aims to change the grapheme cluster
break's `Next()` API by implementing SegmentIteratorUtf16 interface, and adapt
the callers. It shouldn't change the behavior.
While rewriting the caller, one caveat worth mentioning is the loop termination
condition. If the old code relies on `!AtEnd()` as the loop termination
condition, and it advances the iterator at the end of the loop, it meant
to *skip* its logic when the break position is at the end of the string. For
example, see the `mozTXTToHTMLConv::NumberOfMatches`.
This patch also hooks grapheme cluster break iterator into
Segmenter::TryCreate() interface.
Existing test coverage for the file changed:
- netwerk/test/unit/test_mozTXTToHTMLConv.js
- layout/reftests/forms/input/file/dynamic-max-width.html
Differential Revision: https://phabricator.services.mozilla.com/D135643
Include "nsLayoutUtils.h" in nsFileControlFrame to get rid of warnings in my
editor because it uses utilities such as `nsLayoutUtils::AppUnitWidthOfString`.
We compile it without issues because of unified build.
Differential Revision: https://phabricator.services.mozilla.com/D135640
-Wshadow warnings are not enabled globally, so these -Wno-shadow suppressions have no effect. I had intended to enable -Wshadow globally along with these suppressions in some directories (in bug 1272513), but that was blocked by other issues.
There are too many -Wshadow warnings (now over 2000) to realistically fix them all. We should remove all these unnecessary -Wno-shadow flags cluttering many moz.build files.
Differential Revision: https://phabricator.services.mozilla.com/D132289
