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
There is one thing to note in this patch that is a change: this patch changes the displayport that we log for test purposes from the critical display port to the display port.
This will only be different on android. If tests were checking this then they were broken because the critical display port has no significance. I did a quick survey of the tests I could find that used this. None of them seem like they really want the critical display port (given the new world where critical display port has no significance).
Depends on D127350
Differential Revision: https://phabricator.services.mozilla.com/D127351
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
`Span` is more versatile than `const String&`, and existing callers passing a
String into this function do not need any change.
This patch makes the next part simpler.
Differential Revision: https://phabricator.services.mozilla.com/D135642
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
nsPageSequenceFrame does a thing where it grows its desired size to fit the
AvailableISize and ComputedBSize (under the assumption that those are the
actual dimensions of our scrollport, which it wants to make maximal use of).
This behavior causes trouble when it's reflowed under the privileged
'sizeToContent' JS API. That API makes us reflow with nscoord_MAX as the
viewport's ComputedBSize(), and this nscoord_MAX value gets passed down to be
the nsPageSequenceFrame's ComputedBSize as well. When we reach the code in
question, we dutifully grow the desired size to that bogus huge value, which is
clearly wrong.
This patch addresses this issue by simply declining to grow the desired size in
the scenario where ComputedBSize() is unconstrained. This leaves us with
reasonable values for our desired size (which are actually based on the
content, which makes it the right thing to do for the purpose of a
SizeToContent() call).
Differential Revision: https://phabricator.services.mozilla.com/D135762
nsPresContest::RegisterManagedPostRefreshObserver still lets us add a managed post refresh observer until the mPresShell pointer on the prescontent is nulled out. That means that between the call to CancelManagedPostRefreshObservers and mPresContext->DetachPresShell() (which nulls out the mPresShell pointer on the prescontext) in PresShell::Destroy we can add a managed post refresh observer that will never get removed. Notably, destroying the frame tree happens between these two calls.
So move the CancelManagedPostRefreshObservers call to happen right after we null out the mPresShell pointer on the prescontext.
In bug 1737503 I want to add a managed post refresh observer when we destroy a subdocument frame (it's only interested in the recreate frames case not the destruction case, but not an easy way to tell them apart afaik), so it triggers this bug. The patch and test I have for that bug exercise this scenario.
Differential Revision: https://phabricator.services.mozilla.com/D135340
Avoid storing functions with the wrong return type by wrapping them
trivially on a lambda (in ToCreatorFunc).
This gets compiled to a tail call so it's just one more instruction, and
the constexpr constructors should ensure we don't introduce static
inintializers (which is why we used macros in the past).
Differential Revision: https://phabricator.services.mozilla.com/D135343
Run with fission by default in test harnesses, with --disable-fission available as an
option.
Android mach commands automatically set --disable-fission; this can be over-ridden by
--setpref=fission.autostart=true.
fission.autostart is removed from all test profiles.
No changes to wpt, handled already in bug 1743714.
Differential Revision: https://phabricator.services.mozilla.com/D135137
We don't "pass" print settings to the content process by saving them to prefs,
so the test is no longer useful (this removes the code it's testing anyway).
Differential Revision: https://phabricator.services.mozilla.com/D135349
Run with fission by default in test harnesses, with --disable-fission available as an
option.
Android mach commands automatically set --disable-fission; this can be over-ridden by
--setpref=fission.autostart=true.
fission.autostart is removed from all test profiles.
No changes to wpt, handled already in bug 1743714.
Differential Revision: https://phabricator.services.mozilla.com/D135137
Following a GPU process restart ZoomConstraints do not currently get
set for the newly recreated APZCTreeManagers, meaning it is no longer
possible to asynchronously zoom pages.
To solve this, we make ZoomConstraintsClient observe a new
"compositor-reinitialized" topic. We send this notification in
GPUProcessManager::HandleProcessLost() to notify
ZoomConstraintsClients for parent process documents, and in
ContentChild::RecvReinitRendering() for documents in their respective
content processes. This must be performed after the compositor has
been reinitialized so that the APZCTreeManagerChild is able to send
the constraints to the APZCTreeManagerParent in the compositor
process.
Differential Revision: https://phabricator.services.mozilla.com/D135207
This patch fixed the following:
1. Make the helper support the vertical writing modes since its callers
GetMinISize() and GetPrefISize() are fully aware of the vertical writing modes.
`overflow-scroll-intrinsic-001.html` verifies this scenario. This also fixed a
testcase with "writing-mode: vertical-lr" in flexbox's
cross-axis-scrollbar.html.
2. Treat scrollbar's intrinsic size "zero" if we have "scrollbar-width: none"
since no scrollbar is showing at all.
`overflow-auto-scrollbar-gutter-intrinsic-003.html` verifies this scenario.
3. Return the scrollbar size if we have "scrollbar-gutter: stable", or twice the
size if we have "scrollbar-gutter: stable both-edges".
`overflow-auto-scrollbar-gutter-intrinsic-{001,002}.html` verifies this
scenario.
Differential Revision: https://phabricator.services.mozilla.com/D135182
Part of how invalidation works with WebRender is that we assume frames
with a WebRenderUserData object attached to them are in view. This means
for images that we must ensure we create an empty
WebRenderImageProviderData object even when we have no provider or
surface for display. This will allow us to invalidate properly when we
get the FRAME_COMPLETE notification from imagelib indicating that the
redecode has completed.
Differential Revision: https://phabricator.services.mozilla.com/D135077
This shouldn't change behavior but makes following the code a bit
easier. There's no point in using callbacks for touch-action as:
* We return the computed flags anyways.
* Each caller wants to do something different.
* (more importantly) The callback gets called synchronously.
So move the relevant code to TouchActionHelper and make the callers deal
with the flags as they please. I've preserved the behavior of only doing
the thing if the flags array is non-empty.
Differential Revision: https://phabricator.services.mozilla.com/D134933
The assertion here was added during the iterator refactoring in bug 1732349,
but is actually bogus. The old code would have returned via the MOZ_TRY_VAR
that wrapped the call to blockFrame->GetLineNumber(); that's replaced by
iter->FindLineContaining(), so we should now check for an error there and
similarly just return to the caller, not assert.
Differential Revision: https://phabricator.services.mozilla.com/D134950
The background we have on why this exists is in the code comments of the code
that's being removed, and in:
https://bugzilla.mozilla.org/show_bug.cgi?id=193001#c91
It seems very unlikely that this code is necessary. It's run for silent
printing when the new UI is enabled and E10s is disabled. If it was really
necessary it seems likely we'd have seen breakage in our much more common use
cases.
Differential Revision: https://phabricator.services.mozilla.com/D134936
The background we have on why this exists is in the code comments of the code
that's being removed, and in:
https://bugzilla.mozilla.org/show_bug.cgi?id=193001#c91
It seems very unlikely that this code is necessary. It's run for silent
printing when the new UI is enabled and E10s is disabled. If it was really
necessary it seems likely we'd have seen breakage in our much more common use
cases.
Differential Revision: https://phabricator.services.mozilla.com/D134936
Lee Salzman
Joel Maher
Emilio Cobos Álvarez
Olli Pettay
Timothy Nikkel
Marian-Vasile Laza
Ting-Yu Lin
Daniel Holbert
Sean Feng
Florian Quèze
Andi-Bogdan Postelnicu
Cristian Tuns
Geoff Brown
Butkovits Atila
Jonathan Watt
Jamie Nicol
Hiroyuki Ikezoe
Noemi Erli
Andrew Osmond
Jonathan Kew