layout/reftests/bugs/262998-1.html only fails with webrender. I think maybe the initial annotation should have had that.
layout/reftests/bugs/818276-1.html I think is the same situation.
layout/reftests/474472-1.html seems to pass on a no-accel reftest fis run, but fails for me on regular reftest fis run, so I marked it random for now.
Differential Revision: https://phabricator.services.mozilla.com/D60105
--HG--
extra : moz-landing-system : lando
The order of CreateFlexLineAndFlexItemInfo() and
ComputedFlexContainerInfo() doesn't matter. I call
CreateFlexLineAndFlexItemInfo because it matches the order of the
members in ComputedFlexContainerInfo.
Some comments "... filled out at the end of this function" should be
updated. However, since I'm in the process of refactoring these
computations, I'll update them in Part 4.
Differential Revision: https://phabricator.services.mozilla.com/D60048
--HG--
extra : moz-landing-system : lando
Now that we're subclassing nsTextControlFrame we can use the regular replaced
element intrinsic sizing, rather than just faking it in the UA sheet with a
suspicious width declaration.
Differential Revision: https://phabricator.services.mozilla.com/D59981
--HG--
extra : moz-landing-system : lando
There is no way this ever properly worked, as we always passed null for
`aFrameState`.
So it'd only work if we reframed the document element or such... Which is not
amazing.
For simpler test-cases, when we don't construct the scrollframe via
PresShell::Initialize, but via the regular frame constructor updates
(ContentAppended, etc...), those end up working because we go through lazy frame
construction, which ends up in RecreateFramesForContent, which passes
mTempFrameTreeState.
Differential Revision: https://phabricator.services.mozilla.com/D59569
--HG--
extra : moz-landing-system : lando
Now that we're subclassing nsTextControlFrame we can use the regular replaced
element intrinsic sizing, rather than just faking it in the UA sheet with a
suspicious width declaration.
Differential Revision: https://phabricator.services.mozilla.com/D59981
--HG--
extra : moz-landing-system : lando
Changes:
Tighten reftest pixel differences now that reftest has been migrated fully over to ubuntu1804.
Differential Revision: https://phabricator.services.mozilla.com/D59598
--HG--
extra : moz-landing-system : lando
Instead, subclass nsTextControlFrame. This simplifies the code and avoids
correctness issues.
I kept the localization functionality though it is not spec compliant. But I
filed a bug to remove it in a followup.
Differential Revision: https://phabricator.services.mozilla.com/D57193
--HG--
extra : moz-landing-system : lando
PDFJS uses it, for example to allow text selection. It's not great if it shows
on top of the actual PDF :-)
Differential Revision: https://phabricator.services.mozilla.com/D58703
--HG--
extra : moz-landing-system : lando
Instead, subclass nsTextControlFrame. This simplifies the code and avoids
correctness issues.
I kept the localization functionality though it is not spec compliant. But I
filed a bug to remove it in a followup.
Differential Revision: https://phabricator.services.mozilla.com/D57193
--HG--
extra : moz-landing-system : lando
Although CssEnvironment is in Device of media query implementation, some code
creates CssEnvironment instance without Device. So I would like always to use it from Device of media query.
Differential Revision: https://phabricator.services.mozilla.com/D52506
--HG--
extra : moz-landing-system : lando
This prevents grid container frames from being considered subgrid (even when
they have contain:layout/paint) when they are themselves a grid item of a
contain grid.
Differential Revision: https://phabricator.services.mozilla.com/D59790
--HG--
extra : moz-landing-system : lando
When drawing themed backgrounds we snap them therefore we can expose
that in GetOpaqueRegion(). This will help WebRender fallback choose
an appropriately sized surface for drawing them.
Differential Revision: https://phabricator.services.mozilla.com/D59813
--HG--
extra : moz-landing-system : lando
There's no reason to have this pref anymore, as we've shipped with it
successfully for quite a while.
Differential Revision: https://phabricator.services.mozilla.com/D59767
--HG--
extra : moz-landing-system : lando
Do this only on nightly for now since we're about to enter the soft freeze.
(No test updates yet, as try is still running, and I need to figure out how to
import Oriol's changes into WPT, but I wanted to ensure that you were fine with
this)
Differential Revision: https://phabricator.services.mozilla.com/D54595
--HG--
extra : moz-landing-system : lando
So that it takes one pointer instead of two, and doesn't make nsStylePosition's
size blow up.
This is not as ugly as I was fearing, thankfully, though it requires a bit of
boilerplate. I think it's acceptable.
Differential Revision: https://phabricator.services.mozilla.com/D58702
--HG--
extra : moz-landing-system : lando
This is needed to support min() / max() / clamp(), etc, as those need to be a
tree of values and thus need heap storage.
This unfortunately grows LengthPercentage to be two pointers, which is bad as
it blows up the size of nsStylePosition enough to trigger the size assertions.
This patch comments out the assertion for now, the follow-up patches will
uncomment them.
Differential Revision: https://phabricator.services.mozilla.com/D58700
--HG--
extra : moz-landing-system : lando
Do this only on nightly for now since we're about to enter the soft freeze.
(No test updates yet, as try is still running, and I need to figure out how to
import Oriol's changes into WPT, but I wanted to ensure that you were fine with
this)
Differential Revision: https://phabricator.services.mozilla.com/D54595
--HG--
extra : moz-landing-system : lando
On webrender on android, parent-process pages (eg about:support) were not being
rendered immediately after minimising then resuming the app, resulting in a
black screen. The problem was that webrender believed the previous frame was
still valid, and therefore that it did not need to render a new
one. Content-process pages were unnaffected because we clear cached resources
when the app is minimised, so we accidentally rendered a new frame on
resumption.
To fix this we always force a new frame to be rendered immediately on
resumption. This uncovers a race condition which causes us to sometimes render
frames at the wrong size when the window size has changed (for example when
showing or hiding the keyboard), so that is also fixed.
This also fixes a bug affecting fenix, where when opening a page in a new tab
the portion of the screen where the keyboard used to be would remain black until
the page had loaded. This no longer occurs because we force a composite as soon
as the keyboard is hidden.
Additionally, this patch reverts the original attempt at fixing this
bug, as it is not necessary.
Differential Revision: https://phabricator.services.mozilla.com/D59367
--HG--
extra : moz-landing-system : lando
