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
Following tests are disabled
- browser_protectionsUI_cookies_subview.js
- browser_protectionsUI_state.js
- browser_allowListNotifications.js
- browser_urlDecorationStripping.js
The reason that this tests are failing in fission mode is because in
window64 opt mode, additional content blocking event is triggered when
loading chrome:://global/skin/icons/resizer.svg
We don't have this problem before because in this case, we couldn't get the
top-level window, so the event was not fired.
But the recent working to make anti-tracking fission compatible (Bug 1624552) removes
the need of getting top-level window, so the event is fired and
testcases don't expect that.
Differential Revision: https://phabricator.services.mozilla.com/D72601
Refer to bug 1630781 comment 11 for a more detailed explanation of the problem.
A quick summary is that prior to this patch, the sampling operation involved
these steps:
- sample stored APZ state for composition
- advance animations to next vsync
- update stored APZ state to the one just computed
When sampling occured twice within a vsync interval, the stored APZ state
calculated at the end of the first sampling would be produced in the second
sampling, resulting in non-smooth scrolling. Note that the second and third
steps would only run once per vsync interval, but that was sufficient to cause
the problem.
With this patch, the order of the steps is reordered:
- update stored APZ state to that computed in the last vsync interval
- advance animations to next vsync and save it in the queue
- sample stored APZ state for composition
With this ordering (and with the first two steps only running once per vsync
interval), the third step now emits consistent data even if the steps are run
multiple times in a vsync interval. It does mean that the mSampledState deque
can have up to two items in it (front() being the state for the current vsync
interval, and back() being the state computed for the next vsync interval).
Although this problem only affected the WR codepath in practice, it could in
theory occur with the non-WR codepath too, if we for some reason ran the
TransformShadowTree code multiple times in a vsync interval. This patch updates
both codepaths with the new order of steps.
Differential Revision: https://phabricator.services.mozilla.com/D72046
Again, functionally this is a no-op since instead of replacing the back()
element, we do an emplace_back() followed by a pop_front().
Differential Revision: https://phabricator.services.mozilla.com/D72044
The deque always has size 1, so this patch is functionally a no-op. It sets up
the usage of front() and back() to allow holding more than one item in a future
patch.
Depends on D72042
Differential Revision: https://phabricator.services.mozilla.com/D72043
No functional changes intended here, just code getting moved into a helper
class. Note that this patch folds RecalculateCompositedLayoutViewport into
ClampCompositedScrollOffset since there are no longer any independent callers
of the former function (as of bug 1627716).
Depends on D72041
Differential Revision: https://phabricator.services.mozilla.com/D72042
No functional change, since everything was safe already. But this propagates
the proof-of-lock a little further to make it more obvious that fields are
safely accessed.
Depends on D72040
Differential Revision: https://phabricator.services.mozilla.com/D72041
Having to think about multiple codepaths adds complexity and it doesn't seem
like we're going to turn this pref back off anytime soon.
Differential Revision: https://phabricator.services.mozilla.com/D72040
This patch trades a bit of CSS code duplication for the sake of making styles more independent and less prone to break.
- Remove usage of `devtools-button` in the toolbox's toolbar.
- Create a ad-hoc `devtools-tabbar-button` style specifically for the toolbox icon buttons.
Differential Revision: https://phabricator.services.mozilla.com/D72488
This adds the last remaining explicit API for defining clips of
a specific type, and ports wrench and examples to use them.
Differential Revision: https://phabricator.services.mozilla.com/D72284
This allows defining rectangle clips directly, rather than via
the generic clip region methods.
This patch doesn't make use of it in Gecko yet, but it will do
once we add the remaining rounded rect API.
Differential Revision: https://phabricator.services.mozilla.com/D72268
Turn on some tests for InputConnection's behaviors. `inputConnection_setSelection` and `inputConnection_bug1133802` are still disabled due to Gecko issue and no good events.
Although I repeat 30 times to run this after this, no error now.
Differential Revision: https://phabricator.services.mozilla.com/D71151
The problem in https://bugzilla.mozilla.org/show_bug.cgi?id=325392 was
misdiagnosed and then a generic fix in
https://bugzilla.mozilla.org/show_bug.cgi?id=485834 (the kungFuDeathGrip
in nsObserverService::RemoveObserver) was based on the wrong diagnosis.
The root problem in bug 325392 was not that we were calling
nsObserverService::RemoveObserver from the destructor, and then
reentering the destructor. The refcounting code stabilizes the refcount
to 1 before calling the destructor to avoid reentering a destructor. The
real problem was that we were deleting an XPCOM object manually after
creation but without ever holding a strong reference to it, and so not
going through the refcount stabilization (and then the destructor can
reenter of course).
The generic fix in bug 485834 was based on the spotfix in bug 325392,
that was then backed out when the proper fix for that bug landed. I
don't think we should keep this kungfuDeathGrip, I ran into it because
it causes issues with refcount logging (refcount logging always had an
issue with refcounting from a destructor).
Differential Revision: https://phabricator.services.mozilla.com/D72300
Due to the refactored code,
browser/base/content/test/performance/browser_preferences_usage.js started
reporting more accesses to browser.cache.check_doc_frequency preference.
Differential Revision: https://phabricator.services.mozilla.com/D68319
The `webext_storage_bridge` crate introduced in this commit bridges the
`mozIExtensionStorageArea` XPCOM interface to the `webext_storage` Rust
component from Application Services.
This commit factors out the following parts from bug 1623245, so that
we can land them piecemeal:
* The `mozIExtensionStorageArea` interfaces, which implement all the
methods needed to support the `storage.sync` API.
* A Rust implementation of the above, in `StorageSyncArea`.
* A `StorageTask` type, for dispatching storage operations to a
background task queue.
* A `LazyStore`, which wraps the Rust component's `Store` and lazily
initializes it on the background queue the first time it's used.
* A `StorageSyncService`, which is our singleton. It holds on to a
configured `StorageSyncArea`, and hands out references to it via
`getInterface`. Eventually, we'll extend this to support syncing,
too.
Differential Revision: https://phabricator.services.mozilla.com/D71897
Hooray, our first Application Services Rust component! This is a
mechanical run of `mach vendor rust`, split out into its own commit
to make reviewing the Firefox bindings easier.
Differential Revision: https://phabricator.services.mozilla.com/D71895
