XML/Plain text Serializer uses line break segmenter to wrap text. New
segmenter that is compatible with UAX#14 has different rules for old segmenter.
Old segmenter have break opportunity before ASCII space, but UAX#14 doesn't
have it (https://www.unicode.org/reports/tr14/#LB7).
So we have to trim ASCII space at the tail for text wrap.
Depends on D167677
Differential Revision: https://phabricator.services.mozilla.com/D180773
XML/Plain text Serializer uses line break segmenter to wrap text. New
segmenter that is compatible with UAX#14 has different rules for old segmenter.
Old segmenter have break opportunity before ASCII space, but UAX#14 doesn't
have it (https://www.unicode.org/reports/tr14/#LB7).
So we have to trim ASCII space at the tail for text wrap.
Depends on D167677
Differential Revision: https://phabricator.services.mozilla.com/D180773
We have more readable and faster versions (that just omit the namespace
arg).
Mostly done via sed, with a couple helpers to use the faster lookups
where possible.
Differential Revision: https://phabricator.services.mozilla.com/D181795
It's hard to check Selection API calls from both JS and internals when we debug
web apps which has complicated `contenteditable` editor. Therefore, I'd like to
add an ability to log Selection API calls.
This patch needs to stop some methods inlined. Therefore, this could affect to
the performance in release builds, though. If so, I need to work on some
optimization later.
For minimizing the impact for performance, this patch also makes them to check
the logging level before calling logging methods. It's currently redundant
for `LogLevel::Info` case. However, this avoids any performance impact from
changes of `MOZ_LOG` implementation and in the blocks.
Differential Revision: https://phabricator.services.mozilla.com/D170585
Most usage is a straight replacement but gtk needs extra changes as it transfers plain text in UTF8 natively and needs to be converted into UTF16, and Windows uses single-byte characters for RTF and CF_HTML formats so we preserve this.
Differential Revision: https://phabricator.services.mozilla.com/D158587
It's the only method which is used outside of the editor module. Therefore,
we can stop exposing `EditorUtils.h` later.
Depends on D158634
Differential Revision: https://phabricator.services.mozilla.com/D158635
To workaround the historical lack of 'white-space: pre', when an user
wants to compose HTML text with several consecutive spaces, WYSIWYG
HTML editors insert an alternating pattern of SPACE and NBSP to avoid
spaces being collapsed.
This is why browsers, when copying HTML content, usually strip all NBSP
from the copied text.
This commit changes the copying behavior, to strip only NBSP that were
potentially generated by an editor (and preserve the others).
The heuristic used is "An NBSP adjacent to a regular space doesn't make
sense, and can be replaced by a regular space". This detects the
alternating pattern of SPACE/NBSP, but also a space followed by a long
sequence of NBSP (because a line break would occur anyway in that case).
NB: included is a change that makes devtools use regular spaces
(rather than NBSPs) to indent stacktrace frames. This prevent NBSPs from
appearing in the clipboard when copying a stacktrace.
Attribution: the actual nsPlainTextSerializer changes were written by
Rachel Martin <rachel@betterbird.eu>, as a part of Betterbird.
Differential Revision: https://phabricator.services.mozilla.com/D149644
To workaround the historical lack of 'white-space: pre', when an user
wants to compose HTML text with several consecutive spaces, WYSIWYG
HTML editors insert an alternating pattern of SPACE and NBSP to avoid
spaces being collapsed.
This is why browsers, when copying HTML content, usually strip all NBSP
from the copied text.
This commit changes the copying behavior, to strip only NBSP that were
potentially generated by an editor (and preserve the others).
The heuristic used is "An NBSP adjacent to a regular space doesn't make
sense, and can be replaced by a regular space". This detects the
alternating pattern of SPACE/NBSP, but also a space followed by a long
sequence of NBSP (because a line break would occur anyway in that case).
NB: included is a change that makes devtools use regular spaces
(rather than NBSPs) to indent stacktrace frames. This prevent NBSPs from
appearing in the clipboard when copying a stacktrace.
Attribution: the actual nsPlainTextSerializer changes were written by
Rachel Martin <rachel@betterbird.eu>, as a part of Betterbird.
Differential Revision: https://phabricator.services.mozilla.com/D149644
The biggest set of APIs from ns[T]StringObsolete which are still heavily used
are the string searching APIs. It appears the intention was for these to be
replaced by the `FindInReadable` APIs, however that doesn't appear to have
happened.
In addition, the APIs have some quirks around their handling of mixed character
widths. These APIs generally supported both narrow strings and the native
string type, probably because char16_t string literals weren't available until
c++11. Finally they also used easy-to-confuse unlabeled boolean and integer
optional arguments to control behaviour.
These patches do the following major changes to the searching APIs:
1. The ASCII case-insensitive search method was split out as
LowerCaseFindASCII, rather than using a boolean. This should be less
error-prone and more explicit, and allows the method to continue to use
narrow string literals for all string types (as only ASCII is supported).
2. The other [R]Find methods were restricted to only support arguments with
matching character types. I considered adding a FindASCII method which would
use narrow string literals for both wide and narrow strings but it would've
been the same amount of work as changing all of the literals to unicode
literals.
This ends up being the bulk of the changes in the patch.
3. All find methods were re-implemented using std::basic_string_view's find
algorithm or stl algorithms to reduce code complexity, and avoid the need to
carry around the logic from nsStringObsolete.cpp.
4. The implementations were moved to nsTStringRepr.cpp.
5. An overload of Find was added to try to catch callers which previously
called `Find(..., false)` or `Find(..., true)` to set case-sensitivity, due
to booleans normally implicitly coercing to `index_type`. This should
probably be removed at some point, but may be useful during the transition.
Differential Revision: https://phabricator.services.mozilla.com/D148300
This patch moves EqualsIgnoreCase to ns[T]StringObsolete, and removes
the aCount argument, instead migrating callers to use `StringBeginsWith`
with a case-insensitive comparator.
In addition, nsTStringRepr::Compare was removed and replaced with either
calls to methods like `StringBeginsWith` or the global `Compare` method.
These changes required some modifications at call-sites but should make
the behaviour less surprising and more consistent.
Differential Revision: https://phabricator.services.mozilla.com/D148299
The biggest set of APIs from ns[T]StringObsolete which are still heavily used
are the string searching APIs. It appears the intention was for these to be
replaced by the `FindInReadable` APIs, however that doesn't appear to have
happened.
In addition, the APIs have some quirks around their handling of mixed character
widths. These APIs generally supported both narrow strings and the native
string type, probably because char16_t string literals weren't available until
c++11. Finally they also used easy-to-confuse unlabeled boolean and integer
optional arguments to control behaviour.
These patches do the following major changes to the searching APIs:
1. The ASCII case-insensitive search method was split out as
LowerCaseFindASCII, rather than using a boolean. This should be less
error-prone and more explicit, and allows the method to continue to use
narrow string literals for all string types (as only ASCII is supported).
2. The other [R]Find methods were restricted to only support arguments with
matching character types. I considered adding a FindASCII method which would
use narrow string literals for both wide and narrow strings but it would've
been the same amount of work as changing all of the literals to unicode
literals.
This ends up being the bulk of the changes in the patch.
3. All find methods were re-implemented using std::basic_string_view's find
algorithm or stl algorithms to reduce code complexity, and avoid the need to
carry around the logic from nsStringObsolete.cpp.
4. The implementations were moved to nsTStringRepr.cpp.
5. An overload of Find was added to try to catch callers which previously
called `Find(..., false)` or `Find(..., true)` to set case-sensitivity, due
to booleans normally implicitly coercing to `index_type`. This should
probably be removed at some point, but may be useful during the transition.
Differential Revision: https://phabricator.services.mozilla.com/D148300
None of the consumer need to mutate styles, and this saves some ugly
const_casting on the next patch.
Doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D147555
It's hard to fix some callers. Therefore, in this bug, we should fix only
simple cases. Therefore, we should rename existing API first.
Differential Revision: https://phabricator.services.mozilla.com/D131334
It's an internal API corresponding to `Selection.getRangeAt` DOM API.
I think that it should use `uint32_t` rather than `size_t` because of the
consistency with the DOM API and `Selection::RangeCount()`.
This patch fixes all callers of `GetRangeAt()`, and rewrites it with ranged-
loops unless original ones do not refer `RangeCount()` every time and may run
script in the loop.
Differential Revision: https://phabricator.services.mozilla.com/D128848
This unifies most of the calls in nsUnicodeProperties.h. CharType and Script
will be handled in subsequent patches on this bug.
Differential Revision: https://phabricator.services.mozilla.com/D132273
This unifies most of the calls in nsUnicodeProperties.h. CharType and Script
will be handled in subsequent patches on this bug.
Differential Revision: https://phabricator.services.mozilla.com/D132273
With the rewrite, we reduce the dependency of lwbrk LineBreaker::Next(),
WordBreaker::Next(), and their `int32_t` sentinel values
NS_LINEBREAKER_NEED_MORE_TEXT and NS_WORDBREAKER_NEED_MORE_TEXT.
Differential Revision: https://phabricator.services.mozilla.com/D130392
With the rewrite, we reduce the dependency of lwbrk LineBreaker::Next(),
WordBreaker::Next(), and their `int32_t` sentinel values
NS_LINEBREAKER_NEED_MORE_TEXT and NS_WORDBREAKER_NEED_MORE_TEXT.
Differential Revision: https://phabricator.services.mozilla.com/D130392
LineBreaker has no member variables and acts like "namespaces" with
utility functions. Therefore, its methods can be static and called
directly without needing a LineBreaker instance.
Rename GetJISx4051Breaks() to ComputeBreakPositions() per review
feedbacks.
Differential Revision: https://phabricator.services.mozilla.com/D129107
The behavior change of Next() vs DeprecatedNext() here is OK, because if DeprecatedNext()
failed to find a break position then we'd end up reaching the "simple fallback logic"
below, which will just advance to the next space or end-of-text anyhow.
The only case, then, where this results in a change of behavior would be if there's a
space that the line-breaker does *not* consider a valid break, so that instead it
advances to end-of-text, where previously we'd have reached the fallback code and
used the (invalid) space as a break. So (a) this is a really obscure edge-case, and
(b) the new behavior would be more correct anyhow.
Differential Revision: https://phabricator.services.mozilla.com/D127805
Makoto Kato
Sandor Molnar
Emilio Cobos Álvarez
Sean Burke
Masayuki Nakano
serge-sans-paille
Norisz Fay
Csoregi Natalia
Neil Deakin
Ryan VanderMeulen
Henri Sivonen
Ben Campbell
Pierre de La Morinerie
Marian-Vasile Laza
Nika Layzell
criss
Kagami Sascha Rosylight
Jonathan Kew
Dan Minor
Butkovits Atila
Ting-Yu Lin
Iulian Moraru
ssummar
Cristian Tuns
Andrew McCreight