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
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
The purpose of this patch is to remove LineBreaker::Prev(), and audit
the deprecated LineBreaker::DeprecatedNext() (added in bug 1733872).
Add blockquotecite gtest to make sure short line wrapping with
blockquote citation still works. The testcase's behavior is not changed.
Differential Revision: https://phabricator.services.mozilla.com/D127385
With this edge case explicitly considered, it will be easier for the
following patches to simplify logic in `FindWrapIndexForContent()`.
Differential Revision: https://phabricator.services.mozilla.com/D127382
The purpose of this patch is to remove LineBreaker::Prev(), and audit
the deprecated LineBreaker::DeprecatedNext() (added in bug 1733872).
Add blockquotecite gtest to make sure short line wrapping with
blockquote citation still works. The testcase's behavior is not changed.
Differential Revision: https://phabricator.services.mozilla.com/D127385
With this edge case explicitly considered, it will be easier for the
following patches to simplify logic in `FindWrapIndexForContent()`.
Differential Revision: https://phabricator.services.mozilla.com/D127382
This patch is similar to Bug 1728708 Part 4, but for line breaker. This
should make the future integration of ICU4X line segmenter easier. A
UAX14 compatible line breaker always breaks at the end of text
(rule LB3 [1]), and ICU4X line segmenter has this behavior, too.
Current LineBreaker::Next() doesn't treat the end of text as a line
break opportunity, so this patch deprecates it by renaming it, and add a
new Next() method.
TestASCIILB() has adopted the new Next(). All the other callers of the
DeprecatedNext (nsPlainTextSerializer, nsXMLContentSerializer,
InternetCiter) should be audited later, possibly with the removal of
Prev() because the all the usages are very close to Prev().
[1] https://www.unicode.org/reports/tr14/#LB3
Differential Revision: https://phabricator.services.mozilla.com/D127379
Automatically generated path that adds flag `REQUIRES_UNIFIED_BUILD = True` to `moz.build`
when the module governed by the build config file is not buildable outside on the unified environment.
This needs to be done in order to have a hybrid build system that adds the possibility of combing
unified build components with ones that are built outside of the unified eco system.
Differential Revision: https://phabricator.services.mozilla.com/D122345
