This is needed if we want to handle cases like the reporter's example or Google
Images. Rendering the old image upscaled is much better than not rendering
anything while it's loading.
I added a test for the reframing bit, but I don't know how to add a test for the
second bit.
Differential Revision: https://phabricator.services.mozilla.com/D23127
Bug 1472637 makes the decision of whether to construct an image frame not depend
on this, so this is sound.
We need to avoid reframing to fix this bug because otherwise we lose track of
the previously painted image.
Differential Revision: https://phabricator.services.mozilla.com/D23127
Currently the MobileViewportManager leaves somethings permanently changed
even after it is destroyed: it may have changed the resolution of
the Document, and it may have set a fixed size for the visual viewport.
Both of these changes need to be un-done to return to normal display of
the Document.
Differential Revision: https://phabricator.services.mozilla.com/D17999
--HG--
extra : moz-landing-system : lando
Once nsIPresShell::SetVisualViewportSize is called, we currently have
no way to restore the default viewport sizing behavior. This corrects that.
We need the default behavior to get correctly-placed scrollbars when
turning off meta viewport handling in Responsive Design Mode panes.
Differential Revision: https://phabricator.services.mozilla.com/D20593
--HG--
extra : moz-landing-system : lando
Also update ScrollFrameHelper::LayoutScrollbars() to correctly handle
overlay scrollbars when zoomed in in RDM.
Differential Revision: https://phabricator.services.mozilla.com/D20591
--HG--
extra : moz-landing-system : lando
Currently the way we set the NS_FRAME_MAY_BE_TRANSFORMED frame bit for transform
animations fails to take into account the primary/style frame distinction for
display:table content.
This patch moves setting that bit for animations to the point where we already
have a handle on the appropriate EffectSet and already detect the primary/style
frame distinction.
This should be equivalent because:
a) Although it is inside a branch that is only run when |mContent| is set,
nsLayoutUtils::HasAnimationOfPropertySet will return false if the passed-in
frame does not have associated content (see
EffectCompositor::GetAnimationElementAndPseudoForFrame).
b) EffectSet::MayHaveTransformAnimation() should be set if we have any
transform animations in the EffectSet so this should be equivalent to
querying nsLayoutUtils::HasAnimationOfPropertySet.
The only other consideration is that this code is only executed when aPrevInFlow
is nullptr. As a result, this patch also updates the branch where aPrevInFlow is
set to copy the NS_FRAME_MAY_BE_TRANSFORMED bit in that case too.
Differential Revision: https://phabricator.services.mozilla.com/D23636
--HG--
extra : moz-landing-system : lando
There are many bugs regarding our use of EffectSet::GetEffectSet(nsIFrame*)
because the intention of the caller is not clear. If it is called for the
primary frame of display:table content do we expect it to get the EffectSet
associated with the style frame or not? Generally it depends on if we are
looking for transform animations or not.
Rather than inspecting each call site and making it choose the appropriate frame
to use, this patch introduces a new method to EffectSet to get the appropriate
EffectSet based on the properties the caller is interested in.
This patch also uses this function in FindAnimationsForCompositor which in turns
fixes the glitching observed on Tumblr that arose since a number of places in
our display list code were passing the style frame to
EffectCompositor::HasAnimationsForCompositor.
Over the remainder of this patch series we will convert more callers of
EffectSet::GetEffectSet(nsIFrame*) to this new method before renaming
EffectSet::GetEffectSet to GetEffectSetForStyleFrame to make clear how the
method is intended to work.
Differential Revision: https://phabricator.services.mozilla.com/D23282
--HG--
extra : moz-landing-system : lando
It took me a long time to understand why
KeyframeEffect::HasEffectiveAnimationOfPropertySet behaved so differently to
KeyframeEffect::HasAnimationOfPropertySet. This patch attempts to clarify that
while making KeyframeEffect::HasEffectiveAnimationOnPropertySet a little more
generally useful. This will allow us to tidy up the various animation checks in
nsLayoutUtils later in this patch series.
Ultimately, however, we should make this check part of the regular compositor
animation vetting machinery in bug 1534884. That should remove a number of
inconsistencies such that we don't need the extended comments added in this
patch.
Differential Revision: https://phabricator.services.mozilla.com/D23281
--HG--
extra : moz-landing-system : lando
The trouble with utility functions that take an nsIFrame is it's not clear what
the caller's intention is. For example, with
nsLayoutUtils::HasCurrentTransition, is the caller asking for transitions on
that frame? Or animations on _both_ that frame and its corresponding
style/primary frame?
Probably the caller hasn't even thought about it and there are likely to be bugs
when display:table content is encountered.
Where practical it's much better to take an element/pseudo pair since it's clear
that the caller is concerned with all animations (or transitions in this case)
on the element regardless of how it is represented in the frame tree.
This patch updates nsLayoutUtils::HasCurrentTransition to take an element/pseudo
pair and moves it to mozilla::AnimationUtils at the same time.
Differential Revision: https://phabricator.services.mozilla.com/D23280
--HG--
extra : moz-landing-system : lando
I was unable to create a failing reftest for this since this method is not
used when determining whether or not to create a stacking context.
However, I verified that for content with animated transforms and
will-change:transform on display:table content this change does cause us to
return true from the will-change check in this method when previously it would
not.
Differential Revision: https://phabricator.services.mozilla.com/D23279
--HG--
extra : moz-landing-system : lando
We test the transform-style of a frame in places like
KeyframeEffect::CanAnimateTransformOnCompositor but this will likely not work as
expected for display:table content since the transform-style will not be
inherited to the primary frame (and later in this patch series we will ensure
that we are dealing with the primary frame in
KeyframeEffect::CanAnimateTransformOnCompositor).
The individual transform properties are new but they should also be inherited so
that all the appropriate tests for "is this frame transformed?" produce the
correct result when these properties are applied.
Differential Revision: https://phabricator.services.mozilla.com/D23278
--HG--
extra : moz-landing-system : lando
There is some inconsistency between nsIFrame::FrameMaintainsOverflow() and
nsSVGContainerFrame::ComputeCustomOverflow(). If an element is a nondisplay
outer SVG, the latter gives false while the former returns true. We make them
consistent since nondisplay element doesn't need to maintain overflow.
Differential Revision: https://phabricator.services.mozilla.com/D23809
--HG--
extra : moz-landing-system : lando
And use correct AccessibleCaret preference to disable it individually in tests.
Differential Revision: https://phabricator.services.mozilla.com/D10299
--HG--
extra : moz-landing-system : lando
The assertion can be reproduced locally by running
"./mach test dom/canvas/test/chrome/test_drawWindow_widget_layers.html"
with layout.accessiblecaret.enabled=true.
When AccessibleCaret is enabled, caret elements will be inserted into
nsCanvasFrame::mCustomContentContainer, thus it recursively invokes
ConstructFramesFromItemList() to construct frames for carets before it had a
chance to construct popup group.
I feel it's too strict to assume that ConstructFramesFromItemList() cannot be
invoke recursively whenever there's a popup group item. I move the assertion to
the end of ConstructDocElementFrame() to ensure the popup group is processed by
then.
Differential Revision: https://phabricator.services.mozilla.com/D10298
--HG--
extra : moz-landing-system : lando
DidSetComputedStyle won't be called if the style changes to "display:none".
To ensure the reflow is properly scheduled, we need to also hook DestroyFrom.
Differential Revision: https://phabricator.services.mozilla.com/D23353
--HG--
extra : moz-landing-system : lando
This should unblock the fuzzers for now, though it's not the ideal solution.
It's the only reasonably easy solution to unblock them though, I think.
We should probably always keep track of the document a stylesheet was associated
with. We'll need that for constructible stylesheets anyway.
That requires some though on how to get the cycle-collection and such right,
though, and I wouldn't be able to write or land that ASAP.
Differential Revision: https://phabricator.services.mozilla.com/D23584
--HG--
extra : moz-landing-system : lando
::first-line reparenting may make non-first continuations to get a new style on
which we haven't run StartImageLoads when fragmenting out of the first-line.
Given this was mostly an opportunistic optimization let's remove it rather than
sacrificing correctness.
With bug 1465474 we would be able to fix this...
Differential Revision: https://phabricator.services.mozilla.com/D23525
--HG--
extra : moz-landing-system : lando
Adds a method for to nsFrameLoaderOwner destroying and rebuilding a
FrameLoader in order to facilitate a process switch. Method works
without requiring that the work be done in the frontend.
Depends on D22789
Differential Revision: https://phabricator.services.mozilla.com/D22790
--HG--
extra : moz-landing-system : lando
We scroll the visual viewport in addition to the layout viewport to make sure
that the layout viewport also ends up at the desired position; note that the
layout viewport's desired position will change in bug 1516056 as we start
clamping the layout viewport offset to the layout scroll range.
Differential Revision: https://phabricator.services.mozilla.com/D19873
--HG--
extra : moz-landing-system : lando
Right now we just block the image returned from nsIFrame::GetCursor, which is
the first loading cursor image.
I think we should do the same we do when the image fails to load, which is to
fall back to the next image instead.
This patch moves all the custom cursor code selection logic to
EventStateManager, and lets the frame return a CursorKind and whether custom
images are allowed.
Differential Revision: https://phabricator.services.mozilla.com/D23289
--HG--
extra : moz-landing-system : lando
Now, other methods taking `aFrame` of `HandleEvent()` names the argument as
`aFrameForPresShell`. So, `HandleEvent()`'s `aFrame` should also be renamed.
This patch renames it and adds MOZ_CAN_RUN_SCRIPT and comment to
`nsIPresShell::HandleEvent()`.
This is the final patch for bug 1466208.
Differential Revision: https://phabricator.services.mozilla.com/D22463
--HG--
extra : moz-landing-system : lando
Previously we would only paint the building area but we
would not do anything to check that the building area had
changed. Since, we're already allocating a surface for the entire
item it's better to just paint it and not worry about doing extra
invalidations.
Originally, we used mVisibleRect here. That was changed to GetPaintRect()
in part 1 of 1460491 and then to GetBuildingRect in part 2. However,
I think the original code was always wrong and we should've been using
mBounds the whole time.
Differential Revision: https://phabricator.services.mozilla.com/D23215
--HG--
extra : moz-landing-system : lando
You can mess up stuff pretty badly if that happens, and we want to do this
anyway for the shared UA sheet stuff, so...
Differential Revision: https://phabricator.services.mozilla.com/D22554
--HG--
extra : moz-landing-system : lando
In my understanding, `PresShell::EventHandler::HandleEvent()` may redirect
the event to another class or PresShell first. Otherwise, it computes
event target and sets current event info of mPresShell to it. Then, calls
`HandleEventInternal()` to dispatch the event. Then, `HandleEventInternal()`
may handle the event before dispatch, and/or prepare to dispatch, then,
finally dispatches the event and finalize the state of mPresShell and the
event. Therefore, `HandleEventInternal()` actually handles the event, but
the word, "internal" is not explicitly explain its different points from
`HandleEvent()`. Therefore, I think that `HandleEventWithCurrentEventInfo()`
is better name since `HandleEvent()` considers the current event info.
Differential Revision: https://phabricator.services.mozilla.com/D22462
--HG--
extra : moz-landing-system : lando
Finally, we should move the last switch statement in `HandleEventInternal()`
to the new method. Then, `HandleEventInternal() does nothing complicated
things by itself.
Differential Revision: https://phabricator.services.mozilla.com/D22461
--HG--
extra : moz-landing-system : lando
This was introduced in bug 1018324 for the DOM Inspector addon but we no longer
support those kinds of addons.
Differential Revision: https://phabricator.services.mozilla.com/D22872
--HG--
extra : moz-landing-system : lando
This is the part which actually handles the event. The new method should
notify EventStateManager of dispatching event before and after that, and
actually dispatch the event into the DOM.
Differential Revision: https://phabricator.services.mozilla.com/D22459
--HG--
extra : moz-landing-system : lando
For making `PresShell::EventHandler::HandleEventInternal()` easier to read,
move the large switch statement for preparation into the new method.
Differential Revision: https://phabricator.services.mozilla.com/D21341
--HG--
extra : moz-landing-system : lando
`PresShell::EventHandler::HandleEventInternal()` may handle `Escape` key before
dispatching it in some cases. This requires too many lines for somebody who
investigate the method for the other events. Therefore, this patch moves it
into the new method.
Additionally, this patch creates `WidgetKeyboardEvent::CanTreatAsUserInput()`
and `WidgetKeyboardEvent::ShouldInteractionTimeRecorded()` because we should
manage similar checks in one place (we already have
`WidgetKeyboardEvent::CanUserGestureActivateTarget()`). Finally, their
conditions are not enough for what the comment wants to do there since they do
not check some modifier keys. Therefore, this patch makes them check all
possible modifier keys too.
Differential Revision: https://phabricator.services.mozilla.com/D21340
--HG--
extra : moz-landing-system : lando
The first switch statement of `PresShell::EventHandler::HandleEventInternal()`
has 2 jobs:
- Prepare something for specific event type.
- Record the preparation time of some types of events to telemetry.
This intermixed code is not easy to understand and somebody may add new
preparation after recording them. So, even though the preparation time
becomes worse a couple of nanoseconds, we should split those jobs.
The patch moves the latter job into the new method.
Differential Revision: https://phabricator.services.mozilla.com/D21339
--HG--
extra : moz-landing-system : lando
Oddly, there are two trusted eMouseMove preparation code in
`PresShell::EventHandler::HandleEventInternal()`. One is in the `switch`
statement which is used only when `aEvent` is trusted. The other is after
`TouchManager::PreHandleEvent()` is called and after
`AutoHandlingUserInputStatePusher` is created. However, both of them do
nothing if the event is `eMouseMove`. Therefore, we can move the latter
into the former.
Differential Revision: https://phabricator.services.mozilla.com/D21338
--HG--
extra : moz-landing-system : lando
I wrote this patch by first removing UNIFIED_ from layout/style/moz.build, and
then rebuilding, and then addressing build errors one by one.
Nearly all of the build errors were for using the "Document" type without a
proper namespace, and I've addressed this by sprinkling "using namespace"
declarations in the affected .cpp files (and removing a few now-unnecessary
dom:: prefixes on types in those files).
The only other errors were for WorkletGlobalScope.h which needed an #include to
provide the type "DOMHighResTimeStamp", and nsHTMLStyleSheet.h which needed a
forward-declaration for the type "mozilla::dom::Document".
Differential Revision: https://phabricator.services.mozilla.com/D22767
--HG--
extra : moz-landing-system : lando
Actually the function will fail on Android since on xpcshell tests we don't
initialize AndroidBridge so that we can't query the corresponding system
settings.
Differential Revision: https://phabricator.services.mozilla.com/D22270
--HG--
extra : moz-landing-system : lando
You can mess up stuff pretty badly if that happens, and we want to do this
anyway for the shared UA sheet stuff, so...
Differential Revision: https://phabricator.services.mozilla.com/D22554
--HG--
extra : moz-landing-system : lando
Emilio Cobos Álvarez
Brad Werth
Brian Birtles
Sebastian Hengst
violet
Ciure Andrei
longsonr
Csoregi Natalia
Ting-Yu Lin
Edwin Gao
Chris Peterson
Botond Ballo
Dorel Luca
Sylvestre Ledru
Andrew Osmond
Kyle Machulis
David Major
Miko Mynttinen
Doug Thayer
Masayuki Nakano
Boris Zbarsky
Jeff Muizelaar
Cameron McCormack
Olli Pettay
Hiroyuki Ikezoe
Henrik Skupin
Matt Woodrow
Victor Porof
shindli
Razvan Maries
Henri Sivonen
violet
Bogdan Tara
Daniel Holbert
Oana Pop Rus
Ryan Hunt
Andrea Marchesini
arthur.iakab
Neil Deakin