When XBL is disabled, no code in dom/xbl will be built. Also, adds ifdefs
to remove any of the XBL related code elsewhere. There's definitely more
that can be done here, but I think it's better to wait to do the rest of
the cleanup when we actually remove the code.
Depends on D45612
Differential Revision: https://phabricator.services.mozilla.com/D45613
--HG--
extra : moz-landing-system : lando
The only thing it does is asserting a bit and posting more async work to the
text frame. It seems we can just post all the async work early instead, and
remove the change hint.
This was only introduced to fix bug 779971, where a <textPath> element
references its parent SVG, which is obviously unsound if we allowed to render
it.
What we're doing right now is a bit silly... We're observing the <svg>, so when
we finish reflowing it and store its overflow, we invalidate its rendering
observers, but that invalidates a _descendant_, which makes no sense.
Fortunately we don't let the element affect its rendering, as it fails this
check:
* https://searchfox.org/mozilla-central/rev/35cc00a25c4471993fdaa5761952bd3afd4f1731/layout/svg/SVGObserverUtils.cpp#1390
But we still request reflow of the outer <text>, which is not amazing. We
shouldn't invalidate anything if the textpath doesn't reference a valid element
and that didn't change. This is roughly what the code tried to do when checking
mValid, except we always initialize mValid to true and thus always trigger at
least one bogus reflow call.
Differential Revision: https://phabricator.services.mozilla.com/D48008
--HG--
extra : moz-landing-system : lando
What we actually care about here is whether itemRect is empty bceause that's
the what we'll use for the actual surface size.
Differential Revision: https://phabricator.services.mozilla.com/D48548
--HG--
extra : moz-landing-system : lando
It's always used along with nsChangeHint_RepaintFrame, which does most of the
work.
It's only useful to skip calling SyncFrameViewProperties(). That call is really
cheap if nothing actually changed, furthermore since only a handful of frames
actually have views.
So it doesn't seem like it serves any useful purpose.
Differential Revision: https://phabricator.services.mozilla.com/D48003
--HG--
extra : moz-landing-system : lando
This fixes another edge-case that I thought of while debugging this, I think
this makes our behavior correct now. The comment and test-case should be
self-descriptive.
Differential Revision: https://phabricator.services.mozilla.com/D48135
--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
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
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
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
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
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
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
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
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
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
Brendan Dahl
Emilio Cobos Álvarez
Emma Malysz
Jeff Muizelaar
Botond Ballo
Neil Deakin
Sylvestre Ledru
Tom Ritter
Geoff Brown
Boris Chiou
Hiroyuki Ikezoe
Tim Nguyen
Daniel Holbert
Dorel Luca
shindli
Brindusan Cristian
Makoto Kato
arthur.iakab
Kris Maglione
Daniel Varga
Timothy Nikkel
Edgar Chen
Jonathan Kew
Andreea Pavel