If the root scrollframe has the zoomable flag set, it automatically returns
true from WantAsyncScroll which makes it the "primary" scrollframe, and
automatically gets a displayport. However, this can be undesirable in cases
where the root scrollframe is not actually scrollable (i.e. document content
doesn't overflow) because we don't actually need that displayport on the root
scrollframe and instead want it on a scrollframe that is actually scrollable.
This patch removes the behaviour of WantAsyncScroll returning true for such
scrollframes, but maintains the layerization changes needed to support zooming.
This reduces the set of differences between running with apz.allow_zooming on
and off, which in turn eliminates a bunch of test failures when that pref is
enabled.
Depends on D82777
Differential Revision: https://phabricator.services.mozilla.com/D82778
If the scrollable div ends up as the first-encountered scrollframe, it gets a
big displayport that is just over 5000px CSS pixels tall (on GeckoView). When we
check for images being "nearly visible" we expand that displayport further by a
pref-controlled multiplier, which ends up doubling the displayport height to
over 10000 CSS pixels. So for the image to actually get detected as outside the
"nearly visible rect" it needs to be positioned further down in the iframe.
This test was previously passing on GeckoView because the scrollable div was
not getting detected as the first-encountered scrollframe; the root scrollframe
for the top-level document was the one getting the displayport even though it
didn't really need it. A later patch in this bug changes the first-encountered
scrollframe, causing this test to fail without this patch.
Differential Revision: https://phabricator.services.mozilla.com/D82777
This patch was created in two stages:
1. Running the update script
2. Editing jstests.list to add the shell option to all tests added, and
skipping Proxy tests.
Differential Revision: https://phabricator.services.mozilla.com/D82608
The DISPATCH_QUEUE_PRIORITY_DEFAULT queue currently in use starts tasks as they
arrive rather than running tasks sequentially. By using a dedicated serial queue,
frames will be encoded and delivered in the order in which they are added to the
queue. It also makes it possible to post a task to the queue when video capture
is stopped, which can guarantee that all frames have been delivered before stop
completes. This should fix a crash we're seeing in DeliverCapturedFrame which
appears to be caused by racing between the main thread in Stop() and the capture
thread in captureOutput. The new queue is set to target the
DISPATCH_QUEUE_PRIORITY_DEFAULT, so tasks will still run there. This should give
us serial execution without the overhead of starting a new thread to manage our
queue.
The new upstream implementation creates a serial queue rather than using
DISPATCH_QUEUE_PRIORITY_DEFAULT. It also raises the priority of the queue above
default, but I think that should wait for a separate bug.
Differential Revision: https://phabricator.services.mozilla.com/D82721
It removes some invisible leading and/or trailing white-spaces when it inserts
`<br>` element into the invisible white-space sequence. It currently checks
whether the insertion point is in invisible leading and trailing white-spaces
or not with `FindNearestFragment()`, but we can do same thing with
comparing the insertion point with the result of
`TextFragmentData::GetInvisibleLeadingWhiteSpaceRange()` and
`TextFragmentData::GetInvisibleLeadingWhiteSpaceRange()`. However, current
implementation does not make sense because:
- It checks trailing white-spaces with `!IsEndOfHardLine()` and
`IsStartOfHardLine()`, but this means that it does ignores invisible
white-spaces which are the only content in a line.
- It checks leading white-spaces with `!IsStartOfHardLine()` and
`IsEndOfHardLine()`, so, this also ignores invisible white-spaces which
are the only content in a line.
- The important thing of the logic is prevent that invisible leading and
trailing white-spaces become visible with new `<br>` element, but this
is done only for trailing white-spaces.
Differential Revision: https://phabricator.services.mozilla.com/D82283
The change itself isn't important for us, because we don't use ICU's make-files,
but avoids confusion why additional changes were applied when running the update
script.
Differential Revision: https://phabricator.services.mozilla.com/D82545
Currently we're converting the configuration url parameters to strings in makeEngineFromConfig via URLSearchParams. We then pass them through URLSearchParams again in _initEngineURLFromMetaData.
Depends on D82525
Differential Revision: https://phabricator.services.mozilla.com/D82583
The main aim here is to move the call to getEngineParams that currently happens before addEngineWithDetails. This is moved into addEngineWithDetails, so that it is next to where the search engine is actually created. This gets ready for the next step which will be to merge getEngineParams with the SearchEngine initWithMetadata and associated calls.
The side effects are that we need a specific function for policy engines to use, and that we now have only tests using addEngineWithDetails.
Differential Revision: https://phabricator.services.mozilla.com/D82348
Kartikaya Gupta
ffxbld
Matthew Gaudet
emcminn
Lennart Grahl
Andrew Halberstadt
Chris H-C
David Major
Nicolas Chevobbe
Andrea Marchesini
Andi-Bogdan Postelnicu
Razvan Maries
Itiel
Henrik Skupin
Dimi Lee
Kershaw Chang
Dan Minor
Dão Gottwald
Tom Schuster
Masayuki Nakano
Sebastian Streich
André Bargull
pbz
Mark Banner
Andreea Pavel
Tooru Fujisawa
Mirko Brodesser