Bug 1102175 Part 1 only handles HTML documents correctly because they
always have a body element (even if the <body> tag is not written
explicitly in the document). For SVG documents and all other documents
lacking <body> element, we always want to propagate mWritingMode from
the root element, which is our old behavior prior to Bug 1102175.
Note that mDocElementContainingBlock (i.e. nsCanvasFrame) is using
viewport's style, so we need to use the root element's computed style to
compute WritingMode for propagating.
Differential Revision: https://phabricator.services.mozilla.com/D49695
--HG--
extra : moz-landing-system : lando
Most of these tests have been disabled for a long time; they run well
in the current test environment.
With the additional tests running, task times increase; I have added one
more test chunk for android mochitest-plain.
These tests were identified from a random sampling of mochitest manifests;
I intend to enable more mochitests in future patches.
Differential Revision: https://phabricator.services.mozilla.com/D48912
--HG--
extra : moz-landing-system : lando
From https://drafts.csswg.org/css-overflow/#overflow-propagation:
> UAs must apply the overflow-* values set on the root element to the viewport.
> However, when the root element is an [HTML] html element (including XML syntax
> for HTML) whose overflow value is visible (in both axes), and that element has
> a body element as a child, user agents must instead apply the overflow-*
> values of the first such child element to the viewport. The element from which
> the value is propagated must then have a used overflow value of visible.
This was out of sync with Document::IsScrollingElement, which implements the
right thing.
Differential Revision: https://phabricator.services.mozilla.com/D49196
--HG--
extra : moz-landing-system : lando
From https://drafts.csswg.org/css-overflow/#overflow-propagation:
> UAs must apply the overflow-* values set on the root element to the viewport.
> However, when the root element is an [HTML] html element (including XML syntax
> for HTML) whose overflow value is visible (in both axes), and that element has
> a body element as a child, user agents must instead apply the overflow-*
> values of the first such child element to the viewport. The element from which
> the value is propagated must then have a used overflow value of visible.
This was out of sync with Document::IsScrollingElement, which implements the
right thing.
Differential Revision: https://phabricator.services.mozilla.com/D49196
--HG--
extra : moz-landing-system : lando
The TextNodeCorrespondenceRecorder stuff doesn't handle display: contents or
Shadow DOM at all. This causes a failure with an upcoming patch.
This patch fixes it and fixes related crashes like bug 1563779. This is the same
wallpaper as bug 1421807.
Differential Revision: https://phabricator.services.mozilla.com/D49138
--HG--
extra : moz-landing-system : lando
For huge sizes we may end up with an unconstrained isize. Just avoid sizing the
window to that.
Differential Revision: https://phabricator.services.mozilla.com/D49062
--HG--
extra : moz-landing-system : lando
We could put this change itself behind a pref too, if we considered that worth
it. But probably not so.
Differential Revision: https://phabricator.services.mozilla.com/D48010
--HG--
extra : moz-landing-system : lando
I use `warningFlag` instead of `infoFlag` because even if the principal
writing-mode propagation is written in the spec, its effect might
surprise the developers.
Differential Revision: https://phabricator.services.mozilla.com/D48774
--HG--
extra : moz-landing-system : lando
I'm not happy about all the SVG text / disallow out of flow complexity sprinkled
during frame construction... :(
Maybe we should add some kind of more generic mechanism to disallow some
children for particular kinds of frames, or something.
Co-authored-by: Mats Palmgren <mats@mozilla.com>
Differential Revision: https://phabricator.services.mozilla.com/D44808
--HG--
extra : moz-landing-system : lando
We were keeping nsDocShell::mHistoryId and nsDocShell::mOSHE as keys. They
weren't quite good because:
1. While loading an iframe, they were being registered twice with the same
ids(for about:blank and the real URL) sometimes.
2. It wasn't possible to access to the parent mHistoryId and mOSHE from a child
processes if the parent is in a different process. That may not be the case for
now, but it will be after fission.
So we had to find other IDs to:
1. Determine the Tab of the frames.
2. Determine the URLs of the frames.
For the first use case, we were using nsDocShell::mHistoryId for that purpose
but that was wrong. The closest thing that we can get to a tab ID is
BrowsingContext ID because they don't change after a navigation. But iframes
have different BrowsingContext's, so we still need to create a tree to
construct a tab content. That can be either in the front-end or capture time.
For the second use case, we were using a key pair of mHistoryId and mOSHE. We
now chose to keep inner window IDs for that purpose. Inner window IDs are
unique for each navigation loads because inner window correspond to each JS
window global objects. That's why we can use that without any problem. But one
problem is that we cannot handle `history.pushState` and `history.replaceState`
changes with that change since window global objects won't change during those.
But that was the best thing we can do after fission. So this will be a small
sacrifice for us to keep that functionality working after fission.
In that patch we also remove the registration/unregistration calls. We are
going to add those calls in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D47065
--HG--
extra : moz-landing-system : lando
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
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
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 places where profiler_is_active() was used around a profiler_add_marker() (or
similar) call, replace it with profiler_can_accept_markers().
Differential Revision: https://phabricator.services.mozilla.com/D44435
--HG--
extra : moz-landing-system : lando
In places where profiler_is_active() was used around a profiler_add_marker() (or
similar) call, replace it with profiler_can_accept_markers().
Differential Revision: https://phabricator.services.mozilla.com/D44435
--HG--
extra : moz-landing-system : lando
When we call nsContentUtils::IsPatternMatching, we swallow JS engine errors
unconditionally returning true.
This is bad, because if it happens in one of the value sets that arguably
shouldn't change the state of the element, we end up returning an arbitrary
value (true) which may or may not match the previous state of the element.
Handle error explicitly instead, by not updating the state.
Differential Revision: https://phabricator.services.mozilla.com/D45727
--HG--
extra : moz-landing-system : lando
Rounding in layout pixels is very close to snapping in raster pixels if
there are no transforms involved. This is why it worked most of the time
and fell flat in many edge cases. In future parts of this series, we
will trust scene building and frame building to do the heavy lifting for
snapping purposes.
Differential Revision: https://phabricator.services.mozilla.com/D45058
--HG--
extra : moz-landing-system : lando
Rounding in layout pixels is very close to snapping in raster pixels if
there are no transforms involved. This is why it worked most of the time
and fell flat in many edge cases. In future parts of this series, we
will trust scene building and frame building to do the heavy lifting for
snapping purposes.
Differential Revision: https://phabricator.services.mozilla.com/D45058
--HG--
extra : moz-landing-system : lando
Rounding in layout pixels is very close to snapping in raster pixels if
there are no transforms involved. This is why it worked most of the time
and fell flat in many edge cases. In future parts of this series, we
will trust scene building and frame building to do the heavy lifting for
snapping purposes.
Differential Revision: https://phabricator.services.mozilla.com/D45058
--HG--
extra : moz-landing-system : lando
Now that this code path is on its own, we can write more straight-forward code.
Depends on D43799
Differential Revision: https://phabricator.services.mozilla.com/D43800
--HG--
extra : moz-landing-system : lando
This is much easier than the existing ResizeReflowIgnoreOverride function, and
this will allow me to avoid flushing if needed (we already kinda do that
already with the "suppressResizeReflow" thing), which in turn allows me to
consolidate a bunch of the logic for resizes.
The function should be much easier to follow:
* Set the new viewport (async, doesn't do any work).
* Invalidate layout as needed due to the viewport change (that is, resize hint
for the root frame, and invalidate isizes if needed). Also async and doesn't
do any reflowing itself.
* Flush layout / do the reflowing all at once. I think we can stop doing this
much more often now, but that's follow-up work.
Depends on D43798
Differential Revision: https://phabricator.services.mozilla.com/D43799
--HG--
extra : moz-landing-system : lando
Rounding in layout pixels is very close to snapping in raster pixels if
there are no transforms involved. This is why it worked most of the time
and fell flat in many edge cases. In future parts of this series, we
will trust scene building and frame building to do the heavy lifting for
snapping purposes.
Differential Revision: https://phabricator.services.mozilla.com/D45058
--HG--
extra : moz-landing-system : lando
This is the only short-term fix for now until we fix editor or find a
test-case...
This will keep asserting on Nightly, but the correctness issue it'd show in
release (some pseudo-classes not matching) is better than crashing.
Differential Revision: https://phabricator.services.mozilla.com/D45575
--HG--
extra : moz-landing-system : lando
If a <details> is a multi-column container, and has a column-span child
inside, aFrame can be ColumnSetWrapper or column-span-wrapper frame (due
to GetInsertionPrevSibling()'s modification). The latter case is handled
by "Situation #5 in WipeContainingBlock(), and can be reproduced by
changing `<article>` tag to `<details>` in
testing/web-platform/tests/css/css-multicol/multicol-span-all-dynamic-add-005.html
In any case, aFrame might end up in a frame generated by the <details>
element. I feel the assertion to check frame types might not be very
useful. Let's remove it.
Differential Revision: https://phabricator.services.mozilla.com/D45585
--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
If the <details> has ::first-letter, insertion.mParentFrame may be
modified by GetInsertionPrevSibling(), and points to nsFirstLetterFrame.
Fortunately, nsFirstLetterFrame's content is the details element. We can
check the content to determine if reframing the <details> is needed.
Also, add a reftest to test that an appended text should apply styles in
details::first-line.
Differential Revision: https://phabricator.services.mozilla.com/D45454
--HG--
extra : moz-landing-system : lando
In the next part, the patch generated by a script removes "-moz" prefix
to all multi-column properties.
However, some of the tests already have standard multi-column properties
specified. To avoid duplicating CSS multi-column rules in these
files (after applying the next part), I manually remove the prefixed
rules beforehand as many as possible.
Differential Revision: https://phabricator.services.mozilla.com/D44869
--HG--
extra : moz-landing-system : lando
When we had it in the loop, we would continually reduce it, which held the
possibility of bumping it down an epoch due to double imprecision. Now
we only reduce it once, using all rAF callbacks get the same timestamp.
Differential Revision: https://phabricator.services.mozilla.com/D44526
--HG--
extra : moz-landing-system : lando
All calls to `profiler_add_marker()` (outside of the profilers code) are
now replaced by either:
- `PROFILER_ADD_MARKER(name, categoryPair)`
- `PROFILER_ADD_MARKER_WITH_PAYLOAD(name, categoryPair, TypeOfMarkerPayload,
(payload, ..., arguments))`
This makes all calls consistent, and they won't need to prefix the category pair
with `JS::ProfilingCategoryPair::`.
Also it will make it easier to add (and later remove) internal-profiling
instrumentation (bug 1576550), and to replace heap-allocated payloads with
stack-allocated ones (bug 1576555).
Differential Revision: https://phabricator.services.mozilla.com/D43588
--HG--
extra : moz-landing-system : lando
In Bug 1387894 we created a mode for Firefox where it unconditionally clamps all timestamps to 20 microseconds. This happens if you disable privacy.reduceTimerPrecision (which is on by default) and is so we don't inadvertently leak super-high-resolution (nanosec) timestamps.
As part of that patch, we started clamping animation timestamps - which are exempted from privacy.reduceTimerPrecision because it was too difficult to get them working at the time. (We should still fix that though.)
This caused new test failures, and one of those was a comparison between document timelines and the timestamp in requestAnimationFrame. we were not clamping the timestamp in requestAnimationFrame under the logic that it fires in predictable intervals.
However discussions about the WPT change we made to 'fix' the now-broken comparison https://github.com/web-platform-tests/wpt/pull/18172 and https://github.com/web-platform-tests/wpt/pull/18357 showed me that document.timeline is supposed to be slaved to the requestAnimationFrame timestamp (or vice versa.)
The correct fix is therefore to unconditionally clamp the requestAnimationFrame timestamp AND the document.timeline timestamp. In doing so we also start clamping/jittering the requestAnimationFrame timestamp in Resist Fingerprinting mode, so that might cause some new/unexpected behaviors for that mode we should watch out for.
Differential Revision: https://phabricator.services.mozilla.com/D43788
--HG--
extra : moz-landing-system : lando
This avoids doing wasted work and sending spurious resize
events if this case would be hit.
In practice, it cannot be hit yet, I think, because
callers do check for this and bail out earlier. But
there's no assertion to that respect so this shouldn't
hurt.
Differential Revision: https://phabricator.services.mozilla.com/D43798
--HG--
extra : moz-landing-system : lando
Converted the following to StaticPrefs so that we can easily test variations:
NS_GC_DELAY
NS_SHRINK_GC_BUFFERS_DELAY
NS_FIRST_GC_DELAY
NS_FULL_GC_DELAY
NS_INTERSLICE_GC_DELAY
NS_USER_INTERACTION_INTERVAL
Differential Revision: https://phabricator.services.mozilla.com/D43112
--HG--
extra : moz-landing-system : lando
Some of it was dead code, another was inlining a not very useful function (and
in one case redundant, since EnsureInitialized() happened right after
Refresh()).
Differential Revision: https://phabricator.services.mozilla.com/D43042
--HG--
extra : moz-landing-system : lando
Rather than short circuit the refresh driver, this instead only bypasses painting on
Android when WebVR is in immersive mode.
Differential Revision: https://phabricator.services.mozilla.com/D42973
--HG--
extra : moz-landing-system : lando
Removes vsync.parentProcess.highPriority pref and stores BrowserTabsRemoteAutostart() directly into sHighPriorityEnabled.
Differential Revision: https://phabricator.services.mozilla.com/D42962
--HG--
extra : moz-landing-system : lando
Collect telemetry for the number of pending style and layout flush requests per
flush and the number of style and layout flushes per nsRefreshDriver::Tick. A
style flush reports only style requests, but a layout flush reports style and
layout requests since flushing layout implies a style flush also.
Differential Revision: https://phabricator.services.mozilla.com/D40756
--HG--
extra : moz-landing-system : lando
I replaced the values with -moz-inline-box in the crashtests
rather than removing them. I think they are still valuable
after replacing the display value.
Differential Revision: https://phabricator.services.mozilla.com/D42551
--HG--
extra : moz-landing-system : lando
This condition was needed when FindInsertionPrevSibling and co didn't understand
display: contents.
Editor is pretty broken (and calls into PresShell::ContentRemoved directly, and
incorrectly, using anonymous nodes).
In this case we were taking the XBL path because of display: contents, which
means that we tried to seek to the editor anonymous node, and crash (since it's
not an explicit kid).
Editor needs to get fixed, but this is technically more correct and fixes the
crash, so we may as well take it in the interim.
Differential Revision: https://phabricator.services.mozilla.com/D42472
--HG--
extra : moz-landing-system : lando
When contents notify IME or requests something to IME, they need to use
an `nsIWidget` instance which may have focus if active, and handles
native keyboard/IME events since that knows correct native IME context.
Currently, such widget exactly matches with the result of
`nsPresContext::GetRootWidget()`. However, this is unclear for most developers.
Therefore, this patch creates a wrapper method of it named
`nsPresContext::GetTextInputHandlingWidget()`. Then, also adds
`BrowserParent::GetTextInputHandlingWidget()` wraps it. Finally, makes
`IMEStateManager` call `GetTextInputHandlingWidget()` of them.
Differential Revision: https://phabricator.services.mozilla.com/D42301
--HG--
extra : moz-landing-system : lando
Resolution is at:
* https://github.com/w3c/csswg-drafts/issues/3779#issuecomment-481762912
Tests are at https://chromium-review.googlesource.com/c/chromium/src/+/1547974,
I'll make sure to wait until they're in the tree and ensure they're passing.
Note that we need to ensure in the frame constructor that the document element
is styled _before_ calling UpdateViewportScrollStylesOverride(). This saves
duplicated work (since ResolveStyleLazily throws away the style).
ResolveStyleLazily already returns out of date styles, unless the element is not
styled yet, or is in a `display: none` subtree, in which case it computes and
returns a new (up-to-date) style.
So the switch to the FFI call only should change behavior for the display: none
subtree case (since we ensure the unstyled case isn't hit by styling the
document earlier). But that case is one of the cases we're interested in
changing, conveniently.
Depends on D40080
Differential Revision: https://phabricator.services.mozilla.com/D39204
--HG--
extra : moz-landing-system : lando
Return a raw pointer instead of a strong reference to a ComputedStyle, and
handle the case of the style not being present by returning null rather than
requiring an extra function to check it and crashing if the precondition is not
met.
Also, name them so that it's clear they just return outdated styles and don't
make any extra effort.
This is just cleanup that makes the next patch easier / more obvious.
Differential Revision: https://phabricator.services.mozilla.com/D40080
--HG--
extra : moz-landing-system : lando
They're bad, specially if they do vastly different thing in overloaded
functions, like aUseSystemPrincipal and aIsPreload. :)
Differential Revision: https://phabricator.services.mozilla.com/D40851
--HG--
extra : moz-landing-system : lando
This patch is auto-generated by the following command:
./mach clang-format -p layout/
Differential Revision: https://phabricator.services.mozilla.com/D42218
--HG--
extra : moz-landing-system : lando
Emilio Cobos Álvarez
Ting-Yu Lin
Frederic Wang
Hiroyuki Ikezoe
Gijs Kruitbosch
Razvan Maries
Geoff Brown
Coroiu Cristina
Cosmin Sabou
Oana Pop Rus
Gurzau Raul
Nazım Can Altınova
Brendan Dahl
Emma Malysz
Jeff Muizelaar
Botond Ballo
Neil Deakin
Sylvestre Ledru
Tom Ritter
Boris Chiou
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
Adam Gashlin
Randall E. Barker
Gerald Squelart
Bogdan Tara
Andrew Osmond
Ciure Andrei
Brad Werth
Mihai Alexandru Michis
L. David Baron
Andrew Creskey
Mats Palmgren
Mike Hommey
Kristen Wright
Dan Glastonbury
Masayuki Nakano