We have rendering artifacts when sceen scale is set and damage size/position is odd number.
It's caused by round error so update the size/position accordingly.
Differential Revision: https://phabricator.services.mozilla.com/D26903
--HG--
extra : moz-landing-system : lando
Bug 304860 and bug 1364364 have disabled the bfcache for subframes, so we only
store the contentviewer in the root entry.
Depends on D25761
Differential Revision: https://phabricator.services.mozilla.com/D25763
--HG--
extra : moz-landing-system : lando
Depends on D26900
Fixes the blank chart and load issues for the old perf panel in about:devtools-toolbox (or type=content)
Differential Revision: https://phabricator.services.mozilla.com/D26919
--HG--
extra : moz-landing-system : lando
Depends on D26899
This test would timeout with the fix in the previous patch
Differential Revision: https://phabricator.services.mozilla.com/D26900
--HG--
extra : moz-landing-system : lando
Follow up to 1524982. We started using the browserloader to load almost all perf panel files.
However we kept two async methods in the js file loaded by performance/index.xul, which defeated the purpose.
Differential Revision: https://phabricator.services.mozilla.com/D26899
--HG--
extra : moz-landing-system : lando
Add addtest support for per-suite arguments and multiple files. Also
support opening the created test in an editor. This allowed supporting
the wpt suite and replaces `mach wpt-create`.
# Create a wpt test
./mach addtest testing/web-platform/tests/accelerometer/test.html
# Create a wpt reftest
./mach addtest --suite wpt-reftesttesting/web-platform/tests/css/example.html --ref example-ref.html
The files created will be opened in the default editor if --editor is
supplied or a specified editor if the argument is given a value.
Differential Revision: https://phabricator.services.mozilla.com/D26339
--HG--
extra : moz-landing-system : lando
YouTube.com/tv uses YouTube specific extensions to MediaSource.isTypeSupported
in order to determine whether it serves 4K. It checks with bogus values, and if
we reject the bogus values, it assumes we're responding truthfully to the other
queries. So add support to reject the bogus values on YouTube.com.
With this patch, we can play 4K on YouTube.com/tv.
Differential Revision: https://phabricator.services.mozilla.com/D26655
--HG--
extra : moz-landing-system : lando
This is needed to open an SCO channel and do proper (low-latency) bluetooth
communication when doing a call using WebRTC, or simply recording local audio in
a web application.
I think this is more of a GeckoView thing, but I'm a bit fuzzy on the
distinction, maybe it's the wrong manifest. I tested using Fennec.
Differential Revision: https://phabricator.services.mozilla.com/D21734
--HG--
extra : moz-landing-system : lando
We also take account those values in the case of `Find in page`.
The corresponding web platform tests will be coming from this PR.
https://github.com/web-platform-tests/wpt/pull/8575
Though some of them will not be passed, the failure reason is not related
to this change, I will take a look when the PR gets merged into mozilla-central.
Differential Revision: https://phabricator.services.mozilla.com/D25915
--HG--
extra : moz-landing-system : lando
In the case where scroll-snap-type is specified for the scroll container, the
scroll-padding is also factored into in ScrollFrameHelper::ComputeScrollSnapInfo
which is called via ScrollFrameHelper::ScrollToWithOrigin. It doesn't double
the scroll-padding value, but it's actually redundant, we should avoid it.
We could separate the functionality of ScrollToWithOrigin, one is to scroll
to a given element, the other is to scroll to a given position. The former will
be used for Element.scrollIntoElement and relevant stuff, the latter will be
used for Element.scrollTo and relevant stuff. That's being said, as of now, we
have still the old scroll snap implementation, so the separation will introduce
complexity, the separation should be done once after the old implementation
removed.
There are 9 call sites of nsIPresShell::ScrollContentIntoView:
nsIPresShell::GoToAnchor
nsIPresShell::ScrollToAnchor
Element::ScrollIntoView
We definitely needs scroll-padding and scroll-margin for these functions.
nsCoreUtils::ScrollTo
This is used for Accesible::ScrollTo which scrolls to a given accesible node,
probably we should behave as what Element::ScrollIntoView does.
Accessible::DispatchClickEvent
Similar to the above, similated various mouse events on a given target node.
PresShell::EventHandler::PrepareToUseCaretPosition
PresShell::EventHandler::GetCurrentItemAndPositionForElement
Both are for context menu, we shouldn't consider scroll-padding and
scroll-margin.
nsFormFillController::SetPopupOpen
This is used for autocompletion popup, we shouldn't consider scroll-padding
and scroll-margin.
nsFocusManager::ScrollIntoView
This is bit unfortunate, we should use scroll-padding and scroll-margin
depending on call site of this function. Bug 1535232 is for this case.
cssom-view/scrollIntoView-scrollPadding.html which has some tests that is
actually testing scroll-padding with scrollIntoView passes with this change.
The reftest in this change is a test case that the browser navigates to an
element with specifying the anchor to the element.
Differential Revision: https://phabricator.services.mozilla.com/D23084
--HG--
extra : moz-landing-system : lando
As for scrolling on the compositor we don't cull out them since we don't know
the final snapport rect at the time when we send the information about
snapping to the compositor. And we will handle it for APZ in bug 1531589.
https://drafts.csswg.org/css-scroll-snap-1/#snap-scope
Depends on D21632
Differential Revision: https://phabricator.services.mozilla.com/D21633
--HG--
extra : moz-landing-system : lando
The snap alignment position of the target element is the top left of the target
and the position is located out of scroll port (top: -100px, left: -100px).
Even so we try to snap a position as much as possible.
From the spec [1];
If a snap position is unreachable as specified, such that aligning to it would
require scrolling the scroll container’s viewport past the edge of its
scrollable overflow region, the used snap position for this snap area is the
position resulting from scrolling as much as possible in each relevant axis
toward the desired snap position.
[1] https://drafts.csswg.org/css-scroll-snap-1/#unreachabLe
Depends on D21630
Differential Revision: https://phabricator.services.mozilla.com/D21631
--HG--
extra : moz-landing-system : lando
https://drafts.csswg.org/css-scroll-snap-1/#scroll-snap-align
The main logic here is basically same as the old scroll snap implementation,
just iterating over all descendant elements in the scroll container and collect
snap positions. The differences are;
1) the snap positions are specified based on descendant elements instead of
points
2) the snap positions are able to be specified by `block` or `inline` keywords
so that we also need to care the element flow.
more test cases for this are coming in the next commit
3) the target rect is calculated by nsLayoutUtils::TransformFrameRectToAncestor
which means transform is already taken account into it (we have a bug for
the old scroll snap, it's bug 1218745)
some of web platform tests will be added in a subsequent commit
Some of test cases in overflowing-snap-areas.html that accidentally have
passed start failing with this change, all of them will be passed with
subsequent changes in these commit series.
Depends on D21627
Differential Revision: https://phabricator.services.mozilla.com/D21628
--HG--
extra : moz-landing-system : lando
From the spec [1];
Using the scroll-snap-type property on the relevant scroll container, the
author can request a particular bias for the scrollport to land on a snap
position after scrolling operations (including programmatic scrolls such
as the scrollTo() method).
The target here are functions exposed in web contents other than
Element.scrollIntoView which will be changed in the next commit.
[1] https://drafts.csswg.org/css-scroll-snap-1/#overview
Depends on D21624
Differential Revision: https://phabricator.services.mozilla.com/D21625
--HG--
extra : moz-landing-system : lando
Given the test description is mentioning scrollBy, scrollBy should be used
there.
Depends on D21623
Differential Revision: https://phabricator.services.mozilla.com/D21624
--HG--
extra : moz-landing-system : lando
The right top element is positioned at left:1000px and its width is 600px and
the width of the largest element in the content is 2100px. So if the browser
window width (precisely documentElement clientWidth) is greater than 1100px, the
right top element is not suitable for scroll-snap-align:start, thus some test
cases fail.
Differential Revision: https://phabricator.services.mozilla.com/D21623
--HG--
extra : moz-landing-system : lando
