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
The motivation of this patch is to remove rarely used API in
WordBreaker. WordBreaker::BreakInBetween() is used only in
nsFind::BreakInBetween() in production, and it can be replaced by
Next().
If the user wants to know whether there is a word break between two
strings such as the use cases in gtest, joining the two strings and
passing the result to Next() is the preferred way.
Note: I delete the buggy forward word search algorithm in
TestFindWordBreakFromPosition() because from the test expectations, it
doesn't expect to continue the search in previous fragments. Also, the
buggy part comes from the following code, which had undefined behavior
before Part 4, and does nothing after Part 4.
```
wbk->FindWord(prevFragText.get(), prevFragText.Length(), prevFragText.Length());
```
Differential Revision: https://phabricator.services.mozilla.com/D125151
nextChar gets its value from DecodeChar() and PeekNextChar(), and both
functions return char32_t. It also passes as a char32_t argument to
BreakInBetween(). Therefore it really should have 32 bits to avoid
potential truncation.
Differential Revision: https://phabricator.services.mozilla.com/D125149
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
This I'm not 100% sure. Should be harmless, but it's a bit subtle.
Maybe we should special-case it with "we're at the beginning of the
pattern"? Reasoning below:
The previous patch restores the performance of the original test-case.
However, if you go to the reduced test-case and try to type " re" in the
findbar, we still take a long time. The reason for that is not that the
previous patch is not effective, but that the findbar sends find
requests as soon as you type, and thus we end up with a request to find
" ", which matches a gazillion spaces in the page and causes us to use
tons of memory and time. Finding " re" is actually super-fast :-)
This fixes it, but it is a bit subtle, so thoughts? Perhaps the findbar
should wait a bit to perform the search before sending a query for " "
instead or something? But I'd rather make it fast.
Differential Revision: https://phabricator.services.mozilla.com/D111634
This can happen with whitespace, and can cause us to scan whitespace
exponentially. Should be straight-forward and have no behavior change.
This restores the performance characteristics of the findbar before
the regressing bug.
Differential Revision: https://phabricator.services.mozilla.com/D111633
Due to an unfortunate typo I made in base_chars.py, I thought that there
were no mappings we care about outside of the basic multilingual plane.
This patch adds back the non-BMP mappings that we do care about.
Differential Revision: https://phabricator.services.mozilla.com/D107404
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
So what's going on here is that there are pseudo-elements that contain
stuff like content: "Note" or content: "Example".
So when you're searching for "entry", we find the `e`, and then all the
text nodes afterwards are of course in a different subtree... So we end
up ignoring them, but after having iterated through all the DOM first.
To avoid this, change a bit the code so that we check for different
blocks _before_ checking for different subtrees. There's no point to
keep matching once you're done with a block.
Differential Revision: https://phabricator.services.mozilla.com/D89365
This was kind of a pre-existing bug, though not surfaced because we
didn't have conditionally-appearing text nodes I guess.
If we are doing a match in a non-anonymous subtree, we'd skip the
anonymous text (that's alright). But if we actually reach the end of the
document (as it is the case on the test that starts failing with the
other patch in this bug), we'd just early-return, rather than restarting
where we left off, which is not fine and means that potential matches in
anonymous subtrees that were skipped won't show up.
This fixes the bug... Eventually we should probably come up with a
better structure than this gigantic while (true), probably moving all
these variables into their own struct, but today is not that day :)
Differential Revision: https://phabricator.services.mozilla.com/D84425
This restores our previous behavior when matching across anonymous
boundaries, as that's not something we currently can support because DOM
ranges can't represent that.
Differential Revision: https://phabricator.services.mozilla.com/D84397
This restores our previous behavior when matching across anonymous
boundaries, as that's not something we currently can support because DOM
ranges can't represent that.
Differential Revision: https://phabricator.services.mozilla.com/D84397
Maybe if / when we have a native way to allow showing the password we
can lift this if the password is visible or what not. Until then this is
just confusing.
Differential Revision: https://phabricator.services.mozilla.com/D82296
Other than this, there hasn't been any other major regression since we
introduced that switch. I don't think there's a point in keeping it
around.
Differential Revision: https://phabricator.services.mozilla.com/D82297
This check was done in GetNextNonEmptyTextFragmentInSameBlock which I
removed in bug 1627643.
Hopefully the fuzzer finds an easy reduced test-case to land as a
crashtest, otherwise I can try to construct one.
Differential Revision: https://phabricator.services.mozilla.com/D72926
The check for generated content in nsTextFrame is to the best of my
knowledge useless: We don't display generated content as selected when
the parent is selected anyhow, and the offsets would be wrong.
We special-case text inputs and textarea because of ::placeholder, see
the comment, but otherwise there's no reason you shouldn't be able to
find-in-page generated content / fallback / etc.
I added ForceBreakBetween so as to not create ranges that span across
shadow / anonymous content boundaries. They don't work anyway (see the
TODO in test_find.html), so it seems better to make that explicit until
we properly handle them (bug 1590379).
I added a pref just to be safe since this is long-standing behavior, but
I think it should be uncontroversial.
Differential Revision: https://phabricator.services.mozilla.com/D72447
We should always do this, otherwise stuff may not end up being visible which is
not acceptable for focus navigation.
Differential Revision: https://phabricator.services.mozilla.com/D70541
--HG--
extra : moz-landing-system : lando
We should start seeking from the child-at-start/end-offset, rather than the
selection container.
The logic to select the starting node was backwards too...
If we're finding backwards we want to start looking from the beginning of the
range and vice versa. But I think that doesn't really matter since
nsWebBrowserFind always gives us a start range with start == end.
Differential Revision: https://phabricator.services.mozilla.com/D63553
--HG--
extra : moz-landing-system : lando
We should start seeking from the child-at-start/end-offset, rather than the
selection container.
The logic to select the starting node was backwards too...
If we're finding backwards we want to start looking from the beginning of the
range and vice versa. But I think that doesn't really matter since
nsWebBrowserFind always gives us a start range with start == end.
Differential Revision: https://phabricator.services.mozilla.com/D63553
--HG--
extra : moz-landing-system : lando
`nsRange` instances are allocated a lot in the heap especially by editor and
spellchecker. The allocation cost is too bad for benchmarks. Therefore,
we should reuse released instances as far as possible. For managing it in
static factory methods of `nsRange`, we need to hide `nsRange` constructor.
Differential Revision: https://phabricator.services.mozilla.com/D61237
--HG--
extra : moz-landing-system : lando
Masayuki Nakano
Dan Minor
Butkovits Atila
Ting-Yu Lin
Andi-Bogdan Postelnicu
Emilio Cobos Álvarez
Alex Henrie
Kagami Sascha Rosylight
Simon Giesecke
Ricky Stewart
Bogdan Tara
Dorel Luca
Razvan Maries
Tilden Windsor
Mirko Brodesser
Sylvestre Ledru
Simon Van Accoleyen
Mihai Alexandru Michis