This patch updates all occurrences of the type `nsTextFragment` into its new name, `mozilla::dom::CharacterDataBuffer`.
It also updates the includes, including sorting.
Differential Revision: https://phabricator.services.mozilla.com/D259867
Includes the examples from the report as a testcase, though there is not yet
any formal spec for the exact behavior of segment break transformation.
(But nevertheless there is an existing collection of tests, so this just adds
one for the punctuation case.)
Differential Revision: https://phabricator.services.mozilla.com/D231476
Includes the examples from the report as a testcase, though there is not yet
any formal spec for the exact behavior of segment break transformation.
(But nevertheless there is an existing collection of tests, so this just adds
one for the punctuation case.)
Differential Revision: https://phabricator.services.mozilla.com/D231476
Includes the examples from the report as a testcase, though there is not yet
any formal spec for the exact behavior of segment break transformation.
(But nevertheless there is an existing collection of tests, so this just adds
one for the punctuation case.)
Differential Revision: https://phabricator.services.mozilla.com/D231476
The spec explicitly requires that we "must ensure that tab stops continue to line up"
when applying justification to content with preserved white-space that includes tabs.
So when we're computing justification spacing adjustments, we must not apply adjustments
if there is a preserved tab later on the same line; only text after the last tab is to
be justified.
Differential Revision: https://phabricator.services.mozilla.com/D191996
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
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
That prevents preceding whitespace from getting collapsed.
When there's a single lone CR (so `a\rb`) our behavior here diverges
from Chrome's but matches Safari's. We treat it as ZWSP.
That matches the initial resolution of [1], but then there have been
various doing and undoings of that resolution, so it's not totally clear
to me what the correct behavior per spec should be. I think "treat it as
other control character"? But I haven't dug into what that implies, so
for now I've just kept behavior there as-is.
[1]: https://github.com/w3c/csswg-drafts/issues/855
Differential Revision: https://phabricator.services.mozilla.com/D86188
The issues fall into these categories:
- Files that used StaticPrefs::layout_XYZ() API or gfxVars::XYZ that needed an
include. (Addressed by adding the missing include.)
- Files that use mozilla::dom::XYZ or mozilla::gfx::XYZ without qualifying the
namespace & without a 'using' decl. (Addressed by adding "using".)
- A few other includes for types/inlines that were used without their header.
Depends on D50162
Differential Revision: https://phabricator.services.mozilla.com/D50163
Per the discussion in:
https://groups.google.com/d/msg/mozilla.dev.platform/P79pwa9z5m8/iPYPAWPHCAAJ
They should be CamelCase, and that's what most of them already do. This converts
the rest, which are a few.
For the ones that already used `e` or `k` prefixes, I've mostly done:
for file in $(rg Type::e layout | cut -d : -f 1 | sort | uniq); do sed -i 's#Type::e#Type::#g' $file; done
For the ones that used uppercase, I've removed the prefix if it was already in
the type name, and turn them into CamelCase.
Depends on D28680
Differential Revision: https://phabricator.services.mozilla.com/D28681
nsUnicodeProperties.h includes into ICU, which has implicit int
truncation, so quarantine this include out of problematic headers.
Depends on D25498
Differential Revision: https://phabricator.services.mozilla.com/D25499
This patch was generated automatically by the "modeline.py" script, available
here: https://github.com/amccreight/moz-source-tools/blob/master/modeline.py
For every file that is modified in this patch, the changes are as follows:
(1) The patch changes the file to use the exact C++ mode lines from the
Mozilla coding style guide, available here:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
(2) The patch deletes any blank lines between the mode line & the MPL
boilerplate comment.
(3) If the file previously had the mode lines and MPL boilerplate in a
single contiguous C++ comment, then the patch splits them into
separate C++ comments, to match the boilerplate in the coding style.
MozReview-Commit-ID: EuRsDue63tK
This patch is an implementation of CSS Text 3 - 4.1.1 Phase 1 Step 1.
According to the specification, if white space characters are considered
collapsible, they should be removed before applying segment break transformation
rules during the text transform.
In this patch, a refactoring of text transformation logic has been made. Every
run of consecutive document white space characters (spaces/tabs/segment breaks)
is collected first. Then, we could apply the white space processing rules
accordingly.
MozReview-Commit-ID: 1JStjFk5TBs
This patch is an implementation of CSS Text 3 - 4.1.1 Phase 1 Step 1.
According to the specification, if white space characters are considered
collapsible, they should be removed before applying segment break transformation
rules during the text transform.
In this patch, a refactoring of text transformation logic has been made. Every
run of consecutive document white space characters (spaces/tabs/segment breaks)
is collected first. Then, we could apply the white space processing rules
accordingly.
MozReview-Commit-ID: 1JStjFk5TBs
This adds 2 "using namespace mozilla" (to provide various types),
and 2 "using namespace mozilla::gfx" (to provide mozilla::gfx::DrawTarget).
MozReview-Commit-ID: 2bXbMlr4Dbn
Jonathan Kew