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
As it turns out, the difference between the snapped local rect and the
unsnapped local rect was not just that the former contained snapped
primitives and the latter contained unsnapped primitives, but also that
the former took into account surface inflation for primitives, the
entire clip chain instead of just the primitive's local clip, and
removal of culled primitives. As such, the picture's rects can be wildly
different, even if snapping has been taken care of earlier, and parts of
WebRender have come to rely upon this more accurate representation of a
picture.
Differential Revision: https://phabricator.services.mozilla.com/D46605
--HG--
extra : moz-landing-system : lando
Also, update the serialization by the shorter perference because this is
a new feature and using older syntax doesn't make sense.
Besides, use `cssOffset` for web animation IDL attribute name.
Differential Revision: https://phabricator.services.mozilla.com/D45607
--HG--
extra : moz-landing-system : lando
As it turns out, the difference between the snapped local rect and the
unsnapped local rect was not just that the former contained snapped
primitives and the latter contained unsnapped primitives, but also that
the former took into account surface inflation for primitives, the
entire clip chain instead of just the primitive's local clip, and
removal of culled primitives. As such, the picture's rects can be wildly
different, even if snapping has been taken care of earlier, and parts of
WebRender have come to rely upon this more accurate representation of a
picture.
Differential Revision: https://phabricator.services.mozilla.com/D46605
--HG--
extra : moz-landing-system : lando
As it turns out, the difference between the snapped local rect and the
unsnapped local rect was not just that the former contained snapped
primitives and the latter contained unsnapped primitives, but also that
the former took into account surface inflation for primitives, the
entire clip chain instead of just the primitive's local clip, and
removal of culled primitives. As such, the picture's rects can be wildly
different, even if snapping has been taken care of earlier, and parts of
WebRender have come to rely upon this more accurate representation of a
picture.
Differential Revision: https://phabricator.services.mozilla.com/D46605
--HG--
extra : moz-landing-system : lando
People keep adding useless null-checks and it was not clear what the consensus
was from bug 1441165, but this should be unobjectionable I guess.
Differential Revision: https://phabricator.services.mozilla.com/D46781
--HG--
extra : moz-landing-system : lando
Fragmentation spec already has a paragraph describing this behavior.
DONTBUILD because this is a comment only change.
Differential Revision: https://phabricator.services.mozilla.com/D46691
--HG--
extra : moz-landing-system : lando
We don't need this anymore now that we're always
using the visible rect.
This requires bug 1582528 to properly set the visible area.
Differential Revision: https://phabricator.services.mozilla.com/D46628
--HG--
extra : moz-landing-system : lando
It will generate a warning and is useless as explained in the code comment.
Differential Revision: https://phabricator.services.mozilla.com/D46626
--HG--
extra : moz-landing-system : lando
We need to distinguish between the out-of-process iframe is totally invisible and
the given nsIFrame is not in out-of-process iframes.
Differential Revision: https://phabricator.services.mozilla.com/D46553
--HG--
extra : source : fc785139655e3d22d681f1419bd4c80f93460f0e
`image-short.png` never exists in the first place when this test was
introduced, so the intermittent happens when the test file shows a
broken image icon and the reference file without, or the other way
around.
I believe the `<img>` is served as a monolithic element to overflow
`<div class="short">`. Use an empty src should suffice.
Differential Revision: https://phabricator.services.mozilla.com/D46640
--HG--
extra : moz-landing-system : lando
We need to distinguish between the out-of-process iframe is totally invisible and
the given nsIFrame is not in out-of-process iframes.
Differential Revision: https://phabricator.services.mozilla.com/D46553
--HG--
extra : moz-landing-system : lando
This is in the interests of allowing the frontend team to experiment with
switching from XUL grid to CSS grid, without inadvertently changing the
display values for the grid items via css-grid-item blockification.
This patch's new pref is not expected to remain in the codebase for long.
We're just adding it so that the behavior remains the same by default, because
we do currently have some XUL code that inadvertently depends on -moz-box
display values being blockified to 'block'. The plan is for folks to remove
that dependency e.g. by adding explicit 'display:block' styling to frontend
code as-needed. After we've done that, we can tentatively flip the pref to true
by default, and then remove the pref entirely.
Differential Revision: https://phabricator.services.mozilla.com/D45258
--HG--
extra : moz-landing-system : lando
Currently, there's no way to tell whether the SIDEWAYS bit is set from
`writing-mode:sideways-*` or `writing-mode:vertical-*; text-orientation:sideways;`.
To be able to tell them apart, split SIDEWAYS bits into VERTICAL_SIDEWAYS
and TEXT_SIDEWAYS. This is needed by my proposed solution in bug 1102175.
Also, provide convenience methods related to sideways writing-mode, and replace
obscure checks in the codebase.
Note that we don't have the use cases to distinguish vertical-rl from
sideways-rl in layout, but for the completeness, IsSidewaysLR() is still
defined.
Differential Revision: https://phabricator.services.mozilla.com/D46321
--HG--
extra : moz-landing-system : lando
In particular: in our frontend code, if we happen to end up with a flex/grid
item with 'display:-moz-box', we want it to take the same sizing codepath as
other flex/grid items, which are all block-level (even though -moz-box is not
exactly block-level itself). Notably, we want to use ComputeSizeFlags::eDefault
for sizing (like we do for real block-level things), because that's necessary
in order for grid items to stretch correctly in their inline axis.
Also: this patch renames "isBlock" to "isBlockLevel" to reflect reality. Its
naming is based on the constant NS_CSS_FRAME_TYPE_BLOCK, which in fact is not
specific to 'display:block' but in fact is for frames that are "block-level in
normal flow" (which I think in practice means block-level and not
out-of-flow). That is documented here:
https://searchfox.org/mozilla-central/rev/7531325c8660cfa61bf71725f83501028178cbb9/layout/generic/ReflowInput.h#51
Differential Revision: https://phabricator.services.mozilla.com/D46539
--HG--
extra : moz-landing-system : lando
Now that we count them, I think we should do this.
This property is pretty painful for various reasons:
* It's a pretty awkward non-standard property.
* Has a pretty short name, so people use it instead of the standard
alternatives.
* We cannot really even implement it easily anyhow, without breaking a whole
bunch of stuff, because pages do things like:
```
myelement {
zoom: 0.5;
-moz-transform: scale(0.5);
transform-origin: 0 0;
}
```
For now this is only recorded when CSS use counters are enabled (Nightly for
now), but I want to change it once bug 1578661 is in central.
The hope is that this warning slightly raises awareness of this property not
being standard. You get a CSS parsing error in the console, but those are
usually too noisy and disabled by default.
Differential Revision: https://phabricator.services.mozilla.com/D46430
--HG--
extra : moz-landing-system : lando
Also causes removing a pref to take effect immediately, and prevents
losing all color pref overrides when the theme changes.
Differential Revision: https://phabricator.services.mozilla.com/D44416
--HG--
extra : moz-landing-system : lando
By reporting the properties in MappedAttrParser that we used to (the test relies
on counting those), and by adjusting the histogram name to the new thing.
Differential Revision: https://phabricator.services.mozilla.com/D44697
--HG--
extra : moz-landing-system : lando
We only have two counters enabled, just for testing, and they just count from
the SVG mapped attribute code. That's not great, and they mostly complicate the
next few patches.
Differential Revision: https://phabricator.services.mozilla.com/D44695
--HG--
extra : moz-landing-system : lando
This is to avoid skip-ink problems with fonts that leave the OpenType field at zero,
which is unlikely to ever be what is really wanted. Authors can still avoid the clamp by
explicitly using text-underline-offset:from-font.
Differential Revision: https://phabricator.services.mozilla.com/D46268
--HG--
extra : moz-landing-system : lando
By reporting the properties in MappedAttrParser that we used to (the test relies
on counting those), and by adjusting the histogram name to the new thing.
Differential Revision: https://phabricator.services.mozilla.com/D44697
--HG--
extra : moz-landing-system : lando
We only have two counters enabled, just for testing, and they just count from
the SVG mapped attribute code. That's not great, and they mostly complicate the
next few patches.
Differential Revision: https://phabricator.services.mozilla.com/D44695
--HG--
extra : moz-landing-system : lando
By reporting the properties in MappedAttrParser that we used to (the test relies
on counting those), and by adjusting the histogram name to the new thing.
Differential Revision: https://phabricator.services.mozilla.com/D44697
--HG--
extra : moz-landing-system : lando
We only have two counters enabled, just for testing, and they just count from
the SVG mapped attribute code. That's not great, and they mostly complicate the
next few patches.
Differential Revision: https://phabricator.services.mozilla.com/D44695
--HG--
extra : moz-landing-system : lando
arthur.iakab
Dorel Luca
Makoto Kato
Glenn Watson
Lee Salzman
Ting-Yu Lin
Daniel Holbert
Andreea Pavel
Emilio Cobos Álvarez
Cosmin Sabou
Tim Nguyen
Mihai Alexandru Michis
Andrew Osmond
Oana Pop Rus
Timothy Nikkel
Geoff Brown
Boris Chiou
Noemi Erli
Jonathan Watt
longsonr
Glenn Watson
Brian Birtles
Cameron McCormack
Jeff Muizelaar
Kris Maglione
Daniel Varga
Edgar Chen
Hiroyuki Ikezoe
Jonathan Kew
Agi Sferro
Bogdan Tara
Adam Gashlin
Alexander Surkov
Morgan Reschenberg
Randall E. Barker
Nicolas Silva