There is a race condition in which the TableWidget was trying to sort values that are no longer available in the table itself, if we change the contents of the table too quickly. This patch should also fix Bug 1696727
Differential Revision: https://phabricator.services.mozilla.com/D122970
The test function in helper_touch_action_regions.html needs to run as a
generator function, which means it doesn't work with async/await manners, so
once after we make some utility functions as async, it won't work as expected.
To avoid it, getting the scroller position in the screen coords part needs to
be split out from the generator since the part will be async in the next commit,
and nsIDOMWindowUtils.sendNativeTouchPoint needs to be used directly instead of
using synthesizeNativeTouch since synthesizeNativeTouch will also be async.
Differential Revision: https://phabricator.services.mozilla.com/D122558
It does not check whether it meets a non-editable parent or not. Therefore,
it may cross another editing host boundary when `aContent` is in a nested
editing host.
So, this patch fixes some edge cases when editing hosts are nested and
scanning from inner editing host.
Differential Revision: https://phabricator.services.mozilla.com/D122940
There are a lot of ancestor scanners in `HTMLEditUtils`. This is good thing
for the performance, but it makes us hard to maintain. Therefore, we should
merge them as far as possible.
Differential Revision: https://phabricator.services.mozilla.com/D122939
It's more appropriate because the running times are only relevant to a profiling session.
And PreviousThreadRunningTimes can now be accessed through the ThreadRegistration (thanks to the ProfiledThreadData pointer added in the previous patch).
Since the threads' RunningTimes don't live in `PlatformData`, and because they are now implicitly cleared between profiling sessions (because `ProfiledThreadData`s get destroyed/recreated when stopping/starting the profiler), there is no need for an explicit `ClearRunningTimes()` anymore.
Differential Revision: https://phabricator.services.mozilla.com/D121964
Because ProfiledThreadData is always related to IsBeingProfiled, they are set and cleared together.
In particular, this is used to quickly guess that the thread is being profiled by reading the non-atomic mProfiledThreadData, rather than reading the slightly slower atomic mIsBeingProfiled.
Differential Revision: https://phabricator.services.mozilla.com/D121963
This is mostly a copy of the old PlatformData. That old PlatformData will be removed in a later patch, once it's not used anymore.
Differential Revision: https://phabricator.services.mozilla.com/D121959
This will help with replacing the old {,Racy}RegisteredThread with the new ThreadRegistration classes, while still being able to access the old classes (until they are not needed anymore).
Differential Revision: https://phabricator.services.mozilla.com/D121849
Now {,Racy}RegisteredThread don't contain any data, but provide the same API that goes through ThreadRegistration.
Until they are removed, {,Racy}RegisteredThread are given private access to ThreadRegistration{,Data} for easier access.
This means that we can now change uses of RegisteredThread to use ThreadRegistration directly instead, and the data will be the same through either APIs.
Also, RacyRegisteredThread::ThreadId() was unused so it can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D121847
The ProfilingStack object inside ThreadRegistrationData is guaranteed to live while the thread is registered (and alive), and all accesses are guaranteed to be done either:
- On-thread, so during that time ThreadRegistrationData and its ProfilingStack cannot be destroyed.
- From another thread, but with the Profiler lock and/or per-thread lock, which also guarantees that ThreadRegistrationData and its ProfilingStack cannot be destroyed.
RacyRegisteredThread brought some doubts about end-of-thread accesses, that why there's was an intermediate ref-counted ProfilingStackOwner to keep ProfilingStack alive where needed. Now we can remove it.
Also the separate TLS (Thread Local Storage) for ProfilingStackOwner can be removed, since we can reach the ProfilingStack through the ThreadRegistration TLS for the same cost.
Differential Revision: https://phabricator.services.mozilla.com/D121846
Since ThreadRegistration already handles nested registrations, the legacy profiler_{,un}register_thread() functions don't need to care about that anymore (and the RegisteredThread TLS will be removed in a later patch anyway).
The informational markers have been moved to ProfilerThreadRegistration.cpp.
Differential Revision: https://phabricator.services.mozilla.com/D122315
ProfilerThreadRegistry (un)register functions have been moved to platform.cpp because they need to interact closely with functions and classes in that file.
profiler_{,un}register_thread are now simple calls to ThreadRegistration::{R,Unr}egisterThread, which call ThreadRegistry::{R,Unr}egister, which now integrate that old bodies of profiler_{,un}register_thread.
So from this point, threads may use either profiler_{,un}register_thread or ThreadRegistration equivalents, and this will (un)register with both the new ThreadRegistration classes and the legacy RegisteredThread class into CorePS. (Later patches will remove RegisteredThread completely.)
Bonus: Since the stack top is now adjusted when constructing ThreadRegistrationInfo (before giving it to the legacy ThreadInfo), there is no more need for `GetStackTop()`.
Differential Revision: https://phabricator.services.mozilla.com/D121844
Thread-related APIs that are currently in ProfilerState.h will move here, and will use the new ThreadRegistration classes introduced in bug 1721939.
In this patch the header is empty apart from a few #includes, and users of "ProfilerState.h"'s thread functions now #include "ProfilerThreadState.h" instead. So there are no actual code changes yet.
Differential Revision: https://phabricator.services.mozilla.com/D121843
This introduces a new `result.isSuggestedIndexRelativeToGroup` property. When
true, `result.suggestedIndex` is relative to the result's group.
We can get rid of some hardcoded quick-suggest things with this.
I considered a `relativeSuggestedIndex` property that would replace
`suggestedIndex`, but it would have made `muxer._addSuggestedIndexResults` a
little more complex because it would need to know whether it should use
`relativeSuggestedIndex` or `suggestedIndex`. `UrlbarView._rowCanUpdateToResult`
would also need to be updated since it checks for suggestedIndex results. But
there are trade-offs either way and I'm open to using `relativeSuggestedIndex`.
While working on this I noticed that we broke the position of quick suggest
results in bug 1662167. They're supposed to be last in the outer general group,
and currently the muxer is hardcoded to put them last in `GENERAL`, but after
that bug `INPUT_HISTORY` actually comes last. To fix that I added a new
`GENERAL_PARENT` group that's used for the outer general group. Quick suggest
results now use this group, combined with a relative `suggestedIndex`, to come
last. I wanted to rename `GENERAL` to `PLACES` or `BOOKMARKS_HISTORY` and use
`GENERAL` for the outer group, but we use `GENERAL` in a ton of places (tests
especially) and I didn't want to touch blame for it all. I'm open to better
names than `GENERAL_PARENT`. I considered `FIREFOX_SUGGEST` but I don't think
it's a good idea to tie it to specific branding that may change.
Differential Revision: https://phabricator.services.mozilla.com/D122799
Edgar Chen
Belén Albeza
Tooru Fujisawa
Hiroyuki Ikezoe
Masayuki Nakano
Brindusan Cristian
Mike Hommey
Gerald Squelart
Botond Ballo
Noemi Erli
Drew Willcoxon
James Teh
Kajal Sah
Marian-Vasile Laza
Jon Bauman