This adds a notification from APZ to the scrollbar's slider frame to
inform it of APZ starting an async scrollbar drag. This is useful
because APZ can start a scrollbar drag and even change the scroll
position before the scrollbar frame even handles the mousedown event. In
such a case, the mousedown can land on where the scrollthumb *used to
be* before it was dragged away. This can result in scroll-to-click
behavior getting triggered and the scrollthumb glitching.
With this patch, the new notification follows the same path as the
request-repaint message, and so is guaranteed to arrive at the scrollbar
before any request-repaint messages. It sets some state that can be used
to correct the behaviour described above.
Differential Revision: https://phabricator.services.mozilla.com/D12364
--HG--
extra : moz-landing-system : lando
The assert is testing that the content's primary frame shouldn't
generate any native anonymous children, but what we really want to
ensure is that :-moz-column-span-wrapper doesn't create any native
anonymous child (because we don't restyle the wrapper), not the content
which creates ::-moz-column-span-wrapper. The condition is already
guaranteed by !aFrame->HasAnyStateBits(NS_FRAME_OWNS_ANON_BOXES) above.
Also, at this point during the frame construction, we haven't associate
the content with the its primary frame. Therefore,
nsContentUtils::AppendNativeAnonymousChildren() won't return anything
except for scrollbars on root element. That's why we have the crash in
this bug.
Differential Revision: https://phabricator.services.mozilla.com/D12359
--HG--
extra : moz-landing-system : lando
The contain:paint clipping would be redundant and hence unnecessary in this
scenario, because:
- Scroll frames already clip their descendant frames.
- contain:paint has other (non-clipping-related) effects that prevent
descendant frames from escaping the scrollframe ancestor.
So, no further clipping is required.
This is a behavior change - it works around an issue that makes us fail to
repaint mousewheel-scrolled content inside of any scrollframe that returns true
from ShouldApplyOverflowClipping().
Differential Revision: https://phabricator.services.mozilla.com/D12056
--HG--
extra : moz-landing-system : lando
Converted NS_STYLE_BORDER_STYLE_* consts to enum class. Updated corresponding values to enum class. reduced BCCornerInfo struct values to fit StyleBorderStyle values inside struct. Added defaults to switches that do not fully cover all instances of StyleBorderStyle.
This patch removes the following functions:
* nsContentUtils::IsCustomElementsEnabled()
* CustomElementRegistry::IsCustomElementEnabled(JSContext* aCx, JSObject* aObject)
* CustomElementRegistry::IsCustomElementEnabled(nsIDocument* aDoc)
and all references of the pref.
Depends on D11183
Differential Revision: https://phabricator.services.mozilla.com/D11249
--HG--
extra : moz-landing-system : lando
This patch removes the dom.webcomponents.shadowdom.enabled pref and all its
references, including the following functions:
* nsContentUtils::IsShadowDOMEnabled()
* nsIDocument::IsShadowDOMEnabled()
* nsDocument::IsShadowDOMEnabled(JSContext* aCx, JSObject* aGlobal)
* nsDocument::IsShadowDOMEnabled(const nsINode* aNode)
* nsTextNode::IsShadowDOMEnabled(JSContext* aCx, JSObject* aObject)
This function is renamed and updated to nsDocument::IsCallerChromeOrAddon():
* nsDocument::IsShadowDOMEnabledAndCallerIsChromeOrAddon(JSContext* aCx, JSObject* aObject)
I didn't change the tests that load Shadow DOM tests in an iframe, in the interest of keeping hg annotation history.
Differential Revision: https://phabricator.services.mozilla.com/D11183
--HG--
extra : moz-landing-system : lando
This patch removes the following functions:
* nsContentUtils::IsCustomElementsEnabled()
* CustomElementRegistry::IsCustomElementEnabled(JSContext* aCx, JSObject* aObject)
* CustomElementRegistry::IsCustomElementEnabled(nsIDocument* aDoc)
and all references of the pref.
Depends on D11183
Differential Revision: https://phabricator.services.mozilla.com/D11249
--HG--
extra : moz-landing-system : lando
This patch removes the dom.webcomponents.shadowdom.enabled pref and all its
references, including the following functions:
* nsContentUtils::IsShadowDOMEnabled()
* nsIDocument::IsShadowDOMEnabled()
* nsDocument::IsShadowDOMEnabled(JSContext* aCx, JSObject* aGlobal)
* nsDocument::IsShadowDOMEnabled(const nsINode* aNode)
* nsTextNode::IsShadowDOMEnabled(JSContext* aCx, JSObject* aObject)
This function is renamed and updated to nsDocument::IsCallerChromeOrAddon():
* nsDocument::IsShadowDOMEnabledAndCallerIsChromeOrAddon(JSContext* aCx, JSObject* aObject)
I didn't change the tests that load Shadow DOM tests in an iframe, in the interest of keeping hg annotation history.
Differential Revision: https://phabricator.services.mozilla.com/D11183
--HG--
extra : moz-landing-system : lando
This test would fail with the upcoming bug 1159042 (dynamic reflow roots),
without the RecomputePosition fix in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D9481
--HG--
extra : moz-landing-system : lando
This is enough to fix the devtools regression and matches what other browsers
do in the no-attribute case.
Also, I think this change over all makes sense: it doesn't make any sense to
display the broken image icon if there's no request, and we already assume in
EnsureIntrinsicSizeAndRatio() that we don't paint the icon for those (and make
the intrinsic size 0x0).
We still show the border, which matches other UAs (note that devtools
effectively masks the border away with mask-image).
This technically also can change behavior of <object> and <input>, but I think
it's better to be consistent, since EnsureIntrinsicSizeAndRatio also doesn't
special-case <img> either.
Differential Revision: https://phabricator.services.mozilla.com/D11659
--HG--
extra : moz-landing-system : lando
Badly-behaved consumers of DrawTargetRecording can trigger recording of
draw calls that will fail to allocate required draw targets when the
recording is replayed. This patch tries to guard against this by
detecting these situations at record-time rather than crashing at
replay-time. When such a situation is detected, it will crash (for
content processes, to catch such scenarios) or gracefully fail (for
other processes).
Differential Revision: https://phabricator.services.mozilla.com/D11527
--HG--
extra : moz-landing-system : lando
This change eliminates
- nsLayoutUtils::LastContinuationOrIBSplitSibling calls for each CSS
properties on WebRender
- iterating over each display item for each compositor runnable CSS properties
- a bunch of stuff in the case where the layer manager has not yet created,
i.e. the compositor thread is not ready to receive animations
Depends on D11425
Differential Revision: https://phabricator.services.mozilla.com/D11426
--HG--
extra : moz-landing-system : lando
It's an attempt of an alias to `all`, except it doesn't get handled in all
places.
Seems unused both in comm-central and mozilla-central, and all external usage I
could find is followed by -webkit-user-select: all.
Differential Revision: https://phabricator.services.mozilla.com/D11582
It's an attempt of an alias to `all`, except it doesn't get handled in all
places.
Seems unused both in comm-central and mozilla-central, and all external usage I
could find is followed by -webkit-user-select: all.
Differential Revision: https://phabricator.services.mozilla.com/D11582
Also, remove the unused NS_BLOCK_MARGIN_ROOT flag set on nsColumnSetFrame.
Differential Revision: https://phabricator.services.mozilla.com/D8783
--HG--
extra : moz-landing-system : lando
Behavior-wise this only removes the HasAttr(src) check, and adds the IsEmpty()
check to the alt attribute value, since this function is only called for <img>
and <input>.
But it also cleans up a bit.
Differential Revision: https://phabricator.services.mozilla.com/D11194
Behavior-wise this only removes the HasAttr(src) check, and adds the IsEmpty()
check to the alt attribute value, since this function is only called for <img>
and <input>.
But it also cleans up a bit.
Differential Revision: https://phabricator.services.mozilla.com/D11194
--HG--
extra : source : 803b224d52a0940b4fb4b3b9cffc6a1fa6e5d4ee
Behavior-wise this only removes the HasAttr(src) check, and adds the IsEmpty()
check to the alt attribute value, since this function is only called for <img>
and <input>.
But it also cleans up a bit.
Differential Revision: https://phabricator.services.mozilla.com/D11194
The major change in this patch is ::-moz-column-span-wrapper blocks are no
longer linked into the continuation chains when they're created in
CreateColumnSpanSiblings(). We can do that because
::-moz-column-span-wrapper is an non-inheriting anon box, which doesn't need
to be restyled.
This prevents RestyleManager::ProcessPostTraversal or
nsIFrame::UpdateStyleOfOwnedChildFrame, which set the same style on all
continuations of the frame they are working with, from overriding the
::-moz-column-span-wrapper style.
GetNextContinuationWithSameStyle was deleted in bug 1447367. Delete the comment
in nsInlineFrame::UpdateStyleOfOwnedAnonBoxesForIBSplit() to avoid confusion.
This patch also adds another condition to reframe the multi-column container
in MaybeRecreateContainerForFrameRemoval(). That condition is when an
element has a "column-span:all" descendant, i.e. the element's frame has
"column-span:all" siblings (which is created by CreateColumnSpanSiblings).
The added test multicol-span-all-dynamic-remove-006.html will fail without
this patch.
Depends on D5212
Differential Revision: https://phabricator.services.mozilla.com/D9988
--HG--
extra : moz-landing-system : lando
Other frames calling InitAndWrapInColumnSetFrameIfNeeded() needs to be
modified to support column-span (bug 1489295).
Depends on D5208
Differential Revision: https://phabricator.services.mozilla.com/D5209
--HG--
extra : moz-landing-system : lando
This patch doesn't change behavior; it's just making some custom cleanup
code unnecessary by using a better fitting container class.
Differential Revision: https://phabricator.services.mozilla.com/D11237
--HG--
extra : moz-landing-system : lando
In this case aAncestor is an SVGOuterSVGFrame, and aItem is a transform item for
its AnonChildFrame.
I'm not sure if it's quite expected to have such a frame generating a
transform...
Let me know if not and I can try to dig more, but this looks intentional given
the comment in nsSVGOuterSVGAnonChildFrame.
Differential Revision: https://phabricator.services.mozilla.com/D10955
--HG--
extra : moz-landing-system : lando
Currently, GetSplittableType() is called only in
nsCSSFrameConstructor::CreateContinuingFrame(). The splittable concrete frames
should inherit from nsSplittableFrame, and must explicitly create continuing
frame in CreateContinuingFrame(). Thus, no need to maintain GetSplittableType().
Differential Revision: https://phabricator.services.mozilla.com/D10798
--HG--
extra : moz-landing-system : lando
This patch converts datetimebox.xml to datetimebox.js and loads it as a UA Widget,
while touches things here and there to make it work.
In HTMLInputElement manages the lifecycle of the datetimebox UA Widget.
It is loaded when in <input> has type date or time, or have its type switch to date or time.
nsDateTimeControlFrame is changed so that when UA Widget is enabled,
it would not generate <xul:datetimebox>.
Like bug 1483972, a check is added in nsCSSFrameConstructor::CreateGeneratedContentItem()
to make sure we don't generate pseudo content inside <input>.
Assertions in IntlUtils is changed to allow UAWidget to call the methods.
Depends on D9056
Differential Revision: https://phabricator.services.mozilla.com/D9057
--HG--
rename : toolkit/content/widgets/datetimebox.xml => toolkit/content/widgets/datetimebox.js
extra : moz-landing-system : lando
It doesn't make much sense to return const UniquePtr<Foo>& for something that
can't be null, it's just confusing.
Also make more stuff actually const.
Differential Revision: https://phabricator.services.mozilla.com/D10647
--HG--
extra : moz-landing-system : lando
This patch allows us to intercept invalidation requests for display
items, and avoid regenerating the display list for animated images which
are using SharedSurfacesAnimation.
Differential Revision: https://phabricator.services.mozilla.com/D7504
This commit attempts to lower the pain of modifying FrameMetrics.h.
It looks like most includes really only want ViewID or
ScrollableLayerGuid, so this commit factors them out into a separate
header. In the process FrameMetrics::ViewID is changed to
ScrollableLayerGuid::ViewID, which personally seems like a better
place for it now that we have RepaintRequest. Unfortunately that
requires a lot of places to be updated.
After this commit there are still a couple of major places that
FrameMetrics is included.
* nsDisplayList.h
* nsIScrollableFrame.h
* Layers.h
Those are going to be more tricky or impossible to fix so they're
not in this commit.
Differential Revision: https://phabricator.services.mozilla.com/D10722
--HG--
rename : gfx/layers/FrameMetrics.h => gfx/layers/ScrollableLayerGuid.h
rename : gfx/layers/FrameMetrics.h => gfx/layers/ZoomConstraints.h
extra : rebase_source : 29ac79f91460a181bf7437af5c371207e22858e2
extra : source : c2e70e531075493fc6e374dcec862827f0bc6e77
1. Drop {Width|MinWidth|MaxWidh}DependsOnContainer() and
{Height|MinHeight|MaxHeight}DependsOnContainer() because they are bogus
after introducing the writing mode. Dropping these functions needs
update nsLineLayout because it is the only one who still use
these functions.
2. There are still some potential assertions and bugs on handling keywords
in the block size, so we should update them as well.
Depends on D9438
Differential Revision: https://phabricator.services.mozilla.com/D9439
--HG--
extra : moz-landing-system : lando
Keywords on the sizing properties in the block axis should behave as
initial values in the flex frame. We store the keywords as enum, instead
of auto or none in nsStyleCoord, so we have to handle it explicitly.
Differential Revision: https://phabricator.services.mozilla.com/D9438
--HG--
extra : moz-landing-system : lando
The original statement is neat, but one cannot easily associates the values
computed in ChooseColumnStrategy with the actually field name in ReflowConfig.
Remove the aFeasibleBSize and aInfeasibleBSize for ChooseColumnStrategy()
because they're not used.
Differential Revision: https://phabricator.services.mozilla.com/D9467
--HG--
extra : moz-landing-system : lando
Depends on D8740.
This changeset replaces calls to ok with 3 arguments to calls with 2 arguments
in situations where the switch does not have a significant impact on the assert.
Differential Revision: https://phabricator.services.mozilla.com/D8741
--HG--
extra : moz-landing-system : lando
This changeset updates all the test that were wrongly using ok() and wanted to
use is() AND for which the assert is still passing without any modification
required.
Differential Revision: https://phabricator.services.mozilla.com/D8739
--HG--
extra : moz-landing-system : lando
This patch basically reverts the functional part of changeset 52bd865d757c.
I'd optimistically hoped we could skip this early-freeze in order to compute &
report a bit more "potential flexing" information via devtools. Bbut it turns
out that breaks assertions & produces bogus information for flex items whose
base size vs. min/max-clamped "hypothetical" sizes are very
different. (Specifically: it produces nonsense for flex items whose base sizes,
if unclamped, would reverse the directionality of flexing.)
Differential Revision: https://phabricator.services.mozilla.com/D9304
--HG--
extra : moz-landing-system : lando
We need to correctly populate the cumulative resolution field in the
ScrollMetadata in order to support zooming. Without this, the cumulative
resolution doesn't include the presShell resolution, and that results in
APZ getting into an inconsistent state.
Currently, the cumulative resolution is populated from the
ContainerLayerParameters object's scale, but in the case of WebRender,
we call ComputeScrollMetadata with an empty ContainerLayerParameters
since don't actually do layer building or rasterization in Gecko.
This patch makes this more explicit by changing the argument to a
Maybe<ContainerLayerParameters> and passing Nothing() from the WebRender
call sites.
In this scenario, we just use the cumulative presShell resolution as
the cumulative resolution, which should be correct for WebRender as
we won't have an "extra" CSS-derived resolution applied on the Gecko
side.
Depends on D9120
Differential Revision: https://phabricator.services.mozilla.com/D9121
--HG--
extra : moz-landing-system : lando
This patch also updates the expectations in the mochitest test_flex_items.html.
Before this commit, the test (incorrectly) expected the mainBaseSize API to
return some items' *final sizes*, because that's what our implementation did
return, up until now. As of this patch, that API will now return the item's
actual flex base size, which means the text expectations need to change.
I'm also adding a new flex item to the test, to exercise a formerly-untested
scenario. And to accommodate this new item, I'm also doubling the width of
the flex container to be sure there's plenty of space.
Differential Revision: https://phabricator.services.mozilla.com/D8476
--HG--
extra : moz-landing-system : lando
Frozen flex items have already been clamped to their min/max sizes, so their
size-change isn't a "how much we want to flex" measurement, and it's not useful
for determining whether the rest of the line is shrinking.
This patch is just adding a `if (!item->IsFrozen())` check around some code,
and reindenting that code, and adjusting a few comments.
This change is necessary to avoid failing the "GrowthState" assertions,
because (for example) a flex item that's clamped to a small max-width
could fool us into thinking we're in a "shrinking" state (since its final
size is smaller than its base size), even though really we're
in a "growth" state and the item was simply clamped. We avoid this
problem by skipping (potentially-clamped) frozen items when determining
the line's GrowthState.
Depends on D8922
Differential Revision: https://phabricator.services.mozilla.com/D9018
--HG--
extra : moz-landing-system : lando
We'd like to be able to record the "desired" (pre-clamped) delta size from
tentatively flexing for these items. That size would be computed during a loop
of the flex layout algorithm -- but we can't do that if we freeze them before
we start flexing. So let's bypass this early freeze so they get a chance to
compute this tentative size, even though they can never have it.
Differential Revision: https://phabricator.services.mozilla.com/D8922
--HG--
extra : moz-landing-system : lando
This commit adds a scroll origin, nsGkAtoms::relative, which can be used to
mark main thread scrolling that can be combined with a concurrent APZ scroll.
The behavior of this is controlled by a pref, apz.relative-update. This pref
is initially activated and is intended as an aid to narrowing down causes
of regressions for users in bug reports.
Relative scroll updates work by tracking the last sent or accepted APZ
scroll offset. This is sent along with every FrameMetrics. Additionally,
a flag is added to FrameMetrics, mIsRelative, indicating whether the
scroll offset can be combined with a potential APZ scroll. When this
flag is set, AsyncPanZoomController will apply the delta between the sent
base scroll offset, and sent new scroll offset.
This flag is controlled by the last scroll origin on nsGfxScrollFrame. The
new origin, `relative`, is marked as being able to clobber APZ updates,
but can only be set if all scrolls since the last repaint request or
layers transaction have been relative.
Differential Revision: https://phabricator.services.mozilla.com/D8234
--HG--
extra : rebase_source : 51351a84c9cda228a0975e22eda3fd3bd8d261c4
extra : histedit_source : 4b564c19b16fe2bd26adc671b62b7cb6106e8163
This commit changes `Window::ScrollBy` and `Element::ScrollBy` to use
ScrollByCSSPixels in preparation for marking ScrollByCSSPixels as a
relative scroll API.
Differential Revision: https://phabricator.services.mozilla.com/D8233
--HG--
extra : rebase_source : fa82acc12395569bd332573718f8a8013ac20b60
extra : histedit_source : 7ac061e65a2522051ed73f3ba6349d5ea696e15f
PresShell::PageMove() climbs up to parent document when there is no scrollable
parent in current document. However, if aExtend is true, it should expand
Selection in the document itself. Therefore, it needs different rules to
look for container of expanding Selection from scrollable element to scroll.
Additionally, old rules (i.e., before the fix of bug 1369072 which caused
this regression) were also buggy. It used parent scrollable element or
root scrollable element simply. Therefore, if found scrollable element is
ancestor of selection limiter, it didn't work as expected.
This patch creates nsFrameSelection::GetFrameToPageSelect() to retrieve
per-page selection container element with the following rules:
- look for a scrollable element in selection limiter.
- if there is no scrollable element, use selection limiter.
- if there is no selection limiter, use the root frame.
So, nsFrameSelection::CommonPageMove() should take nsIFrame rather than
nsIScrollableFrame since container of per-page selection may be used in
non-scrollable contenteditable element. If it's called with non-scrollable
frame, it needs to compute the expanding range with the frame size.
Differential Revision: https://phabricator.services.mozilla.com/D8954
--HG--
extra : moz-landing-system : lando
In order to get the correct computed value of these keywords, we have to
make sure we store the correct computed values in sizing properties in
both inline axis and block axis.
-moz-max-content and -moz-min-content should behave as the property's
initial value in block axis. -moz-fit-content and -moz-available are not
supported in block axis, so we also treat them as initial values.
Differential Revision: https://phabricator.services.mozilla.com/D8290
--HG--
extra : moz-landing-system : lando
nsRefreshDriver::ObserverArray is a nsTObserverArray which is
infallible, so no need to check the return value from AppendElement
(which a later patch in this series will remove).
This field appears to be only ever used as a local variable, and can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D7126
--HG--
extra : rebase_source : 310057f703f4734ba9aef807100c5b5ff888da41
extra : histedit_source : 735d3f09bdb56d6eb386e2b5faffea1d769d97a1
It's not really invalidated anywhere, and the float manager code only checks for
float region changes. Extend it so that it knows about shapes as well, and avoid
reframing due to a bogus nsChangeHint_ScrollbarChange which really meant to be
UpdateOverflow, which really is useless in this situation..
Differential Revision: https://phabricator.services.mozilla.com/D7583
The CSSWG has recently resolved that layout containment
suppress baseline alignment, while size containment does not:
https://github.com/w3c/csswg-drafts/issues/2995
Spec text (https://drafts.csswg.org/css-contain/#containment-layout):
"7. For the purpose of the vertical-align property,
or any other property whose effects need to relate
the position of the containing element's baseline
to something other than its descendants,
the containing element is treated as having no baseline."
And a note in (https://drafts.csswg.org/css-contain/#containment-size):
"Note: size containment does not suppress baseline alignment.
See layout containment for that."
This patch does this change just switching IsContainSize()
by IsLayoutSize() in several places related to baseline alignment
in the source code.
With the patch several WPT tests start to pass. Apart from that,
some of the tests under vendor-imports are updated to follow
the new behavior.
--HG--
extra : amend_source : 05dc9a320afeb1d58981e2bd8bc47b435999f2f9
Before this patch, TextOverflow had an explicitly-*defaulted* default
constructor. But in fact, this constructor was *implicitly* deleted because one
of the member variables (of type LogicalRect) couldn't be default-constructed
due to having its own default constructor explicitly deleted.
clang trunk highlights this inconsistency with a build warning
(-Wdefaulted-function-deleted) which this patch addresses.
Differential Revision: https://phabricator.services.mozilla.com/D8028
--HG--
extra : moz-landing-system : lando
If we're waiting on an interrupt, then our child items haven't been totally
reflowed and our measures would be bogus.
This will probably regress performance in the cases bug 1209697 fixed, so we
should probably add an interrupt check somewhere in nsFlexContainerFrame to
avoid keeping reflowing flex containers indefinitely.
We could probably just bail out from our reflow if any kid reflow was
interrupted.
Filed bug 1495532 to consider that.
Differential Revision: https://phabricator.services.mozilla.com/D7288
--HG--
extra : moz-landing-system : lando
Once again, calculating the amount of font size inflation isn't as expensive as
it used to be, but there's still no need to do it unnecessarily. The current
code does this unconditionally as part of computing a frame's margins
Additionally, calculating the font size inflation for frames that we don't
actually want to inflate also messes with the planned writing mode assertions
from bug 1428670. In some special cases (e.g. the scroll bars), a frame might
use a different writing mode (horizontal/vertical) than its parent without
creating a new font inflation flow root at the boundary. As long as we never
want to apply font size inflation for that frame this is okay, but if the margin
computation then runs the font inflation calculation regardless, we have a
problem.
Differential Revision: https://phabricator.services.mozilla.com/D7329
--HG--
extra : moz-landing-system : lando
When one of the two factors governing the effective container width for font
inflation changes, we need to mark all affected frames as dirty.
While the visible area commonly changes because of viewport changes and we can
catch those through the check for ISize resizes of the top-level frame
("!mFrame->GetParent() && isIResize"), it still seems nicer to move calculation
of the effective container width into the FontInflationData itself, especially
since the effective container width calculation in nsLayoutUtils is the only
consumer of the NCAISize currently stored by the FontInflationData.
That way
- we can be sure that really all changes of the visible width will correctly
mark all affected frames as dirty
- can avoid repeatedly recalculating the effective container width
- can also detect the cases where the effective container width actually remains
the same after a change in one of its input factors and skip forcing a full
dirty reflow for all descendants just because of font inflation.
While the code in nsLayoutUtils was technically always using the writing
mode (horizontal/vertical) of each individual frame for determining which
dimension of the visible size should be used for clamping, just using the
writing mode of the respective flow root should be enough, since each change in
the writing mode should create a new flow root.
This assumption should already hold today because
1. as per the Writing Modes CSS spec, a change in writing mode compared to its
parent means that the affected block cannot be purely "inline", but at most
"inline-block".
2. Generally, any non-inline frame will be marked as a font inflation container.
3. Any block frame whose writing direction doesn't match its parent will be a
block formatting context, which implies NS_BLOCK_FLOAT_MGR.
4. Any block frame that has both NS_BLOCK_FLOAT_MGR set and is a font inflation
container will also become a font inflation flow root.
but because this chain of reasoning is not the most direct, we also add a
corresponding assertion to better catch any potential bugs here.
Differential Revision: https://phabricator.services.mozilla.com/D5578
--HG--
extra : moz-landing-system : lando
Before bug 1308876, child frames marked themselves as dirty during reflow if
their parent was dirty, too. After bug 1308876, the point where dirtiness is
being propagated to a frame's descendants has been shifted: Now, dirty parents
are responsible for marking all their children as dirty, too, when the parent
starts reflowing.
This means that if a frame wants to mark a whole subtree as dirty *during its
own* reflow, it's no longer sufficient to just mark the root of the subtree as
dirty and then rely on all further children marking themselves as dirty as well
when reflow reaches them.
The font inflation code is one such case. When the font inflation data on a font
inflation flow root has become dirty, or we're resizing the top-level frame
(which because of the effective container width clamping from bug 707855 can
affect the font inflation font size as well), we now need to explicitly mark all
affected children as dirty.
Differential Revision: https://phabricator.services.mozilla.com/D5577
--HG--
extra : moz-landing-system : lando
In bug 1488300 xidorn make us kick off loading of masks/filters/clipPaths in
resource documents when the style context is set so that the 'load' event
will be blocked until they load. I missed that in 5177bb8cb2ce (bug 1494355)
where we stopped creating the SVGFilterObserverList in
SVGObserverUtils::GetEffectProperties since I missed that creating that object
looks up the target element (without observing it), which triggers loading of
external resources as necessary.
Differential Revision: https://phabricator.services.mozilla.com/D7188
--HG--
extra : rebase_source : 698fe4b437660761e457ecf54d8d604a098229db
extra : amend_source : 3ae9f25761372ee6a33bd4043c7bf6183361ca58
This patch make nsCSSFrameConstructor::CreateGeneratedContentItem() early
returns if the originating element contains an UA Widget shadow root.
Differential Revision: https://phabricator.services.mozilla.com/D6828
--HG--
extra : moz-landing-system : lando
nsCSSFrameConstructor::FindDisplayData() guarantees a block with "display:
list-item" will be constructed by ConstructBlock() (either through
ConstructScrollableBlock() or ConstructNonScrollableBlock()).
This is also a preparation to fix bug 1491915 since we want to control
bullet frame creation under column hierarchy.
Depends on D6840
Differential Revision: https://phabricator.services.mozilla.com/D6841
--HG--
extra : moz-landing-system : lando
Those arguments were added in bug 591737 to create a triangle for the
summary frame, but <summary> has been re-implemented by using "list-item"
since then. Now the only caller is nsBlockFrame itself, so there's no need
to expose those arguments.
Differential Revision: https://phabricator.services.mozilla.com/D6839
--HG--
extra : moz-landing-system : lando
It's queried during layer building, for the RCD-RSF only. If we set it for
a subframe RSF, that overwrites the value for the RCD-RSF, and we end up
querying the incorrect value.
Differential Revision: https://phabricator.services.mozilla.com/D6536
--HG--
extra : moz-landing-system : lando
This patch isn't expected to change behavior; it's just some simplification.
Depends on D6976
Differential Revision: https://phabricator.services.mozilla.com/D6978
--HG--
extra : moz-landing-system : lando
This patch isn't expected to change behavior; it's just some simplification.
Differential Revision: https://phabricator.services.mozilla.com/D6976
--HG--
extra : moz-landing-system : lando
A flex item's available inline size would be relevant (i.e. would have an
impact on layout) if we were fragmenting the flex item in its inline direction
(e.g. if it were an inline-level box, in an inline-layout context).
But we're not doing that, so its available isize doesn't make a difference. To
the extent that it's been useful at all in this flex-item-caching code up to
this point, we'll now be caching something more-specific (the item's *computed*
inline size) which should serve roughly the same purpose.
Depends on D6991
Differential Revision: https://phabricator.services.mozilla.com/D6992
--HG--
extra : moz-landing-system : lando
Kartikaya Gupta
Margareta Eliza Balazs
Coroiu Cristina
Mats Palmgren
Ting-Yu Lin
Emilio Cobos Álvarez
Razvan Maries
Boris Zbarsky
Daniel Holbert
Brad Werth
Cosmin Sabou
Kristen Wright
arthur.iakab
Timothy Guan-tin Chien
Jonathan Kew
Jonathan Watt
Andreea Pavel
Gerald Squelart
Hiroyuki Ikezoe
Randell Jesup
Gurzau Raul
Botond Ballo
Csoregi Natalia
Ryan Hunt
Nazım Can Altınova
shindli
Noemi Erli
Andrew Osmond
Miko Mynttinen
Boris Chiou
Julian Descottes
Xidorn Quan
Masayuki Nakano
Diego Pino Garcia
Manuel Rego Casasnovas
Edgar Chen
Narcis Beleuzu
Nicholas Nethercote
Kevin Chen
Jan Henning
Ting-Yu Lin