This patch is a mechanical replacement without any reparent, i.e.
passing nullptr as parent into nsFrameList::AppendFrame().
Differential Revision: https://phabricator.services.mozilla.com/D25337
--HG--
extra : moz-landing-system : lando
In order to get rid of nsFrameItems::AddChild() and use
nsFrameList::AppendFrame() instead, we need to keep table captions'
parent to be nsTableFrame when they're created (no adjust in
ConstructFramesFromItem) so that their parent remain the same as other
frames in the table when appending into the temporary aFrameItems.
We then adjust captions' parent right before we call
SetInitialChildList()/AppendFrames/InsertFrames().
Also, pass nullptr to AppendFrames() in
nsTableWrapperFrame::AppendFrames() because callers should already set
captions' parent frame properly. No need to reparent them again.
Differential Revision: https://phabricator.services.mozilla.com/D25335
--HG--
extra : moz-landing-system : lando
'contain:size' just means we should size these elements as if they had no
contents -- i.e. wherever we derive the size of the scrollable frame from the
size of its contents, we should pretend that its contents had zero size.
Differential Revision: https://phabricator.services.mozilla.com/D25155
--HG--
rename : layout/reftests/w3c-css/submitted/contain/contain-size-block-001.html => layout/reftests/w3c-css/submitted/contain/contain-size-block-002.html
rename : layout/reftests/w3c-css/submitted/contain/contain-size-inline-block-001.html => layout/reftests/w3c-css/submitted/contain/contain-size-inline-block-002.html
extra : moz-landing-system : lando
This patch doesn't affect behavior. It just makes it easier for the next patch
in this series to implement contain:size for scrollframes (by conditionally
setting the new helper variable to 0,0 if we have contain:size).
Differential Revision: https://phabricator.services.mozilla.com/D25154
--HG--
extra : moz-landing-system : lando
This makes `Document::GetShell()` return `PresShell*` instead of `nsIPresShell`.
Additonally, "shell" is unclear ("docshell" vs. "presshell"). Therefore, this
also renames `Document::GetShell()` to `Document::GetPresShell()`.
Similarly, some other method names of `Document` are also renamed from
`*Shell*` to `*PresShell*`.
Differential Revision: https://phabricator.services.mozilla.com/D25338
--HG--
extra : moz-landing-system : lando
`*Inlines.h` shouldn't be included by another header file, but `nsPresContext.h`
does it. This causes include-hell which blocks the following fix.
Additionally, it causes an include hell between `PresShell.h` vs.
`nsIPresShell.h` and `nsPresContext.h if `Document.h` includes `PresShell.h`.
Therefore, this patch also solves this include hell with adding
`nsPresContextInlines.h`.
Differential Revision: https://phabricator.services.mozilla.com/D25333
--HG--
extra : moz-landing-system : lando
If `Document::GetShell()` returns `PresShell*` rather than `nsIPresShell`, it's
a good step to deCOMTaminate `PresShell`.
This patch makes `Document.h` stop including `nsIPresShell.h` since
`nsIPresShell.h` includes `Document.h` indirectly and that causes bustage
when we make `Document::GetShell()` return `PresShell*`.
Differential Revision: https://phabricator.services.mozilla.com/D25332
--HG--
extra : moz-landing-system : lando
This makes `Document::GetShell()` return `PresShell*` instead of `nsIPresShell`.
Additonally, "shell" is unclear ("docshell" vs. "presshell"). Therefore, this
also renames `Document::GetShell()` to `Document::GetPresShell()`.
Similarly, some other method names of `Document` are also renamed from
`*Shell*` to `*PresShell*`.
Differential Revision: https://phabricator.services.mozilla.com/D25338
--HG--
extra : moz-landing-system : lando
`*Inlines.h` shouldn't be included by another header file, but `nsPresContext.h`
does it. This causes include-hell which blocks the following fix.
Additionally, it causes an include hell between `PresShell.h` vs.
`nsIPresShell.h` and `nsPresContext.h if `Document.h` includes `PresShell.h`.
Therefore, this patch also solves this include hell with adding
`nsPresContextInlines.h`.
Differential Revision: https://phabricator.services.mozilla.com/D25333
--HG--
extra : moz-landing-system : lando
If `Document::GetShell()` returns `PresShell*` rather than `nsIPresShell`, it's
a good step to deCOMTaminate `PresShell`.
This patch makes `Document.h` stop including `nsIPresShell.h` since
`nsIPresShell.h` includes `Document.h` indirectly and that causes bustage
when we make `Document::GetShell()` return `PresShell*`.
Differential Revision: https://phabricator.services.mozilla.com/D25332
--HG--
extra : moz-landing-system : lando
They're only used in forms.css, and only for some anonymous content, which are
not content-accessible in the first place.
The only place where this could be exposed is calling
getComputedStyle(input, "::placeholder"), so I think this should be pretty safe,
but I've added a pref just in case.
While at it, also derive the Parse implementation. Less code is better.
Differential Revision: https://phabricator.services.mozilla.com/D25118
--HG--
extra : moz-landing-system : lando
If the maximal and minimal font-size in a SVGTextFrame have a huge difference,
previously we chose mFontSizeScaleFactor to satisfy the minimal one. That's
problematic, because the maximal one might be a reasonable size, while the minimal
one is extremely small. We should honor the maximal one if this is the case.
Differential Revision: https://phabricator.services.mozilla.com/D24494
--HG--
extra : moz-landing-system : lando
The animated GIF in background-blending-image-color-gif.html has two animation
frames, the one is a red rectangle, the other is a green rectangle. The reftest
is supposed to take the snapshot during the time where the animation frame is
the red rectangle (the first frame) and the frame duration is 1000ms. So if we
take over 1000ms there for some reasons, say on slow platforms, before taking
the snapshot, the reftet fails.
Differential Revision: https://phabricator.services.mozilla.com/D24843
--HG--
extra : moz-landing-system : lando
elementFromPoint-002.html, elementFromPoint-003.html and dialog-showModal.html
use document.elementFromPoint with a given point which is calculated from the
value returned by getBoundingClientRect() for a 100% width element. Before
this change, the given point is outside of view because there is no viewport
meta tag in the documents so that elementFromPoint fails. After this change, the
documents fit to the visual viewport so that elementFromPoint works as expected.
Differential Revision: https://phabricator.services.mozilla.com/D16155
--HG--
extra : moz-landing-system : lando
Relocated the `fuzzy-if` conditions for windows10-aarch64 in the files listed below, as the fuzzy condition was being overridden by conditions that came later.
Also tuned some of the values for pixel differences to reduce oranges.
Differential Revision: https://phabricator.services.mozilla.com/D25113
--HG--
extra : moz-landing-system : lando
This allows this enumeration to be used from nsIPresShell.h without introducing
a circular dependency.
Its new home in layout/base/ScrollTypes.h, included as mozilla/ScrollTypes.h.
Others similar enums can be added to that file if desired.
This patch also makes ScrollMode an enum class (as it's no longer nested
inside a class) and switches its enumerators to the |eName| naming convention.
Differential Revision: https://phabricator.services.mozilla.com/D24796
--HG--
extra : moz-landing-system : lando
The functional fix in this patch series makes some other scrollbar rendering
tests actually test something useful.
Some of them just start passing. Some need a bit of fuzzing. Some need an
adjustment to avoid running afoul of our minimum viewport width of 200.
Differential Revision: https://phabricator.services.mozilla.com/D23079
--HG--
extra : moz-landing-system : lando
LLVM doesn't manage to use any fast code for froundf, so use NSToIntRound
instead, which is probably what we should be using anyway for consistency.
Differential Revision: https://phabricator.services.mozilla.com/D25049
--HG--
extra : moz-landing-system : lando
The only caller of `TouchManager::PreHandleEvent()` is
`PresShell::EventHandler::HandleEventWithCurrentEventInfo()` which is guaranteed
that it never handles untrused event by bug 1536353. Therefore, we can make
`PresShell::EventHandler::PrepareToDispatchEvent()` call it instead. That's
better place from the point of view of semantics and making
`PresShell::EventHandler::PrepareToDispatchEvent()` simpler.
Note that this may cause changing the score of a telemetry probe,
"INPUT_EVENT_QUEUED_APZ_TOUCH_MOVE_MS" because it will include the time of
the runtime cost of `TouchManager::PreHandleEvent()` when the event is an
`eTouchMove` event and handled by APZ. However, this was expired in 60.
So, we don't meet any changes with this patch actually.
Differential Revision: https://phabricator.services.mozilla.com/D24133
--HG--
extra : moz-landing-system : lando
On some low end GPUs, clip mask rendering can be a significant
GPU cost. One way to reduce this is to support segment rendering
on more primitive types, to reduce the size of clip masks.
This patch adds support for pictures that have clip masks
to take part in segment rendering. This can significantly
reduce the number of fragments that must be drawn into a clip
mask for off-screen picture surfaces.
In future, WR can take advantage of segment rendering to use
clip mask shaders that handle only a single corner at a time.
This will be a further significant performance win to clip mask
render time.
Differential Revision: https://phabricator.services.mozilla.com/D24852
--HG--
extra : moz-landing-system : lando
fcp is often almost blank paint, but the next couple paints have more content.
But in order to not regress page load time, reduce frame rate later during the page load.
Differential Revision: https://phabricator.services.mozilla.com/D24636
--HG--
extra : moz-landing-system : lando
I kept it building the most straight-forward way possible (pub use) because it
seems to me that bindings is not a bad name, and we should probably move
structs.rs to be bindings.rs rather than the other way around.
But that's a different bug in any case, need to think more about it.
Differential Revision: https://phabricator.services.mozilla.com/D24713
--HG--
extra : moz-landing-system : lando
And make them actually sound. We're defining functions on Rust-land that get
structs as arguments, but declaring them in C++ as getting pointers.
This is another step in order to be able to autogenerate ServoBindings.h and
remove bindings.rs altogether.
We remove FooOwned in favor of Owned<Foo>, which is generated via cbindgen.
It'd be good to actually mark Owned and such as MOZ_MUST_USE_TYPE, so I sent
https://github.com/eqrion/cbindgen/pull/307 for that.
Differential Revision: https://phabricator.services.mozilla.com/D24681
--HG--
extra : moz-landing-system : lando
In normal cases, `PresShell::EventHandler` won't receive untrusted event.
However, only `nsIDOMWindowUtils.dispatchDOMEventViaPresShell()` may send
untrusted event if its `aTrusted` is false. Currently, this is not used by
chrome so that we don't need to keep supporting it for dispatching untrusted
events.
This patch removes `aTrusted` argument from it.
Differential Revision: https://phabricator.services.mozilla.com/D24870
--HG--
extra : moz-landing-system : lando
`PresShell::EventHandler::PrepareToDispatchEvent()` checked whether the
given event is a trusted event or an untrusted event, but
`PresShell::EventHandler::PrepareToDispatchOntextMenuEvent()` didn't so.
However, now, both of them don't need to check it. Therefore, we can merge
them.
Differential Revision: https://phabricator.services.mozilla.com/D24132
--HG--
extra : moz-landing-system : lando
`PresShell::EventHandler` shouldn't be used to dispatch untrusted event.
However, it checks whether the given event is trusted or untrusted somewhere
and that makes the code harder to understand. So, it should check each event
only with `MOZ_ASSERT()` or `MOZ_DIAGNOSTIC_ASSERT()` instead. Then,
developers can trust the event is always a trusted event.
Differential Revision: https://phabricator.services.mozilla.com/D24131
--HG--
extra : moz-landing-system : lando
If the frame supports it (stacking context + containing block for fixed), and a descendant was
modified, we would have created an override dirty region with just the area of that descendant.
In the case where no descendants are modified, we should use an empty rect, rather than
the area inherited from our parent.
This fixes the case where we forcibly build position:fixed frames (since they might async
scroll differently to the rest of the page), but we only need to build the container item,
not the whole frame subtree within it.
Added a test that shows us building the non-intersecting position:fixed, but not items within it.
Differential Revision: https://phabricator.services.mozilla.com/D23610
--HG--
extra : moz-landing-system : lando
- Re-implement flick() and send_keys() required by AccessibleCaret tests.
- Delete skip_if_not_rotatable() because it's unused.
- Change the dragging distance from 50px to 40px in
test_carets_not_jump_when_dragging_to_editable_content_boundary and
test_caret_not_jump_to_front_when_dragging_up_to_editable_content_boundary
to avoid MoveTargetOutOfBoundsException. Changing the distance doesn't
alter the meaning of the tests.
Differential Revision: https://phabricator.services.mozilla.com/D24311
--HG--
extra : moz-landing-system : lando
selection.py is used only by AccessibleCaret tests.
Differential Revision: https://phabricator.services.mozilla.com/D24447
--HG--
rename : testing/marionette/client/marionette_driver/selection.py => layout/base/tests/marionette/selection.py
extra : moz-landing-system : lando
Several tests in marionette are failing in `Mn`, `MnH`, `MG` for windows10-aarch64.
This patch disables the tests that are failing.
Individual issues are recorded in:
- 1536278
- 1536369
Differential Revision: https://phabricator.services.mozilla.com/D23991
--HG--
extra : moz-landing-system : lando
nsIChannel.LOAD_CLASSIFY_URI is no longer required so we can remove it from
the codebase.
In the mean time, we add a new LOAD_BYPASS_URL_CLASSIFIER load flag for
channel creator to be able to force channel to bypass URL classifier check.
The use of the new LOAD_BYPASS_URL_CLASSIFIER flag will be addressed in
the other patches.
Differential Revision: https://phabricator.services.mozilla.com/D22111
--HG--
extra : moz-landing-system : lando
This patch renames nsIPresShell::SetPendingVisualScrollUpdate() to
ScrollToVisual(), and adds an instant vs. smooth option.
SetPendingVisualScrollUpdate() still exists, as a helper for the instant case.
Differential Revision: https://phabricator.services.mozilla.com/D24553
--HG--
extra : moz-landing-system : lando
We avoid removing subsumed hints for out-of-flow and column-span frames
in RestyleManager::ProcessPostTraversal(). We should do something
similar here.
Differential Revision: https://phabricator.services.mozilla.com/D24578
--HG--
extra : moz-landing-system : lando
With the current code we'll eventually detect the cycle, but will take much
more, creating many shadow trees unnecessarily. Take for example the following:
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="133" height="232774">
<style>
symbol { display: block }
</style>
<symbol id="svg-sprite" viewBox="0 0 133 230866">
<title>svg-sprite</title>
<symbol id="svg-sprite" viewBox="0 0 133 230866">
<title>svg-sprite</title>
<use xlink:href="#svg-sprite" width="500" height="500" />
</symbol>
<use xlink:href="#svg-sprite" y="1601" width="133" height="228958" />
</symbol>
<use xlink:href="#svg-sprite" y="1601" width="133" height="230866" />
</svg>
Before this patch, we'd create an svg use element subtree for #svg-sprite. That
subtree will contain two other <use> elements, one under the <symbol>, one not
under it.
Both point to #svg-sprite, but we fail to detect we're an ancestor since the
element #svg-sprite we're looking at is the clone of the #svg-sprite element.
Thus we need to take a look at mOriginal instead (which is the <use> element
under #svg-sprite) rather than at the clone.
Yeah, I had to draw the trees, it's messy :)
Blink and WebKit do something slightly different (they check the element id
directly[1]). That's not 100% correct, since you can have multiple elements with
the same ID.
[1]: https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/svg/svg_use_element.cc?l=560&rcl=861855dcb8c39ba8d42497247d433277858df79b
Differential Revision: https://phabricator.services.mozilla.com/D24565
--HG--
extra : moz-landing-system : lando
This is a large patch that contains all of the core changes for
renderroot splitting.
Differential Revision: https://phabricator.services.mozilla.com/D20701
--HG--
extra : moz-landing-system : lando
We need to pull outerFrame one level up to the outer scope because it's
needed when calling FinishBuildingColumns().
The patch is very similar to implementing column-span:all for <fieldset>
in bug 1535200.
Differential Revision: https://phabricator.services.mozilla.com/D24396
--HG--
extra : moz-landing-system : lando
Rename outerSC to outerStyle because nsStyleContext was gone.
Depends on D24394
Differential Revision: https://phabricator.services.mozilla.com/D24395
--HG--
extra : moz-landing-system : lando
After supporting column-span, the top-level container for multicol
layout is no longer the ColumnSetFrame, so remove the "SET" suffix from
FCDATA_ALLOW_GRID_FLEX_COLUMNSET bit to make it sound more general.
Also, update the document and add an assertion.
Differential Revision: https://phabricator.services.mozilla.com/D24394
--HG--
extra : moz-landing-system : lando