This reverts the changes from bug 1481593 / bug 1317870 which broke
the default rendering on Android only (since it doesn't have
a native theme for <input type=range>).
Differential Revision: https://phabricator.services.mozilla.com/D47345
--HG--
extra : moz-landing-system : lando
Unclear whether the visual viewport code path is the right thing to do at all.
Differential Revision: https://phabricator.services.mozilla.com/D47791
--HG--
extra : moz-landing-system : lando
Avoid intermittent test failures on android.
The existing android assertion count was introduced by bug 1405550, to avoid
assertion count failures with stylo.
Differential Revision: https://phabricator.services.mozilla.com/D47792
--HG--
extra : moz-landing-system : lando
This moves the origin of fallback blobs back to the top left of their display
item bounds. This is what they were before the patches in bug 1568227 and makes
more sense because there's not necessarily a reference frame above the fallback
frame which means that the coordinates of the display item can change without
us wanting to invalidate the interior.
Differential Revision: https://phabricator.services.mozilla.com/D47275
--HG--
extra : moz-landing-system : lando
Mostly renaming for clarity, as the gradient parsing code is a bit hairy.
This also changes -webkit- gradients, which is, I think, the right thing to do
(otherwise I need to give up on the type system and sprinkle parse_non_negatives
around, which would be unfortunate).
I filed https://bugs.chromium.org/p/chromium/issues/detail?id=1008112 on
Chromium still accepting negative radii for those, so will wait to submit the
patch for review until they reply there with their intentions.
Differential Revision: https://phabricator.services.mozilla.com/D47141
--HG--
extra : moz-landing-system : lando
Once this patch lands, all content drawn by WebRender is drawn into
a picture cache surface.
This will incur some extra GPU memory overhead since there are extra
GPU texture buffers. Much of this can be reduced by adding a couple
of simple optimizations in future to detect tiles that are solid
colors only.
With this change, we'll now be able to provide exact dirty rects for
the entire screen without any hacks, and start the work to draw into
OS compositor surfaces directly.
Differential Revision: https://phabricator.services.mozilla.com/D47395
--HG--
extra : moz-landing-system : lando
This means that you can use it as a very light-weight crashtest harness by
using:
MOZ_GDB_SLEEP=0 ./mach run -layoutdebug <file> -autoclose
Right now we just never exit otherwise.
Differential Revision: https://phabricator.services.mozilla.com/D47715
--HG--
extra : moz-landing-system : lando
This moves the origin of fallback blobs back to the top left of their display
item bounds. This is what they were before the patches in bug 1568227 and makes
more sense because there's not necessarily a reference frame above the fallback
frame which means that the coordinates of the display item can change without
us wanting to invalidate the interior.
Differential Revision: https://phabricator.services.mozilla.com/D47275
--HG--
extra : moz-landing-system : lando
This means that you can use it as a very light-weight crashtest harness by
using:
MOZ_GDB_SLEEP=0 ./mach run -layoutdebug <file> -autoclose
Right now we just never exit otherwise.
Differential Revision: https://phabricator.services.mozilla.com/D47715
--HG--
extra : moz-landing-system : lando
Once this patch lands, all content drawn by WebRender is drawn into
a picture cache surface.
This will incur some extra GPU memory overhead since there are extra
GPU texture buffers. Much of this can be reduced by adding a couple
of simple optimizations in future to detect tiles that are solid
colors only.
With this change, we'll now be able to provide exact dirty rects for
the entire screen without any hacks, and start the work to draw into
OS compositor surfaces directly.
Differential Revision: https://phabricator.services.mozilla.com/D47395
--HG--
extra : moz-landing-system : lando
Once this patch lands, all content drawn by WebRender is drawn into
a picture cache surface.
This will incur some extra GPU memory overhead since there are extra
GPU texture buffers. Much of this can be reduced by adding a couple
of simple optimizations in future to detect tiles that are solid
colors only.
With this change, we'll now be able to provide exact dirty rects for
the entire screen without any hacks, and start the work to draw into
OS compositor surfaces directly.
Differential Revision: https://phabricator.services.mozilla.com/D47395
--HG--
extra : moz-landing-system : lando
This means that you can use it as a very light-weight crashtest harness by
using:
MOZ_GDB_SLEEP=0 ./mach run -layoutdebug <file> -autoclose
Right now we just never exit otherwise.
Differential Revision: https://phabricator.services.mozilla.com/D47715
--HG--
extra : moz-landing-system : lando
We always check StyleWillChangeBits_TRANSFORM bit together with a
transform-like property set, so using WillChangeBits::TRANSFORM bit to
represent all transform-like properties is ok.
However, it seems the new test case works well even if we don't have this
patch. I still add it for individual transform properties to make sure
the test coverage is enough anyway.
Differential Revision: https://phabricator.services.mozilla.com/D47509
--HG--
extra : moz-landing-system : lando
Most of these tests have been disabled for a long time; they run well
in the current test environment.
Differential Revision: https://phabricator.services.mozilla.com/D47616
--HG--
extra : moz-landing-system : lando
This avoids frequent intermittent failures observed with changes to be made by
bug 1584290 (changes which appear unrelated to this test).
Differential Revision: https://phabricator.services.mozilla.com/D47615
--HG--
extra : moz-landing-system : lando
Doesn't recognize all the edge cases, but I think this should be good enough.
Let me know if you think something common is missing.
Differential Revision: https://phabricator.services.mozilla.com/D47469
--HG--
extra : moz-landing-system : lando
Doesn't recognize all the edge cases, but I think this should be good enough.
Let me know if you think something common is missing.
Differential Revision: https://phabricator.services.mozilla.com/D47469
--HG--
extra : moz-landing-system : lando
We have already called FlushDelayedResize(false) earlier in this method, and
after bug 1583534 that queues a reflow if one is needed. All the boolean
controls is whether reflows are processed by the FlushDelayedResize call.
Since we plan to process reflows anyway a few lines later, there is no need to
do that explicitly that via FlushDelayedResize(true).
Differential Revision: https://phabricator.services.mozilla.com/D47287
--HG--
extra : moz-landing-system : lando
multicol-span-all-margin-bottom-001.xht and multicol-span-none-001.xht
have been patched upstream. They should pass after we import from wpt.
DONTBUILD because this is a comment-only change.
Differential Revision: https://phabricator.services.mozilla.com/D47340
--HG--
extra : moz-landing-system : lando
I wanted to fix the more general problem and script-block more of
FlushPendingNotifications, but simple attempts to do that have resulted in
terribly orange try runs with very bizarre failures, so in the "perfect is the
enemy of good" spirit, fix the issue at hand (scroll anchoring adjustments not
dealing with layout reentering beneath them) by running them while
script-blocked, which is the right thing to do anyway.
Differential Revision: https://phabricator.services.mozilla.com/D47256
--HG--
extra : moz-landing-system : lando
That is, for the multicol container of depth two and more, we lay them
out by using "column-fill:auto" and "column-count:1".
I've check bug 725376 comment 9 for the previous approaches. Thanks to
bug 1555818, this solution is feasible because the fragmentation with
"column-fill:auto" is now possible.
Differential Revision: https://phabricator.services.mozilla.com/D47011
--HG--
extra : moz-landing-system : lando
Previously, the setup_picture_caching function was hard coded
to support only a very specific shape of display list. With this
change, flags are added to PrimitiveCluster that can specify
if a picture cache slice should be created before / after this
cluster when picture caching is set up.
The usage of these flags in this patch matches the old behaviour,
so should not have any functional effect.
However, in future we will make use of this functionality to
create picture slices for a number of different use cases, such as:
* Creating cache tiles for the UI.
* Slicing the scene where there are video elements, in order to
allow these to be composited directly by the OS. This may also
apply to WebGL and/or canvas elements.
* Slicing the scene when there is a very large fixed position
background image or other element, to avoid invalidating the
entire tile cache each frame.
Differential Revision: https://phabricator.services.mozilla.com/D46125
--HG--
extra : moz-landing-system : lando
Now all test cases for individual transform properties work fine on GeckoView.
Depends on D47200
Differential Revision: https://phabricator.services.mozilla.com/D47201
--HG--
extra : moz-landing-system : lando
I think these should hold, everything that runs under them should just schedule
other stuff to some later date:
* Synth mouse events -> scheduled as refresh driver observers.
* Scroll events -> Scheduled as well.
* Caret state change events -> Also scheduled after last patch.
* IME and accessibility stuff -> I don't think they can reenter layout.
We can always revert this if it causes troubles, plus it shouldn't crash on
release so should be fine.
Differential Revision: https://phabricator.services.mozilla.com/D31090
--HG--
extra : moz-landing-system : lando
Instead, post the event for the next turn of the event loop.
In this case, what killed the frame is ActionBarHandler.jsm via
Selection.toString().
Depends on D31088
Differential Revision: https://phabricator.services.mozilla.com/D31089
--HG--
extra : moz-landing-system : lando
Since background threads get shut down near `xpcom-shutdown-threads`,
there's no need to have `WebCryptoThreadPool` anymore; we can rely on
the background thread dispatching to fail to dispatch our task as
appropriate.
Differential Revision: https://phabricator.services.mozilla.com/D47006
--HG--
extra : moz-landing-system : lando
I think most of them should not be needed after bug 1561450. From our discussion
at TPAC in https://github.com/w3c/csswg-drafts/issues/4239, there should be no
reason not to do this unless we find fallout.
We need to enable the pref in tests that test these particular heuristics of
course.
Differential Revision: https://phabricator.services.mozilla.com/D47315
--HG--
extra : moz-landing-system : lando
That is, for the multicol container of depth two and more, we lay them
out by using "column-fill:auto" and "column-count:1".
I've check bug 725376 comment 9 for the previous approaches. Thanks to
bug 1555818, this solution is feasible because the fragmentation with
"column-fill:auto" is now possible.
Differential Revision: https://phabricator.services.mozilla.com/D47011
--HG--
extra : moz-landing-system : lando
Change the taskcluster max-run-time for mochitests and reftests to use the
defaults, now that android tests no longer run anywhere near 7200 seconds.
(Also noticed some unrelated tc configuration that is obsolete - tidied that.)
Also remove the special 600 second reftest timeout for android debug reftests.
Differential Revision: https://phabricator.services.mozilla.com/D47301
--HG--
extra : moz-landing-system : lando
Intent to unship: https://groups.google.com/forum/#!topic/mozilla.dev.platform/JnJVGTmIwPE
- Introduce a new preference option mathml.deprecated_alignment_attributes.disabled()
to disable alignment attributes for mfrac/munder/mover/munderover elements.
- Disable the attributes in Nightly and when running WPT tests.
- Enable the attributes in other channels but add a counter and deprecation warning.
- Remove failure expectation for WPT test frac-numalign-denomalign-001.html for mfrac
- Add new WPT test for underover-legacy-align-attribute-001.html for munder/mover/munderover
- Enable the attributes for MathML reftests checking these attributes.
- Disable numalign/denomalign test for Mochitest test_bug975681.html when the attributes
are disabled.
Differential Revision: https://phabricator.services.mozilla.com/D46712
--HG--
extra : moz-landing-system : lando
Actually, Gecko's long tap implementation will select a word string near tapped
area even if tapped area isn't text.
Since Blink doesn't select it and user reports this issue via web compat, I
would not like to select text if tapped area isn't text.
Differential Revision: https://phabricator.services.mozilla.com/D46126
--HG--
extra : moz-landing-system : lando
Previously, the setup_picture_caching function was hard coded
to support only a very specific shape of display list. With this
change, flags are added to PrimitiveCluster that can specify
if a picture cache slice should be created before / after this
cluster when picture caching is set up.
The usage of these flags in this patch matches the old behaviour,
so should not have any functional effect.
However, in future we will make use of this functionality to
create picture slices for a number of different use cases, such as:
* Creating cache tiles for the UI.
* Slicing the scene where there are video elements, in order to
allow these to be composited directly by the OS. This may also
apply to WebGL and/or canvas elements.
* Slicing the scene when there is a very large fixed position
background image or other element, to avoid invalidating the
entire tile cache each frame.
Differential Revision: https://phabricator.services.mozilla.com/D46125
--HG--
extra : moz-landing-system : lando
This patch makes fragmentation in "column-fill:auto" mode possible.
Note that we only bail out of creating more column contents when
"column-fill:auto" mode is set from the styles, i.e. when mForceAuto is
false. That is because when mForceAuto is true, we usually in the case
where we have gave up balancing, and we really want to create overflow
columns.
Note: without `!aConfig.mForceAuto` check, 673770.html can generated
assertions, and the frame tree contains dangling Overflow-lines and
ExcessOverflowContainersList.
Differential Revision: https://phabricator.services.mozilla.com/D47005
--HG--
extra : moz-landing-system : lando
mUsedColCount is used in balancing mode to check whether we have created
the maximum number of columns when the content cannot fit. Similarly,
mUsedColCount can also be useful in "column-fill:auto" mode to improve
the fragmentation story in the next patch.
This patch doesn't change the behavior (yet).
Differential Revision: https://phabricator.services.mozilla.com/D47004
--HG--
extra : moz-landing-system : lando
In next patch, this variable won't be set to INT32_MAX in
"column-fill:auto" mode, and it will be used in Part 4. Hence the
rename.
Differential Revision: https://phabricator.services.mozilla.com/D47003
--HG--
extra : moz-landing-system : lando
The associated if-block has a "break" statement at the end of the scope
to break the while-loop, making the else-block redundant.
Differential Revision: https://phabricator.services.mozilla.com/D47002
--HG--
extra : moz-landing-system : lando
D46944 / bug 1583534 is what fixes the root cause of bug 1528052 by not
having the first call to ResizeReflow have a wrong old size of 0x0.
This removes the code that bug introduces to suppress resize events, which
fixes this bug. I think our behavior now is pretty sane.
In particular, consider the test-case:
<!doctype html>
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<a href="" target="_blank">Open me in a separate tab</a>
<pre id="log"></pre>
<script>
// This shouldn't be needed, but otherwise Fenix doesn't show the tooltip on
// longpress...
document.querySelector("a").href = location.href;
function logSize() {
log.innerText += window.innerWidth + "x" + window.innerHeight + "\n";
}
logSize();
onresize = logSize;
</script>
(Hosted at https://crisal.io/tmp/gecko-mobile-resize.html for convenience)
Right now on trunk, when you click the link from GVE or Fenix, we're only
getting an initial size of 0x0 (which is not great, btw), and only after first
paint we get the real device size, but content doesn't get a resize event.
This is obviously wrong, every time the layout viewport changes we should fire
resize events.
Pages that get opened in new tabs and get refreshed when resized may get an
extra reload with this approach, but this seems not avoidable unless widget sets
the viewport size right in advance (which from discussion with snorp and agi
doesn't seem possible in the general case).
What used to happen is that we were triggering a redundant resize reflow from
the initial paint which didn't update the layout viewport (because the content
viewer and co had the right viewport from the previous navigation).
Now that we optimize those away, I think our behavior should be correct.
Differential Revision: https://phabricator.services.mozilla.com/D46956
--HG--
extra : moz-landing-system : lando
In particular, not let ResizeReflow take the old and new size. Most of the
callers pass dummy values anyway.
Instead, use the old size of the layout viewport. This ensures we fire resize
events only if the layout viewport actually changes.
This is important because the first resize of the mobile viewport manager
after a navigation has an "old size" of 0x0, even though the layout viewport
is initialized on presshell initialization to the right size.
Thus, we fire resize events unnecessarily in that case, which is the root cause
for bug 1528052.
To do this, we need to shuffle a bit of code in nsDocumentViewer that deals with
delayed resizes, to set the visible area _and_ invalidate layout, rather than
setting the visible area and _then_ relying on doing a resize reflow.
Further cleanup is possible, though not required for my android resizing fix, so
will do separately.
Differential Revision: https://phabricator.services.mozilla.com/D46944
--HG--
extra : moz-landing-system : lando