This test sets the pref `dom.text_fragments.enabled` to true for
web-platform tests in
- /scroll-to-text-fragment
- / css/css-pseudo (which contains various tests for `::target-text`
Differential Revision: https://phabricator.services.mozilla.com/D195690
This patch integrates the algorithm to find a text fragment range
into the document loading mechanism.
Unlike described in the spec, the fragment directive is not stripped
from the URL in the Session History Entry, instead it is stripped when
setting the URI into the Document using `Document::SetURI()`,
as well as when accessing the URL through `Location`.
The `PresShell` class is extended by a new method which sets the
ranges created from the text directives into the FrameSelection as
TargetText selection and scrolls it into view.
Security restrictions like force load at top and cross-origin iframes
are not yet considered in this patch.
Differential Revision: https://phabricator.services.mozilla.com/D195688
This patch implements the `::target-text` pseudo element.
Similarly to the Custom Highlight API, this is done implementing
a new Selection type.
Differential Revision: https://phabricator.services.mozilla.com/D195687
Main part of this patch is an implementation of the algorithm defined
in the spec [0].
The algorithm takes an array of `TextDirective` (which is the result of
the fragment directive parser implemented in part 2 of this bug)
and converts it into an array of `nsRange`s.
The algorithm is not optimized for performance yet.
Instead it follows the spec very closely.
Therefore, it may for now only be seen as a baseline to a faster `nsFind` based approach.
The algorithm differs from the spec, using a standard `nsString::Find()`
instead of the mentioned collator-based search, i.e.
performing a case-sensitive and locale-independent search.
[0]: https://wicg.github.io/scroll-to-text-fragment/
Differential Revision: https://phabricator.services.mozilla.com/D195686
This patch provides functions to extract the fragment directive from a url / a hash
into an array of `TextDirective`s
as well as to create a fragment directive string from given text directives.
The algorithms are implemented as a rust crate.
Interface functions and data structures which are accessible from C++
are provided in `lib.rs`.
The actual implementation (using pure rust types)
lives in `fragment_directive_impl.rs`, tests live in `test.rs`.
The implementation currently only supports text directives.
Other future directive types are not considered and will be ignored.
The main function, `parse_fragment_directive()` takes a url / a url hash
as parameter and returns (as out parameter) a struct which contains the stripped input url,
the fragment directive string, and an array of parsed text directive objects.
Additionally, there are functions that create a full fragment directive string
from a list of text directives as well as a function that creates
a single text directive string from a text directive.
The `TextDirective` class, which is shared with C++, contains four
string elements for the prefix, start, end and suffix elements.
These strings are percent-decoded and do not contain identifiers
(like the `-` that indicates it being a prefix or suffix).
All elements besides `start` can be empty.
The implemented algorithms are used in the following patches.
Differential Revision: https://phabricator.services.mozilla.com/D195685
This patch should only impact how `ContentSubtreeIterator` uses `ContentIteratorBase<NodeType>::GetDeepFirstChild`
because `IteratorHelpers::GetShadowRoot` can only return non-null with
ContentSubtreeIterator. Secondly, `ContentSubtreeIterator` only uses this
method with
`ContentSubtreeIterator::DetermineCandidateForFirstContent`, so we are
talking about getting the deepest first child for the first content candidate.
If the first content candidate is a shadow host with web exposed shadow
root, we should always use the first child of this shadow root rather than the
child of this content in light DOM.
Differential Revision: https://phabricator.services.mozilla.com/D206552
When calling MoveToAnotherPendig the record gets removed from the
pending queue, and InsertRecord is called. As InsertRecord again
increments mPendingCount, we need to decrement it when removing from
a pending queue to ensure it's accurate.
Depends on D206498
Differential Revision: https://phabricator.services.mozilla.com/D206503
The issue here is only obvious on Windows, when network.dns.get-ttl=true
and network.dns.native_https_query=true.
GetTTL will cause another resolution to happen with a low priority,
but these don't get picked up unless
mActiveAnyThreadCount < MaxResolverThreadsAnyPriority()
This causes the DNS_NATIVE_QUEUING probe to increase since these
queries don't get picked up immediately.
Also decrementing mActiveAnyThreadCount for ByType records makes
sure it always has the correct value.
Differential Revision: https://phabricator.services.mozilla.com/D206498
Parallelization is process based, which implies a pickle-compatible IR,
thus the few code changes.
It is mandatory to serialize the IR only once per process for the
parallelization to be beneficial.
The parsing is still single-threaded.
Differential Revision: https://phabricator.services.mozilla.com/D205053
position: sticky items scroll independently of their containing
content, resulting in large amounts of picture cache invalidation when
scrolling, causing poor performance. This patch attempts to give them
their own picture cache slice in order to avoid that invalidation.
Differential Revision: https://phabricator.services.mozilla.com/D206502
We know that we frequently hit this limit and so, based on observed performance improvements in sub-resource connection times, we are increasing it to 20.
Note that this is very conservative as on desktop we see no sign of overall socket pool exhaustion.
See https://bugzilla.mozilla.org/show_bug.cgi?id=1819556
Android changes will follow as we currently have a much smaller overall socket pool on that platform.
Differential Revision: https://phabricator.services.mozilla.com/D206406
Sorry for the massive patch but I found it hard to split without
introducing a bunch of copies around...
This mostly makes necko and DOM agree on which strings to use, which
should result on less copies and conversions.
Differential Revision: https://phabricator.services.mozilla.com/D205601
Before the fix, Accessibility Scanner was showing the color contrast
between text color and the background color as insufficient.
With the modification made the accessibility scanner shows the
problem as fixed. The color that was used for the fix is the closest to
the one before that can satisfy the contrast required.
Before
{F6465923}
After
{F6465924}
Differential Revision: https://phabricator.services.mozilla.com/D206365
The toolbar height includes the top border now. It's not what we want
anyways:
* In some cases its usage was completely redundant (we can use the
default static position).
* In other cases what we want is the urlbar-container height, which
doesn't include that border. I confirmed this looks good in compact
mode (which was the reason for introducing this in bug 1580248).
So simplify the code a tiny bit and fix the flickering that got the
original version reverted.
Differential Revision: https://phabricator.services.mozilla.com/D206596
This relands the simplification that was reverted in bug 1647356, which
made it so that the border takes space, with a key tweak.
The border taking space is generally good and simplified some code, but
it causes uneven spacing around the urlbar if we set the separator color
to transparent (like many even builtin themes do).
This is technically already an issue if a theme sets the
`chrome-content-separator-color` to transparent, but I think that's
really uncommon, and we don't want to encourage themes to suppress that
separator IMO... We might want to forbid that even somehow?
So for now only handle the tabs separator. Clean-up some adjacent code
while at it.
An alternative would be to keep the shadow, and add some comments as for
why it's a shadow and not a border, but that seems to subtly complicate
layout in other places (which were working around it before the
regressing bug).
Differential Revision: https://phabricator.services.mozilla.com/D206547
The test weren't spawning the DevToolsServer the same way as in production.
--start-debugger-server spawns the server in the distinct devtools global in order to be able to debug privileged compartment.
Differential Revision: https://phabricator.services.mozilla.com/D206497
