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's never modified anywhere, and so there's no real point in having it.
The patch also removes the now-empty nsCORSListenerProxy::Startup().
Differential Revision: https://phabricator.services.mozilla.com/D40342
--HG--
extra : moz-landing-system : lando
ClassID::nsBox_id is zero, so that case is trivial. Disable the
warning in Clang, like it is in GCC. The Clang pragma can't be behind
an #elseif because Clang appears to define __GNUC__, too.
Differential Revision: https://phabricator.services.mozilla.com/D40866
--HG--
extra : moz-landing-system : lando
CORS only works on http channels, so anything else that tries to do a
CORS-enabled request fails catastrophically.
resource:// images are useful for extension developers, so don't perform CORS
checks on them. We may want to also do file:// and fix bug 1565509, while at it,
if we consider it's causing developer pain.
Differential Revision: https://phabricator.services.mozilla.com/D40651
--HG--
extra : moz-landing-system : lando
Bindgen is no longer necessary now that Rust bindings are generated by
generate_static_pref_list.py.
Differential Revision: https://phabricator.services.mozilla.com/D40793
--HG--
extra : moz-landing-system : lando
Converts mozilla.widget.disable-native-theme varcache pref to a static pref and updates uses of its associated global variable with the pref. This also renames the pref to widget.disable-native-theme to group with other widget prefs.
Differential Revision: https://phabricator.services.mozilla.com/D40721
--HG--
extra : moz-landing-system : lando
Helps support migrating from XUL DOM to an HTML DOM structure. I attempted
to remove the early return when the root element is not a XUL element, but
it appears setting the transparency on a non XUL root is still broken
(test widget/tests/test_mouse_scroll.xul started failing on windows).
Differential Revision: https://phabricator.services.mozilla.com/D40734
--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
Converts layout.framevisibility.amountscrollbeforeupdatevertical and layout.framevisibility.amountscrollbeforeupdatehorizontal to static prefs.
Differential Revision: https://phabricator.services.mozilla.com/D40718
--HG--
extra : moz-landing-system : lando
Note that this changes the writing mode used for the SetSize call from
the parent's to the child's. (This controls what position is kept
constant.) I don't think this changes behavior at all, since there is
(for this caller) a SetRect call just below.
Differential Revision: https://phabricator.services.mozilla.com/D40566
--HG--
extra : moz-landing-system : lando
At first glance, it might look like this would change behavior, since
FinishReflowChild passes aReflowInput to DidReflow, which in turn
notifies aReflowInput's mPercentBSizeObserver. However, if you examine
how the mPercentBSizeObserver is propagated, it can only be set for the
anonymous block wrapping the children of table cells, the children of
table cells, or additionally a child of a table wrapper frame that has
it set (i.e., a table or its caption, when logically a child of a table
cell). Since all of the frames for which this is being changed are
either internal table elements that are inside of the table, or are
things that can never be a descendant of a table at all, there should be
no change in behavior.
Differential Revision: https://phabricator.services.mozilla.com/D40565
--HG--
extra : moz-landing-system : lando
It seems better to convert this before adding a new flag (in bug
1547759) and risking replacing the wrong 0 with a flag.
Differential Revision: https://phabricator.services.mozilla.com/D40562
--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
There are two existing callers of IsTableCellFrame that both appear to want to
include BCTableCell frames, but don't. A patch in bug 1547759 will add a
third that wants the same.
The existing users of frame types all have to work around it being a distinct
type, and none appear to want the distinction. This removes that complexity.
If any callers want to make the distinction, they could implement QueryFrame
for BCTableCellFrame and use it. (It's not implemented now, though!)
In a little more detail, prior to this patch (in my debug build, at least):
* nsQueryFrame::ClassID::nsMathMLmtdFrame_id was 46
* nsQueryFrame::ClassID::nsTableCellFrame_id was 47
* nsQueryFrame::ClassID::nsBCTableCellFrame_id was 65
and entries 46 and 47 in sLayoutFrameTypes were
mozilla::LayoutFrameType::TableCell while entry 65 was
mozilla::LayoutFrameType::BCTableCell.
With this patch:
* nsQueryFrame::ClassID::nsBCTableCellFrame_id is 40
* nsQueryFrame::ClassID::nsMathMLmtdFrame_id is 41
* nsQueryFrame::ClassID::nsTableCellFrame_id is 42
and entries 40 through 42 in sLayoutFrameTypes are
mozilla::LayoutFrameType::TableCell.
Differential Revision: https://phabricator.services.mozilla.com/D40560
--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
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
That way we don't need to re-request a reflow. This code can run from reflow
itself, so requesting a reflow from here can break invariants.
There's the question of whether this code should be running at all for
continuations, but this patch fixes a bug regardless of whether we do that or
not.
Differential Revision: https://phabricator.services.mozilla.com/D41021
--HG--
extra : moz-landing-system : lando
Parts of nsFrame::Init or code called by it should be able to rely on the
invariant that, if the frame has the NS_FRAME_OUT_OF_FLOW bit, the first-in-flow
frame has a placeholder property.
Alternatively to this patch, the NS_FRAME_OUT_OF_FLOW frame bit could be
propagated later, as it used to be.
Differential Revision: https://phabricator.services.mozilla.com//D40815
Parts of nsFrame::Init or code called by it should be able to rely on the
invariant that, if the frame has the NS_FRAME_OUT_OF_FLOW bit, the first-in-flow
frame has a placeholder property.
Alternatively to this patch, the NS_FRAME_OUT_OF_FLOW frame bit could be
propagated later, as it used to be.
Differential Revision: https://phabricator.services.mozilla.com/D40815
--HG--
extra : moz-landing-system : lando
Bindgen is no longer necessary now that Rust bindings are generated by
generate_static_pref_list.py.
Differential Revision: https://phabricator.services.mozilla.com/D40793
--HG--
extra : moz-landing-system : lando
Support `<track-size>+` on the implicit track sizing properties,
grid-auto-columns and grid-auto-rows.
Differential Revision: https://phabricator.services.mozilla.com/D38408
--HG--
extra : moz-landing-system : lando
ClassID::nsBox_id is zero, so that case is trivial. Disable the
warning in Clang, like it is in GCC. The Clang pragma can't be behind
an #elseif because Clang appears to define __GNUC__, too.
Differential Revision: https://phabricator.services.mozilla.com/D40866
--HG--
extra : moz-landing-system : lando
Currently, TabGroups know to break their reference cycles only when the last
window leaves them. For TabGroups which have never had a window join (which
happens under Fission), this means they also never see a window leave, and
therefore never break their reference cycles, and leak.
This patch adds a check to break reference cycles if no windows have joined by
the time a BrowserChild they belong to is destroyed.
MANUAL PUSH: Lando fails to rebase.
Differential Revision: https://phabricator.services.mozilla.com/D40669
--HG--
extra : source : 03acb28ab60fb77fa06064385a62cc46cf4ad1bd
extra : amend_source : 0a71625d99951bebe45ee6f62570de491a714e97
We check surrogate pair at specific index in `nsTextFragement` in a lot of
places. This requires boundary check of the index so that it can cause
security issue and crash reason with simple mistake, and also it steals
your time to understand the code what it does especially when it's a
part of an `if` condition.
Therefore, this patch adds new API to `nsTextFragment` and makes the all
surrogate pair handlers of `nsTextFragument` use new API.
Differential Revision: https://phabricator.services.mozilla.com/D39689
--HG--
extra : moz-landing-system : lando
I'm _really_ sorry for the size of the patch. I tried to do this in two steps
but it was a lot of work and pretty ugly.
This patch makes us use cbindgen for grid-template-{rows,columns}, in order to:
* Make us preserve repeat() at computed-value time. This is per spec since
interpolation needs to know about repeat(). Except for subgrid, which did the
repeat expansion at parse-time and was a bit more annoying (plus it doesn't
really animate yet so we don't need it to comply with the spec).
* Tweaks the WPT tests for interpolation to adopt the resolution at:
https://github.com/w3c/csswg-drafts/issues/3503.
Trade-off here, as this patch stands, is that this change makes us use less
long-living memory, since we expand repeat() during layout, but at the cost of a
bit of CPU time during layout (conditional on the property applying though,
which wasn't the case before). It should be very easy to store a cached version
of the template, should this be too hot (I expect it isn't), or to change the
representation in other ways to optimize grid layout code if it's worth it.
Another trade-off: I've used SmallPointerArray to handle line-name merging,
pointing to the individual arrays in the style data, rather than actually
heap-allocating the merged lists. This would also be pretty easy to change
should we measure and see that it's not worth it.
This patch also opens the gate to potentially improving memory usage in some
other ways, by reference-counting line-name lists for example, though I don't
have data that suggests it is worth it.
In general, this patch makes much easier to tweak the internal representation of
the grid style data structures. Overall, I think it's a win, the amount of magic
going on in that mako code was a bit huge; it took a bit to wrap my head around
it.
This patch comments out the style struct size assertions. They will be
uncommented in a follow-up patch which contains some improvements for this type,
which are worth getting reviewed separately.
Also, this patch doesn't remove as much code as I would've hoped for because of
I tried not to change most of the dom/grid code for inspector, but I think a
fair bit of the nsGridContainerFrame.cpp code that collects information for it
can be simplified / de-copy-pasted to some extent. But that was a pre-existing
problem and this patch is already quite massive.
Differential Revision: https://phabricator.services.mozilla.com/D36598
This patch lets nsBlockFrame keep its NS_FRAME_FIRST_REFLOW bit a bit
longer, for the full duration of its first reflow, so that in the future
we may add more code to inspect it if needed before nsFrame::DidReflow()
clears it.
Differential Revision: https://phabricator.services.mozilla.com/D40512
--HG--
extra : moz-landing-system : lando
This annotation matches the one in
layout/reftests/css-invalid/select/reftest.list for
select-disabled-fieldset-1.html (which should really produce the same
rendering, and have the same reference).
This is a one-pixel fuzz on the fieldset border near the bottom right corner.
It's unclear which patch of this pushlog, if any, caused this:
https://hg.mozilla.org/mozilla-central/pushloghtml?changeset=4a49d88894d8d88f87760ac59ae35b2158fab7b2
Probably bug 1404868, which added reftests and tickled something. But it seems
this is not really that patches' fault, so to avoid speculatively backing it
out, with the chance of it not being the offender, let's mark it as fuzzy for
now.
I kept the exact same annotation as the other test, since this goes directly to
central, so it's less risky.
We could try to make it fuzzy-if(Android,9-9,1-1), maybe, though given it seems
to be affected to changes to adjacent reftests that may be unwise.
Various cleanup:
- remove extraneous calls to grant_runtime_permissions
- remove unused legacy jimdb support code
- remove "This may take a while" logging
- emphasize x86/x86_64 capabilities of emulator
Differential Revision: https://phabricator.services.mozilla.com/D40302
--HG--
extra : moz-landing-system : lando
We still don't optimize out the second based on the results of the first, but I
plan to do that in a bit. That's what this bug is about anyway.
Differential Revision: https://phabricator.services.mozilla.com/D40298
This depends on the line state stored in the previous patch, and will be
used in the following patch.
I'm passing this information through the reflow input here, rather than
doing an extra pass over the frame tree in the following patch, because
I believe it's substantially better for memory locality during reflow.
Differential Revision: https://phabricator.services.mozilla.com/D40275
--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
After moving the logic that carries NS_FRAME_OUT_OF_FLOW bit from the
prev-in-flow into nsFrame::Init() in Part 1,
testing/web-platform/tests/css/css-multicol/float-and-block.html starts
to crash.
In the test, it has a float element that fragments into two columns.
When creating a continuation for the float frame, we have a callstack
looks like nsFrame::Init() -> UpdateVisibleDescendantsState() ->
GetInFlowParent(). Because NS_FRAME_OUT_OF_FLOW is set in
nsFrame::Init(), GetInFlowParent() tries to get
PlaceholderFrameProperty() on its FirstContinuation(), but the first
continuation is not established until the end of
nsCSSFrameConstructor::CreateContinuingFrame().
This being said, we don't need to UpdateVisibleDescendantsState() when
creating continuations because UpdateVisibleDescendantsState() needs to
traverse a stable frame tree, and the animation code only looks at the
primary frames.
Differential Revision: https://phabricator.services.mozilla.com/D40245
--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
The fix for bug 1549625 is only necessary in cases where the layout and
visual viewports can diverge (currently mobile, and later desktop zooming),
but it has caused regressions in desktop scenarios that don't involve zooming.
While we can get a proper fix in place (tracked in bug 1543485), restricting
the existing fix to zoomable configurations mitigates the regressions.
Differential Revision: https://phabricator.services.mozilla.com/D40473
--HG--
extra : moz-landing-system : lando
The animations of motion path are not running on the compositor, and the
properties in [motion-1] is not part of transform-like properties (i.e.
nsCSSProperties::TransformLikeProperties()) for now, so we should run
transform animations on the main thread if offset-path is not `none`.
Differential Revision: https://phabricator.services.mozilla.com/D39966
--HG--
extra : moz-landing-system : lando
Also drive-by remove some useless prefixes since user-select was unprefixed in
bug 1492739.
Differential Revision: https://phabricator.services.mozilla.com/D40456
--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
The test unfortunately passes without the patch because for HTML documents we go
through DoUpdateCharSet which ends up through RebuildAllStyleData. So I think
this bug is not web-observable.
I'll file a bug to try to optimize parts of that away, since I think that we can
be doing a bit of wasteful work there for somewhat common cases...
Differential Revision: https://phabricator.services.mozilla.com/D39737
--HG--
extra : moz-landing-system : lando
Editor creates a `<br>` element when it's root element is empty.
Then, it's stored by `TextEditRules::mBogusNode` and used for checking
whether the editor is empty quickly. However, this `<br>` element has
`mozeditorbogusnode` attribute whose value is `true`. However, adding or
removing the attribute is not cheap and web apps can refer such illegal
attribute.
Therefore, this patch makes `HTMLBRElement` take a specific flag whether
it's a bogus node or not. However, this means that this hacky thing will be
exposed outside editor module. For making what is the bogus node clearer,
this patch calls the such `<br>` elements as "padding `<br>` element for
empty editor". So, this patch also includes a lot of renaming methods and
variables, and modifying related comments.
Differential Revision: https://phabricator.services.mozilla.com/D39857
--HG--
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
Converts content.sink.enable_perf_mode to a static pref. Also removes nsContentSink::InitializeStatics(), since this is the last varcache pref in the function.
Differential Revision: https://phabricator.services.mozilla.com/D40141
--HG--
extra : moz-landing-system : lando
On its own (without the previous patch), this fixes bug 1406291.
Combined with the previous patch, this patch fixes this bug (bug
1420528) when column-span is not enabled (today's configuration), and
also fixes 1411799.
Differential Revision: https://phabricator.services.mozilla.com/D39818
--HG--
extra : moz-landing-system : lando
This patch fixes bug 1420528 when column-span is enabled, and it also
fixes bug 1468654.
Differential Revision: https://phabricator.services.mozilla.com/D39582
--HG--
extra : moz-landing-system : lando
Note that I introduced a blank line to make the intent of the NOTE
clearer, which I had to research. I think it's clear it covers the
three tests below it based on
https://hg.mozilla.org/mozilla-central/rev/53489b3e14f1 and
https://bugzilla.mozilla.org/show_bug.cgi?id=967311#c0 .
I'm also running this test both with and without the column-span pref,
because those two states will be fixed by different patches.
Co-authored-by: L. David Baron <dbaron@dbaron.org>
Co-authored-by: Daniel Holbert <dholbert@cs.stanford.edu>
Differential Revision: https://phabricator.services.mozilla.com/D39581
--HG--
extra : moz-landing-system : lando
These tests were marked as `fails-if(geckoview&&!webrender)`. They are
failing on geckoview because of bug 1558513: there is an offset
between the emojis in the test and reference images.
The reason that they were passing on webrender previously was because
the emojis weren't being drawn at all, so both the test and reference
images were blank. Bug 1562316 fixed the emojis being drawn with
webrender, but bug 1558513 remains (they are still offset).
Differential Revision: https://phabricator.services.mozilla.com/D40191
--HG--
extra : moz-landing-system : lando
We expect ColumnSet and -moz-column-content to be block outside.
If ColumnSets' display style is inherit from ColumnSetWrapper, then a
multicol with "display: inline-block" is going to wrap ColumnSet in a
inline nsLineBox when ColumnSet is added to ColumnSetWrapper, which is
not what we want.
This change fixed [.multicol 4] and [.multicol 6] in
multicol-gap-percentage-001.html with column-span disable, but it can
also fix [.multicol 5] in multicol-gap-percentage-001.html when
column-span is enabled (bug 1489298), so I go ahead and enable the pref
in that test.
Differential Revision: https://phabricator.services.mozilla.com/D39997
--HG--
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
This might seem like we are including the parent scale twice because it is also included in mInheritedTransform but FrameLayerBuilder::ChooseScale only incorporates the passed in scale when combining it with a scale computed purely based on the local transform induced by this stacking context item.
This also fixes bug 1564698 and doesn't regress bug 1495163 (the only testcase I can still find for the regressing bug, bug 1415987).
Differential Revision: https://phabricator.services.mozilla.com/D39867
--HG--
extra : moz-landing-system : lando
This was an oversight in bug 1520154. We kept the -moz- version in the specified
value but not the computed value.
That's a very peculiar way of making aliases work. This makes them work
consistently as many other aliases instead.
Also, add an assert that would've caught this much much earlier.
Differential Revision: https://phabricator.services.mozilla.com/D40063
--HG--
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
In the beginning of nsOverflowContinuationTracker::Insert() there is an
assertion MOZ_ASSERT(aOverflowCont->GetPrevInFlow()). Assume this is
correct, we should use next-in-flows instead of next-continuations when
converting overflow containers.
The crashtest is not added because the assertion can also be triggered
in the reftests added in Part 3 without this patch.
Differential Revision: https://phabricator.services.mozilla.com/D15392
--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
If we re-use the old item we hit the warning because we try to set the very same item as the glass item, but that is fine.
Differential Revision: https://phabricator.services.mozilla.com/D39308
--HG--
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
Not sure if we need this, but the window dragging regions have it, so in case we need to turn off retained display lists we have this and there will be no difference to before the patches in this bug.
Depends on D38589
Differential Revision: https://phabricator.services.mozilla.com/D38590
--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
For retained display lists it needs to be a weak frame region to areas get removed for modified frames and the rest stick around.
Each display item can contribute an opaque region but WeakFrameRegion can only track one rect per frame. It turns out that we only return rects from GetOpaqueRegion except in one hit testing case.
This still means more than one display item per frame could be contributing to the opaque region, we would miss the second and further rects in that case.
Differential Revision: https://phabricator.services.mozilla.com/D38589
--HG--
extra : moz-landing-system : lando
Now that the functionality we we wanted to preserve has been moved out of
XULDocument, we can start loading XUL files as XHTML. This will allow
the removal of XULDocument once we are confident that everything is working
correctly as XHTML.
Differential Revision: https://phabricator.services.mozilla.com/D38694
--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
Bug 1561547 introduces an SVG resource document in the UI in a way that the pref
changed callback ends up being called for that document _before_ being called for
the main document.
Given mDeviceContext is shared, it's a bug to depend on the return value of the
CheckDPIChange call, since then we only properly update the first document that
gets notified.
Differential Revision: https://phabricator.services.mozilla.com/D38974
--HG--
extra : moz-landing-system : lando
The reftest-paged tests don't trigger the document clone code-path (I realized
that after writing them), but I guess they don't hurt, the printpreview test
does fail without the previous patch.
Depends on D39053
Differential Revision: https://phabricator.services.mozilla.com/D39054
--HG--
extra : moz-landing-system : lando
This should ensure that the inner window for each document is set up correctly
before iframe elements are created in them during a static clone. Other,
non-static-clone cases are not affected because they cannot load subframes.
Differential Revision: https://phabricator.services.mozilla.com/D38931
--HG--
extra : moz-landing-system : lando
After bug 1555060, <tabs> elements should not use dom accessors to get
to the <tab> elements inside a <tabs>. This test was using lastChild,
this patch brings it up to date.
Differential Revision: https://phabricator.services.mozilla.com/D38526
--HG--
extra : moz-landing-system : lando
TraverseFrames gathers a bunch of frames into an array, and then at
forced breaks or the end of the block flushes its array by running
ResolveParagraph. ResolveParagraph can sometimes cause lines to break,
so lines recorded during TraverseFrames may no longer be accurate during
ResolveParagraph.
It may look like the lines are only needed during ResolveParagraph and
we could handle the one issue in TraverseFrames that deals with
preformatted newlines by restructuring the code a tad. However, in the
next patch, there will be an additional caller that needs the current
line during TraverseFrames to pass to CreateContinuation, which makes
such a structure less plausible.
This will also make it easier to produce a current line for the call to
SplitInlineAncestors within ResolveParagraph, which will be done in the
patch after the next.
Differential Revision: https://phabricator.services.mozilla.com/D38797
--HG--
extra : moz-landing-system : lando
This information is used in the next patch, which will use that information to
maintain a line iterator while iterating over mLogicalFrames (and will remove
the stored mLinePerFrame).
Differential Revision: https://phabricator.services.mozilla.com/D38796
--HG--
extra : moz-landing-system : lando
Rules and their declarations are a single object as far as the CC is concerned. They have a single nsCycleCollectionISupports and they are represented by a single node in the CC graph. That single object has two nsWrapperCache instances in it that point to different JS objects, and we need to make sure that the ordering of the unlink operations for those nsWrapperCache instances is handled correctly.
Differential Revision: https://phabricator.services.mozilla.com/D38326
--HG--
extra : moz-landing-system : lando
When we unlink, we may null out the mFontFaceSet pointer, but still keep
mInFontFaceset as true. Which can cause null dereference bugs as described in
comment 0.
This is mostly a speculative fix since I think that's a plausible cause for a
bug like that, but it may not be the only cause for the crash.
Differential Revision: https://phabricator.services.mozilla.com/D38822
--HG--
extra : moz-landing-system : lando
* Tweak headers to add title and WPT meta tags.
* Simplify text content and use the Ahem font to avoid "random" result.
* Remove dir-11 since it has already been exported to
mathml/relations/css-styling/dynamic-dir-1.html by @bkardell
* Move dir-10 to mathml/presentation-markup/direction/direction-010.html
* Move dir-9 to mathml/presentation-markup/direction/direction-009.html
and add a .ini file for the corresponding failure expectation (bug 787215).
* Move dir-8 to mathml/presentation-markup/direction/direction-008.html
and add a .ini file for the corresponding failure expectation.
* Move dir-7 to mathml/presentation-markup/direction/direction-007.html
* Move dir-6 to mathml/presentation-markup/direction/direction-006.html
Differential Revision: https://phabricator.services.mozilla.com/D41922
--HG--
rename : layout/reftests/mathml/dir-6-ref.html => testing/web-platform/tests/mathml/presentation-markup/direction/direction-006-ref.html
extra : moz-landing-system : lando
Many of these features are non-functional these days, but I'll keep them
hooked up in case we decide to fix them.
Differential Revision: https://phabricator.services.mozilla.com/D38413
--HG--
extra : moz-landing-system : lando
They're wrong. When a property that affects the parent frame changes, we get a
hint for both frames. This fixes this bug.
Depends on D38598
Differential Revision: https://phabricator.services.mozilla.com/D38599
--HG--
extra : moz-landing-system : lando
This is IMO the right RestyleManager change for what bug 1527210 tried to fix.
We need to apply the animation hints to the primary frame, not the style frame.
The other non-RestyleManager bits of that bug still apply and look fine to me.
Differential Revision: https://phabricator.services.mozilla.com/D38598
--HG--
extra : moz-landing-system : lando
Seems we can leave this node alive for too long if the user scrolls between
domcontentloaded (where GoToAnchor is called) and onload (where ScrollToAnchor()
is called).
Though it seems we can leave it for too long if we don't end up calling
ScrollToAnchor(), the documentation of the method claims that it's cleared
unconditionally.
Differential Revision: https://phabricator.services.mozilla.com/D38398
--HG--
extra : moz-landing-system : lando
This is a potential fix that I thought it was worth doing rather than
implementing Blink's platform-dependent silliness. This ensures that the display
frame always has enough space to display itself.
Note that it may still get clipped, if there's no room for both the display
frame and the button.
Differential Revision: https://phabricator.services.mozilla.com/D37922
--HG--
extra : moz-landing-system : lando
Unmasking is an optional style of showing password. Therefore, if callers of
`nsIEditor::Unmask()` specify middle of surrogate pair(s), it may mean that
they want to expand the unmask range from shorter range which does not include
the high and/or low surrogate. Therefore, one of the surrogates is in unmasked
range, we unmask the surrogate pair. However, we handle this in a lot of
places, i..e., we have duplicated code. This can get rid of these duplicates
with making `nsIEditor::Unmask()` expand the range automatically.
Differential Revision: https://phabricator.services.mozilla.com/D38432
--HG--
extra : moz-landing-system : lando
In some cases, other tools may show selected content in their UI. E.g.,
character palette of macOS. Therefore, we shouldn't allow them to show
masked password.
Differential Revision: https://phabricator.services.mozilla.com/D38430
--HG--
extra : moz-landing-system : lando
Double click, long tap, moving selection with keyboard and deleting text
scan word boundary. With these changes, the text node has raw password
value even if it's masked visually. For making safer,
`nsTextFrame::PeekOffsetWord()` should search word boundary in masked text.
Then, we can hide word boundary at masked range, but keep allowing to look
for word boundary only in unmasked range.
Differential Revision: https://phabricator.services.mozilla.com/D38013
--HG--
extra : moz-landing-system : lando
Anonymous text node in password field has `NS_MAYBE_MASKED` flag and
`TextEditor` managing the node has range of unmasking. This patch makes
`BuildTextRunsScanner::BuildTextRunForFrames()` treat text frame in
password field as `text-transform` applied. For recording the unmask range,
this patch creates `nsTransformedCharStyle::mMaskPassword` and treats unmask
range start/end edges as different style boundary. Therefore,
`nsCaseTransformTextRunFactory::TransformString()` can replace each character
with a password mask character with the information.
Note that we need to kill bidi algorithm in password fields with forms.css
because caret position will tell everybody whether the typing character is
an RTL or an LTR character.
Differential Revision: https://phabricator.services.mozilla.com/D38009
--HG--
extra : moz-landing-system : lando
With the previous patches, editor has stopped masking characters in password
field. Instead, layout code needs to handle it. However, layout code
especially around `nsTextFrame` is performance critical area. Therefore,
layout code requires a quick way to check whether a text node in password
field or not.
This patch creates new flag for `CharacterData` node and marks all text nodes
whose characters should be masked with the flag when `EditorBase` or
`nsTextControlFrame` creates them.
Differential Revision: https://phabricator.services.mozilla.com/D38006
--HG--
extra : moz-landing-system : lando
Now, `TextEditRules` should use the new editor API to mask/unmask characters
if it's for a password editor. With this change, it does not need to manage
masked characters and unmasked characters separately since the anonymous
text node always have unmasked characters and `nsTextFrame` will mask the
characters at painting time.
Differential Revision: https://phabricator.services.mozilla.com/D38005
--HG--
extra : moz-landing-system : lando
Currently it's completely unclear at use sites that the getters for `once`
static prefs return the pref value from startup, rather than the current pref
value. (Bugs have been caused by this.) This commit improves things by changing
the getter name to make it clear that the pref value obtained is from startup.
This required changing things within libpref so it distinguishes between the
"base id" (`foo_bar`) and the "full id" (`foo_bar` or
`foo_bar_DoNotUseDirectly` or `foo_bar_AtStartup` or
`foo_bar_AtStartup_DoNotUseDirectly`; the name used depends on the `mirror` and
`do_not_use_directly` values in the YAML definition.) The "full id" is used in
most places, while the "base id" is used for the `GetPrefName_*` and
`GetPrefDefault_*` functions.
(This is a nice demonstration of the benefits of the YAML file, BTW. Making
this change with the old code would have involved adding an entry to every
single pref in StaticPrefList.h.)
The patch also rejigs the comment at the top of StaticPrefList.yaml, to clarify
some things.
Differential Revision: https://phabricator.services.mozilla.com/D38604
--HG--
extra : moz-landing-system : lando
Delete `return false` at the end of the if-statement block that handling
the multicol subtree reframing, and let it fall though the bottom of
WipeContainingBlock() where there is a complete logic for ib-split
reframing.
Differential Revision: https://phabricator.services.mozilla.com/D38548
--HG--
extra : moz-landing-system : lando
CSSStyleSheet.prototype.deleteRule can throw an IndexSizeError. This change
makes it so that the exception thrown has the max valid index for that function.
Differential Revision: https://phabricator.services.mozilla.com/D38519
--HG--
extra : moz-landing-system : lando
This patch adds an assertion that documents the invariant that this code
needs to maintain to manage the line iterator correctly. Failing to
meet that invariant would also cause additional assertions in my
work-in-progress on bug 1300293.
It then adds two assignments of mPrevFrame to null that make that
assertion hold.
The first assignment to null is tested by a number of tests already in
our test suite, including
layout/reftests/w3c-css/received/css-writing-modes/block-plaintext-004.html
and layout/reftests/bidi/unicode-bidi-plaintext.html , which would hit
the added assertion if that assignment to null were not present.
The second assignment to null was untested in our test suite (though it
showed up when doing view-source: of https://html.spec.whatwg.org/ ), so
I've added a reftest (1567036-1.html) that hits the added assertion if
that second assignment to null is not present.
Differential Revision: https://phabricator.services.mozilla.com/D38438
--HG--
extra : moz-landing-system : lando
Brendan Dahl
Emilio Cobos Álvarez
Ting-Yu Lin
Nicholas Nethercote
Andrew McCreight
Razvan Maries
Charlie Marlow
Kristen Wright
Kannan Vijayan
L. David Baron
Brian Grinstead
Nika Layzell
Kris Maglione
Jared Wein
Bogdan Tara
Tom Schuster
Edgar Chen
Cosmin Sabou
Bob Owen
Ciure Andrei
Cameron McCormack
Boris Chiou
Andreea Pavel
Masayuki Nakano
Gurzau Raul
Brindusan Cristian
Daniel Varga
Botond Ballo
Geoff Brown
Eitan Isaacson
Edwin Gao
Olli Pettay
Jamie Nicol
Daniel Holbert
Timothy Nikkel
Hiroyuki Ikezoe
Ting-Yu Lin
Alex Catarineu
Jonathan Kew
Lee Salzman
Miko Mynttinen
Thomas Nguyen
François Freitag
Dan Glastonbury
Coroiu Cristina
Narcis Beleuzu
Andrew Swan
Boris Zbarsky
harry
Mihai Alexandru Michis
Mats Palmgren
longsonr
Frédéric Wang
Connor Brewster
Nicolas Silva
Blito
Andrea Marchesini
RuchikaGosain