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
Otherwise the origin of the rect might not be correctly converted.
We have a supposed test for something like this:
layout/reftests/forms/input/number/spinner-overflow-vertical.html
But in practice it doesn't work, because I removed the "overflowing
descendants inflate outlines" behavior (bug 1739894), and even with that
pref it doesn't seem to cut it... So repurpose that test to test both.
Differential Revision: https://phabricator.services.mozilla.com/D131175
1. Use dom events in RootAccessible to fire ACTIVE state changes.
2. Add DOMMenuItemInactive events to nsListControlFrame and fire it on
the previously active option.
3. Don't fire those DOM events on collapsed combo boxes.
4. Add ACTIVE state change events for collapsed combo box options.
Differential Revision: https://phabricator.services.mozilla.com/D130298
1. Use dom events in RootAccessible to fire ACTIVE state changes.
2. Add DOMMenuItemInactive events to nsListControlFrame and fire it on
the previously active option.
3. Don't fire those DOM events on collapsed combo boxes.
4. Add ACTIVE state change events for collapsed combo box options.
Differential Revision: https://phabricator.services.mozilla.com/D130298
These are only used for frameset painting and the non-e10s <select>
dropdown focus codepath. We have other more appropriate standard
colors for this.
Differential Revision: https://phabricator.services.mozilla.com/D129992
This patch doesn't change any user-observable behavior.
StaticAutoPtr lets us remove a handful of explicit 'delete' statements, by
making deletion happen automatically when these variables are cleared.
Differential Revision: https://phabricator.services.mozilla.com/D127336
There's only one meaningful usage of it, which is to disable native
appearance of the <input type=range> (the windows native theme is no
longer exposed to content).
<input type=range> is inconsistent with every other native widget, which
only disables native appearance if the author specifies backgrounds or
borders. So make it match literally all other widgets and simplify a bit
the code.
We had no tests for this special behavior, let me know if you think it's
worth adding one (but I don't feel very strongly about it).
Differential Revision: https://phabricator.services.mozilla.com/D127082
There's only one meaningful usage of it, which is to disable native
appearance of the <input type=range> (the windows native theme is no
longer exposed to content).
<input type=range> is inconsistent with every other native widget, which
only disables native appearance if the author specifies backgrounds or
borders. So make it match literally all other widgets and simplify a bit
the code.
We had no tests for this special behavior, let me know if you think it's
worth adding one (but I don't feel very strongly about it).
Differential Revision: https://phabricator.services.mozilla.com/D127082
This frame property's type is small enough to fit directly in the property
table's 64-byte slot; so, this patch makes us store the data directly there
(rather than allocating it externally and storing a pointer in the table).
This patch shouldn't impact behavior at all.
Differential Revision: https://phabricator.services.mozilla.com/D126032
Emilio Cobos Álvarez
Edgar Chen
Miko Mynttinen
Norisz Fay
Daniel Holbert
Andi-Bogdan Postelnicu
Ting-Yu Lin
Jan Varga
Marian-Vasile Laza
Mats Palmgren
Chris Peterson
Andi-Bogdan Postelnicu
Eitan Isaacson
Butkovits Atila
Cristian Tuns
criss