A UAX29 compatible word breaker (like ICU4C) treat the end of text as a
word break opportunity (rule WB2 [1]), but currently lwbrk word breaker
doesn't.
The motivation of this patch is to make `WordBreaker::Next()` closer to
a UAX29 compatible one (at least for English text), and see if the
callers need to change. This should make the future integration of ICU4X
segmenter easier.
The only caller of WordBreaker::Next() is ClusterIterator's constructor.
This patch shouldn't change its behavior because we've already manually
assigned a word break point at the end of the line when `aContext` is
empty and `aDirection` is -1. This patch generalizes it to all
conditions.
Also, update TestPrintWordWithBreak() so that the result string makes
more sense.
[1] https://www.unicode.org/reports/tr29/#WB2
Differential Revision: https://phabricator.services.mozilla.com/D124304
Here are the changes in this patch. They shouldn't change the behavior.
* Rename the gtest to `TestBreak.cpp` because it also contains word break tests.
* Align ruler comments to the test strings.
* Rename `lb` to `wb` in `TestASCIIWB`.
* Remove unused variable `j` in `TestPrintWordWithBreak()`.
* Use `ArrayLength` instead of `sizeof` trick to get the array length.
* #include ArrayUtils.h, and sort the #includes statements.
Differential Revision: https://phabricator.services.mozilla.com/D124303
We leave the following ones unchanged:
- geckodriver because the results are used to releases on github.
- sixgill because the script that creates it is not in-tree.
- *-dist-toolchain because sccache is not expecting a .tar.zst.
We use native tar support in most cases, except for toolchain scripts also
used on Windows, for which we use our zstdpy script.
Differential Revision: https://phabricator.services.mozilla.com/D124733
This avoids always posting a NSEvent to the event loop everytime we run a
non-native event. Servicing native NSEvents appears to have quite a high
overhead and causes us to commit a CoreAnimation transaction and communicate
with the WindowServer for every Gecko event. This change should also reduce the
CPU usage of the WindowServer process.
It appears that we still need to post an NSEvent when we're in a nested event loop
or when we're shutting down, but those situations are uncommon.
Differential Revision: https://phabricator.services.mozilla.com/D124857
We leave the following ones unchanged:
- geckodriver because the results are used to releases on github.
- sixgill because the script that creates it is not in-tree.
- *-dist-toolchain because sccache is not expecting a .tar.zst.
We use native tar support in most cases, except for toolchain scripts also
used on Windows, for which we use our zstdpy script.
Differential Revision: https://phabricator.services.mozilla.com/D124733
Historically, client.mk was not invoked with -jn because it would create
race conditions, but that was actually mostly solved by the addition of
`.NOTPARALLEL` in bug 422986, although the mechanism of adding -jn via
`MOZ_MAKE_FLAGS` or `MOZ_PARALLEL_BUILD` has continued well past that.
Nowadays, client.mk is only invoked by mach (it will even bail out if
that's not the case) and only has one target (`build`) and no
dependencies.
This means we don't need to rely on `MOZ_PARALLEL_BUILD` to pass `-jn` in
some cases, and can just always invoke `make -f client.mk` with `-jn`, even
when we just want no parallelism, in which case we can use `-j1`.
This, in turn, allows to remove the extra allow_parallel argument to
`_run_make`, and only rely on `num_jobs`, and to remove some of the
multiple ways the `n` in `-jn` could be set.
Differential Revision: https://phabricator.services.mozilla.com/D124729
It was moved in bug 1495798 for rusttests, because they didn't use
client.mk, but as of bug 1683797, they do. And it turns out that when
sccache is really started as originally intended, inheriting the make
jobserver, the build is dead-locked until sccache quits (because sccache
still has a jobserver token for some reason). But sccache never quits
when we make it stop outside client.mk.
Differential Revision: https://phabricator.services.mozilla.com/D124728
Both work, but the former is preferred. Also remove MOZ_MAKE_FLAGS
in the mozconfig example for msan, because it's irrelevant.
Differential Revision: https://phabricator.services.mozilla.com/D124726
This adds a `quickSuggestScenario` Nimbus variable.
We could use the `quickSuggestShouldShowOnboardingDialog` variable to
distinguish between offline and online on the client, since offline won't get
the onboarding but online will. However, using a separate variable would be
clearer and possibly less confusing for stakeholders, and it would also allow us
to have finer control over the onboarding prompt if we need it.
We'll need to distinguish between the two scenarios on the client for telemetry
pings, tweaks to the preferences UI, and possibly other things.
Differential Revision: https://phabricator.services.mozilla.com/D124844
Without the pref enabled, DocumentLoadListener is destroyed when
DocumentChannelParent is destroyed. With the pref enabled, we create
DocumentLoadListener when we are trying to do a parent controlled navigation,
but it does not get destroyed anywhere. To do that, we can disconnect the
DLL listeners before we trigger redirection to the real channel and resume the
load.
Differential Revision: https://phabricator.services.mozilla.com/D122131
When tapping accessiblecaret and moving/releasing it, the follow error occurs.
```
GeckoViewContent[C]: handleEvent: mozcaretstatechanged
Web Content: [JavaScript Error: "TypeError: can't access property "sendRequest", this.eventDispatcher is undefined" {file: "resource:///actors/GeckoViewContentChild.jsm" line: 291}]
Web Content: handleEvent@resource:///actors/GeckoViewContentChild.jsm:291:11
```
I think that we miss super.actorCreated() call in actorCreate(). This might be
regression by bug 1661480.
Differential Revision: https://phabricator.services.mozilla.com/D124639
This commit makes several tweaks to memory reporting for wasm memory.
* Add a field for shared wasm memory and track it in SAB.
- Before this commit, shared wasm memory wouldn't report its guard pages but should.
* Track wasm guard pages in RuntimeSizes, not ClassInfo
- We want wasm guard pages to show as a top-level memory report item, similar to vmem,
and not under the owning array object. Displaying under the owning object bloats the
tree of memory usage with large amounts of memory that's only reserved and not
committed, which is confusing. Before this commit the class info reporter would
try to make this happen, but this approach was broken and the simplest fix is to
track this on RuntimeSizes and report the value from their.
* Only add wasm memory if the buffer is attached. Detached buffers may still be live
but no longer own the wasm heap and shouldn't report their old size.
Differential Revision: https://phabricator.services.mozilla.com/D124390
