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
Run broken-column-rule-1.html with column-span enabled because it was
regressed by Bug 1548100 Part 2, but fixed by this patch.
Differential Revision: https://phabricator.services.mozilla.com/D41907
--HG--
extra : moz-landing-system : lando
The counting code was incrementing the start counter twice for <li value>, as it
generates both an increment and a reset.
We should instead only increment it once per list-item, that is, once per
increment.
Differential Revision: https://phabricator.services.mozilla.com/D42001
--HG--
extra : moz-landing-system : lando
The fixed still worked because we get another SetBounds call right after with the same bounds. But it does mean we are doing some useless invalidation.
Differential Revision: https://phabricator.services.mozilla.com/D42059
--HG--
extra : moz-landing-system : lando
Converts layout.css.outline-style-auto.enabled to a static pref and removes nsLayoutUtils::isOutlineStyleAutoEnabled().
Differential Revision: https://phabricator.services.mozilla.com/D41861
--HG--
extra : moz-landing-system : lando
Converts layout.idle_period.required_quiescent_frames and layout.idle_period.time_limit to static prefs. These are the last prefs in nsLayoutUtils::initialize(), but since the function still calls nsComputedDOMStyle::RegisterPrefChangeCallbacks() the commit retains it.
Differential Revision: https://phabricator.services.mozilla.com/D41856
--HG--
extra : moz-landing-system : lando
svg.transform-box.enabled is already a static pref, so I removed the varcache definition of it in nsLayoutUtils.
Differential Revision: https://phabricator.services.mozilla.com/D41850
--HG--
extra : moz-landing-system : lando
Converts layout.interruptible-reflow.enabled to a static pref and updates its usage.
Differential Revision: https://phabricator.services.mozilla.com/D41849
--HG--
extra : moz-landing-system : lando
Converts nglayout.debug.invalidation to a static pref. Retains the old getter function from the old static bool, because it makes an additional comparison.
Differential Revision: https://phabricator.services.mozilla.com/D41845
--HG--
extra : moz-landing-system : lando
Converts zoom.maxPercent and zoom.minPercent to static prefs, which creates a new "zoom" category on StaticPrefList.yaml.
Differential Revision: https://phabricator.services.mozilla.com/D41835
--HG--
extra : moz-landing-system : lando
Converts font.size.systemFontScale to a static pref. Removes the function in nsLayoutUtils and does the float division directly in PresShell.
Differential Revision: https://phabricator.services.mozilla.com/D41824
--HG--
extra : moz-landing-system : lando
Converts font.size.inflation.forceEnabled and font.size.inflation.disabledInMasterProcess to static prefs. Like previous revisions, I retained the member variables in PresShell and set them to the static prefs.
Differential Revision: https://phabricator.services.mozilla.com/D41664
--HG--
extra : moz-landing-system : lando
Converts font.size.inflation.lineThreshold varcache pref to a static pref. Like previous revisions, this retains the member variable in PresShell.
Differential Revision: https://phabricator.services.mozilla.com/D41662
--HG--
extra : moz-landing-system : lando
Converts font.size.inflation.minTwips, font.size.inflation.emPerLine, and font.size.inflation.mappingIntercept to static prefs and removes their associated functions from nsLayoutUtils. There are associated member variables in PresShell, but since documentation specified that these variables are set specifically to prevent changes to the cache from being read until page reload, I made the decision to leave these and set them to the static prefs.
Differential Revision: https://phabricator.services.mozilla.com/D41656
--HG--
extra : moz-landing-system : lando
Creates the new 'font' category in StaticPrefList.yaml and adds font.size.inflation.maxRatio to the category. Removes the old static uint in nsLayoutUtils and the function that returns it.
Differential Revision: https://phabricator.services.mozilla.com/D41654
--HG--
extra : moz-landing-system : lando
Converts layout.css.ruby.intercharacter.enabled to a static pref and removes the associated function nsLayoutUtils::IsInterCharacterRubyEnabled(). Also removes the macro INTERCHARACTER_RUBY_ENABLED_PREF_NAME, since it was only being used to add the varcache pref.
Differential Revision: https://phabricator.services.mozilla.com/D41653
--HG--
extra : moz-landing-system : lando
Converts layout.animated-image-layers.enabled to a static pref and removes the nsLayoutUtils::AnimatedImageLayersEnabled() function, replacing it with the static pref.
Differential Revision: https://phabricator.services.mozilla.com/D41652
--HG--
extra : moz-landing-system : lando
Converts layers.offmainthreadcomposition.async-animations and layers.offmainthreadcomposition.log-animations to their respective static prefs. Since all IsAnimationLoggingEnabled() did was create a pref and return the variable sShouldLog, this function is removed and replaced with the static pref.
Differential Revision: https://phabricator.services.mozilla.com/D41651
--HG--
extra : moz-landing-system : lando
All .xul files have been loading as HTMLDocuments for a few weeks now, so
it should be safe to remove the XULDocument implementation.
Differential Revision: https://phabricator.services.mozilla.com/D41238
--HG--
extra : moz-landing-system : lando
It was made pointless by the previous patch.
This replaces callers that had a frame type for another reason with the
frame type check that IsTableCell did, and callers that needed to call
Type() with an IsTableCellFrame call.
Differential Revision: https://phabricator.services.mozilla.com/D40561
--HG--
extra : moz-landing-system : lando
This also renames the existing infallible nsDocShell:GetBrowsingContext()
getter to BrowsingContextRef(), and changes the return type, since several
callers rely on it returning a raw pointer rather than an already_AddRefed.
Differential Revision: https://phabricator.services.mozilla.com/D40312
--HG--
extra : moz-landing-system : lando
nsTypeAheadFind.cpp contains all of the callsites to this function, so it seems like a logical place for it to live.
Differential Revision: https://phabricator.services.mozilla.com/D40696
--HG--
extra : moz-landing-system : lando
We want mHasColumnSpanSiblings to propagate to all the
continuations (both fixed ones or fluid ones) in nsFrame::Init() so that
we don't need to traverse all the way to FirstInFlow() for the bit in
nsBlockFrame::ComputeFinalBSize().
For the last ColumnSet or the last non-column-span wrapper, we'll need
to unset the bit for them manually after constructing them.
Differential Revision: https://phabricator.services.mozilla.com/D40761
--HG--
extra : moz-landing-system : lando
We naively remove and then recreate accessibles when their content's
frame is reconstructed. By delaying the removal until we are certain the
content does not have a new layout frame, we can cut down on redundant
recreations.
When reconstructed content is re-inserted we can check it and its
subtree for missing frames and prune those accessibles from the tree.
Differential Revision: https://phabricator.services.mozilla.com/D38380
--HG--
extra : moz-landing-system : lando
These frame state bits belong to the generic group, and there is
existing logic in nsFrame::Init() for carrying frame state bits. It's
better to consolidate them in one place.
Differential Revision: https://phabricator.services.mozilla.com/D40244
--HG--
extra : moz-landing-system : lando
Not happy with all these void pointer stuff, but I think this is slightly nicer
to read.
Also not happy with what clang-format has done to my code ;)
I've removed the comment about zoom because it's not clear to me it is still
relevant, but I've preserved the order because, should we have similar stuff
going on, it seems slightly better, and I'm moderately sure the rest of the
callers don't really care.
I think closures coerced to function pointers are nicer (I considered putting
this on a template or using std::function, maybe, this was less code specially
given some callers of EnumerateExternalResources may or may not be hot...),
but if you want me to keep stuff out of line, or move the whole thing to
std::function<> or templates let me know.
Differential Revision: https://phabricator.services.mozilla.com/D40249
After enabling column-span, ColumnSet becomes an anonymous child under
ColumnSetWrapperFrame. It doesn't need to handle border and padding,
containment, and non-auto block-size. ColumnSet's final block-size is
simply the union of ::-moz-column-content frames' rects.
However, we should extend ColumnSet's block-size to consume the
available block-size if the ColumnSetWrapper's block-size is constrained
so that the column rules are drawn to the block-end edge of the multicol
container.
Differential Revision: https://phabricator.services.mozilla.com/D39060
--HG--
rename : testing/web-platform/meta/css/css-multicol/multicol-breaking-000.html.ini => testing/web-platform/meta/css/css-multicol/multicol-rule-nested-balancing-001.html.ini
rename : testing/web-platform/meta/css/css-multicol/multicol-breaking-000.html.ini => testing/web-platform/meta/css/css-multicol/multicol-rule-nested-balancing-002.html.ini
rename : testing/web-platform/meta/css/css-multicol/multicol-breaking-000.html.ini => testing/web-platform/meta/css/css-multicol/multicol-span-all-rule-001.html.ini
extra : moz-landing-system : lando
After enabling column-span, ColumnSet becomes an anonymous child under
ColumnSetWrapperFrame. It doesn't need to handle border and padding,
containment, and non-auto block-size. ColumnSet's final block-size is
simply the union of ::-moz-column-content frames' rects.
However, we should extend ColumnSet's block-size to consume the
available block-size if the ColumnSetWrapper's block-size is constrained
so that the column rules are drawn to the block-end edge of the multicol
container.
Differential Revision: https://phabricator.services.mozilla.com/D39060
--HG--
rename : testing/web-platform/meta/css/css-multicol/multicol-breaking-000.html.ini => testing/web-platform/meta/css/css-multicol/multicol-rule-nested-balancing-001.html.ini
rename : testing/web-platform/meta/css/css-multicol/multicol-breaking-000.html.ini => testing/web-platform/meta/css/css-multicol/multicol-rule-nested-balancing-002.html.ini
rename : testing/web-platform/meta/css/css-multicol/multicol-breaking-000.html.ini => testing/web-platform/meta/css/css-multicol/multicol-span-all-rule-001.html.ini
extra : moz-landing-system : lando
Also spam a NS_ERROR whenever this happens (in debug builds), so that we
know to fix the caller to avoid division by zero.
Differential Revision: https://phabricator.services.mozilla.com/D39801
--HG--
extra : moz-landing-system : lando
In frame construction, a block can be split by column-spans into several
fragments and each of the fragments is chained together by non-fluid
continuations. Later in reflow, each fragment can create its own fluid
continuations due to reasons such as the constraint of its available
block-size.
The main idea of this patch is that we calculate the block's final
block-size by shrinkwrapping the children for every fragment except for
those fluid continuations after the final column-span. To do that, we
need to correctly tag each non-column-span-wrappers
nsIFrame::HasColumnSpanSiblings() except the last one.
We also need to modify nsSplittableFrame::ConsumedBSize() so that it
includes the block-size for both fluid and non-fluid continuations.
Differential Revision: https://phabricator.services.mozilla.com/D38124
--HG--
extra : moz-landing-system : lando
When privacy.spoof_english = 2, we should hide the user's
locale in content. So we use en-US default strings for HTML
form elements, such as a Submit button.
We also force GetLocalizedEllipsis() to always return the
ellipsis used by en-US.
Differential Revision: https://phabricator.services.mozilla.com/D35815
--HG--
extra : moz-landing-system : lando
One of the issues with the test-case in this bug is that the page consumes a ton
of CPU due to scroll anchor adjustments being triggered from scroll events,
which in turn cause other scroll events to fire.
This happens in Chrome as well (just scroll to the bottom of the test-case, and
do `addEventListener("scroll", () => console.log("scroll"))` on devtools. But I
think it's worth fixing. This patch fixes it and overall I think it's a slightly
better approach to suppress adjustments than what we're doing.
Differential Revision: https://phabricator.services.mozilla.com/D39339
--HG--
extra : moz-landing-system : lando
If the subdocument display item gets created when the subdocument doesn't have a root frame it'll be based on the subdocument frame in the parent document. This means that the prescontext pointer on the document viewer of the subdocument can go away without the subdocument display item getting any kind of invalidation. So we make sure the subdocument display item gets rebuilt if that happens. The reason the prescontext pointer is important is that is what nsSubDocumentFrame::GetSubdocumentPresShellForPainting uses (via nsDocShell::GetPresShell) to get the subdocument presshell. So it will fail to get a presshell and RetainedDisplayListBuilder::IncrementSubDocPresShellPaintCount will crash.
Differential Revision: https://phabricator.services.mozilla.com/D39310
--HG--
extra : moz-landing-system : lando
When we use SVG layout, and transform-box is fill-box, the current
implementation makes the object not align with offset-path because there
may be an offset (SVG x and y values) between the anchor point and offset-path.
We have to tweak the anchor point to fix the alignment.
Differential Revision: https://phabricator.services.mozilla.com/D39419
--HG--
rename : testing/web-platform/tests/css/motion/offset-anchor-transform-box-fill-box.html => testing/web-platform/tests/css/motion/offset-anchor-transform-box-fill-box-001.html
rename : testing/web-platform/tests/css/motion/offset-anchor-transform-box-fill-box.html => testing/web-platform/tests/css/motion/offset-anchor-transform-box-fill-box-002.html
extra : moz-landing-system : lando
This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
--HG--
extra : moz-landing-system : lando
For a slow tick, where the processing time takes longer than 1/60th sec, record
telemetry for the percentage of that time spent in each sub-system processing
Events, Style), Reflow, Display and Paint.
Differential Revision: https://phabricator.services.mozilla.com/D38962
--HG--
extra : moz-landing-system : lando
This is what other browsers do, and it does make sense to me, it's useless to
try to scroll a frame with no scroll range in a given direction.
I think all callers of this function should be treated like this, so this is
more like a RFC / feedback request than a patch per se.
The wheel handling code already checks scroll range, so there's no difference of
behavior in that case, if I'm reading the code right.
There are a few other functions that check the result of
GetPerceivedScrollingDirections(), but I think if we change this we should
change this consistently.
I also think that if we do this we should rename the method to something like
GetAvailableScrollingDirections() or such.
Anyhow, wdyt? I should also add a test for this if we go with this.
Differential Revision: https://phabricator.services.mozilla.com/D38991
--HG--
extra : moz-landing-system : lando
This is what other browsers do, and it does make sense to me, it's useless to
try to scroll a frame with no scroll range in a given direction.
I think all callers of this function should be treated like this, so this is
more like a RFC / feedback request than a patch per se.
The wheel handling code already checks scroll range, so there's no difference of
behavior in that case, if I'm reading the code right.
There are a few other functions that check the result of
GetPerceivedScrollingDirections(), but I think if we change this we should
change this consistently.
I also think that if we do this we should rename the method to something like
GetAvailableScrollingDirections() or such.
Anyhow, wdyt? I should also add a test for this if we go with this.
Differential Revision: https://phabricator.services.mozilla.com/D38991
--HG--
extra : moz-landing-system : lando
We shouldn't have a frame and a null root frame. This assertion failing is the
only way to get this to happen.
So assert it a bit harder so that we can hopefully find a way to repro it and
thus figure out what the right thing to do is. If it legitimately fails, chances
are we shouldn't be putting this function on PresShell in the first place.
Differential Revision: https://phabricator.services.mozilla.com/D39124
--HG--
extra : moz-landing-system : lando
This is what other browsers do, and it does make sense to me, it's useless to
try to scroll a frame with no scroll range in a given direction.
I think all callers of this function should be treated like this, so this is
more like a RFC / feedback request than a patch per se.
The wheel handling code already checks scroll range, so there's no difference of
behavior in that case, if I'm reading the code right.
There are a few other functions that check the result of
GetPerceivedScrollingDirections(), but I think if we change this we should
change this consistently.
I also think that if we do this we should rename the method to something like
GetAvailableScrollingDirections() or such.
Anyhow, wdyt? I should also add a test for this if we go with this.
Differential Revision: https://phabricator.services.mozilla.com/D38991
--HG--
extra : moz-landing-system : lando
Brindusan Cristian
Tim Nguyen
Daniel Holbert
Emilio Cobos Álvarez
Makoto Kato
Geoff Brown
arthur.iakab
Dorel Luca
Kris Maglione
Daniel Varga
Timothy Nikkel
Edgar Chen
Hiroyuki Ikezoe
Jonathan Kew
Andreea Pavel
Adam Gashlin
Ting-Yu Lin
Randall E. Barker
Gerald Squelart
Boris Chiou
Bogdan Tara
Botond Ballo
Andrew Osmond
Ciure Andrei
Brad Werth
Gurzau Raul
Sylvestre Ledru
shindli
Mihai Alexandru Michis
Gijs Kruitbosch
Tom Ritter
L. David Baron
Andrew Creskey
Mats Palmgren
Mike Hommey
Kristen Wright
Dan Glastonbury
Masayuki Nakano
Noemi Erli
Connor Brewster
Cosmin Sabou
Brendan Dahl
Nika Layzell
Tom Schuster
Razvan Maries
Nicholas Nethercote
Eitan Isaacson
Olli Pettay
Alex Catarineu
Kannan Vijayan
Coroiu Cristina
Narcis Beleuzu