This simplifies dealing with frames that are pushed/pulled between
continuations during reflow, allows us to avoid the complexity of the
fix to 1459937, and hopefully fixes some of the regressions from bug
1308876.
This disables the changes from bug 1459937 by commenting out a single
line in ReparentFrameInternal in nsBlockFrame.cpp, but all the added
code will be removed in the following patch.
Co-authored-by: Gerald Squelart <gsquelart@mozilla.com>
Co-authored-by: L. David Baron <dbaron@dbaron.org>
Depends on D36423
Differential Revision: https://phabricator.services.mozilla.com/D36424
--HG--
extra : moz-landing-system : lando
Actually, long tap can set focus. But since it uses `nsIFocusManager::FLAG_BYMOUSE` flag, we cannot recognize whether setting focus is by long tap or not.
So I would like to add new flag `FLAG_BYLONGPRESS` and `CAUSE_LONGPRESS` that are by long tap.
Differential Revision: https://phabricator.services.mozilla.com/D35991
--HG--
extra : moz-landing-system : lando
The bounds attribute has been deprecated and shown zero use, and thus this change removes it.
Differential Revision: https://phabricator.services.mozilla.com/D36005
--HG--
extra : moz-landing-system : lando
And move the useful bits of it somewhere else (ServoStyleConstInlines.h for the
inline function definitions, and nsFrame.cpp for the static assertions).
Differential Revision: https://phabricator.services.mozilla.com/D36120
And move the useful bits of it somewhere else (ServoStyleConstInlines.h for the
inline function definitions, and nsFrame.cpp for the static assertions).
Differential Revision: https://phabricator.services.mozilla.com/D36120
--HG--
extra : moz-landing-system : lando
Some `nsRange` static methods are useful in `StaticRange` and some of them
are used in a lot of places but not related to `nsRange` directly. This
patch moves them into new static method only class, `mozilla::RangeUtils`.
Differential Revision: https://phabricator.services.mozilla.com/D35142
--HG--
extra : moz-landing-system : lando
For avoiding confusion between API of `nsRange` and `StaticRange`, I'd like to
rename `nsRange::CreateRange()` to `nsRange::Create()` because
`StaticRange::CreateStaticRange()` is too long name and
`StaticRange::CreateRange()` sounds odd. This patch renames it and changes
related methods to template methods to avoid runtime cost of temporary
`RawRangeBoundary` instance creation.
Differential Revision: https://phabricator.services.mozilla.com/D35141
--HG--
extra : moz-landing-system : lando
Two benefits:
1) Align test setup with shipping Firefox - We don't allow content
privilege XUL in shipping versions of Firefox, so having the tests be
chrome would be more realistic to our use case.
2) Support the XUL to XHTML migration. These files will soon become XHTML
files, but will still need to load XUL elements, so they'll need to be
marked as chrome privileged to continue working.
Differential Revision: https://phabricator.services.mozilla.com/D35870
--HG--
rename : dom/xul/test/test_bug486990.xul => dom/xul/test/test_bug486990.xhtml
rename : layout/base/tests/file_bug465448.html => layout/base/tests/chrome/file_bug465448.html
rename : layout/base/tests/test_bug465448.xul => layout/base/tests/chrome/test_bug465448.xul
extra : moz-landing-system : lando
The patch also removes the dom.vr.oculus.quit.timeout pref, because it's
unused.
Differential Revision: https://phabricator.services.mozilla.com/D35973
--HG--
extra : rebase_source : bd16ed5ff0b7c2b4f8e653e9835610b25b14a39f
Two benefits:
1) Align test setup with shipping Firefox - We don't allow content
privilege XUL in shipping versions of Firefox, so having the tests be
chrome would be more realistic to our use case.
2) Support the XUL to XHTML migration. These files will soon become XHTML
files, but will still need to load XUL elements, so they'll need to be
marked as chrome privileged to continue working.
Differential Revision: https://phabricator.services.mozilla.com/D34782
--HG--
rename : layout/base/tests/test_bug465448.xul => layout/base/tests/chrome/test_bug465448.xul
extra : moz-landing-system : lando
From the CSSOM View spec[1];
The scroll-behavior property of the HTML body element is not propagated to
the viewport.
The reason why this change fixes the test case in this commit is that we don't
have two different scrollable frames for <html> and <body> respectively if we
don't propagate scroll-behavior property from <body> to <html> so that we can
properly find the `flow root` of sticky position elements.
In other words, in the case where both of <html> and <body> have properties
that are propagated from <body> but they are different we have two scrollable
frames as a candidate of the 'flow root' for the sticky position element in
the test case, one is the scrollable frame for <html> and the other is the
scrollable frame for <body>. That means that
nsLayoutUtils::GetNearestScrollableFrame doesn't return what we want in some
places, for example we have a pretty similar issue in case of
overscroll-behavior which is bug 1561107.
Note that the test position-sticky-root-scroller-with-scroll-behavior.html is
almost copy-and-pasted from
/css/css-position/position-sticky-root-scroller.html [2] in wpt, the reason why
we put the test in /css/cssom-view is that there is a handy function to wait
for async scroll completion.
[1] https://drafts.csswg.org/cssom-view/#propdef-scroll-behavior
[2] https://searchfox.org/mozilla-central/rev/928742d3ea30e0eb4a8622d260041564d81a8468/testing/web-platform/tests/css/css-position/position-sticky-root-scroller.html
Differential Revision: https://phabricator.services.mozilla.com/D35739
--HG--
extra : moz-landing-system : lando
This is pretty much the same as ScrollStyles::IsSmoothScroll right now,
but in the next commit, we will no longer propagate scroll-behavior on <body> to
the root element so that nsIScrollableFrame::IsSmoothScroll will be changed
to reflect it.
Differential Revision: https://phabricator.services.mozilla.com/D35737
--HG--
extra : moz-landing-system : lando
In this codepath, the parent process may be sending an event to a particular
content process. The last-saved mouse target might be stale, and using that
to redirect the event can result in the event getting sent to the wront content
process. Deleting this erroneous change restores correct behaviour.
Differential Revision: https://phabricator.services.mozilla.com/D35697
--HG--
extra : moz-landing-system : lando
App units of a remote browser element in the parent process are
different from app units inside the remote content in the child
process. We should apply the appropriate conversions by exposing
the relevant data as LayoutDevicePixel.
Differential Revision: https://phabricator.services.mozilla.com/D35334
--HG--
extra : moz-landing-system : lando
Bug 1507244 changes how NS_FRAME_HAS_MULTI_COLUMN_ANCESTOR is propagated
to the child, but I forget to add the bit for nested ColumnSetWrapper.
Currently, no other code depends on this bit being set on nested
ColumnSetWrapper, but Part 3 will. Without this patch,
testing/web-platform/tests/css/css-multicol/multicol-nested-margin-002.xht
will fail with Part 3.
Differential Revision: https://phabricator.services.mozilla.com/D31675
--HG--
extra : moz-landing-system : lando
This is a rework for the issue in bug 1516963.
The condition `aFrame->IsFrameOfType(nsIFrame::eReplaced)` was added to
avoid breaking
editor/libeditor/tests/test_abs_positioner_positioning_elements.html
because it contains blockified (position:absolute) images in
contenteditable, and we don't want these images to use frame edge. But
for non-editable undraggable images, which have display:inline, we want
them to use frame edge to avoid being selected by a single-clicking.
Note that non-editable draggable images use a different code patch to
handle their operations.
I think it easier to understand by checking the frame types directly. As
for images, we want non-editable images to use frame edge, but not those
editable ones because editor has its own logic to handle all the
dragging operations, etc. Using frame edge for editable images makes
them undraggable, and fails
test_abs_positioner_positioning_elements.html.
Add more tests for empty inline-grid, inline-flex, inline-table, video,
to ensure the behavior is not changed. We don't want them to be selected
by a single-clicking, either.
Note I only test video's selection is collapsed when single-clicking
because I failed to turn off picture-in-picture on <video> in
test_reftests_with_caret.html.
Differential Revision: https://phabricator.services.mozilla.com/D34909
--HG--
extra : moz-landing-system : lando
That includes changing privacy.resistFingerprinting to a non-VarCache pref,
because it doesn't need to be a VarCache.
Differential Revision: https://phabricator.services.mozilla.com/D36162
--HG--
extra : rebase_source : 6d742e6ff2a4b786cb21f6e8874d1fd4bbde1857
The patch also removes the layers.mlgpu.enable-container-resizing pref, because
it's dead.
Differential Revision: https://phabricator.services.mozilla.com/D36159
--HG--
extra : rebase_source : e215d584aed18f865d2e8d00a78e76e9b0323e6e
This is consistent with the scroll area events too, and allows us to
remove the WillPaintObserver stuff.
Differential Revision: https://phabricator.services.mozilla.com/D5271
--HG--
extra : moz-landing-system : lando
The test is supposed to test that changing the preference layers.acceleration.disabled doesn't cause a crash, but this pref is only read on startup well before the test has a chance to run and switch the pref.
It's not doing anything.
Differential Revision: https://phabricator.services.mozilla.com/D34781
--HG--
extra : moz-landing-system : lando
Even if we don't have a root displayport, the composition size is still used for
displayport margins calculations. For extremely tall iframes, this will create
a displayport that is way to big. We should instead report a composition size that
is equivalent to the visible rect for OOP-iframes.
Differential Revision: https://phabricator.services.mozilla.com/D34528
--HG--
extra : rebase_source : 1f43cb16a0841eb3cd892401c83a46d56276cf2e
visibleRect should affect both WR/layers, and scaling will only affect
layers.
Differential Revision: https://phabricator.services.mozilla.com/D34525
--HG--
extra : rebase_source : 49273db3e10088c9493f693d5f8b58864dcb01aa
This patch adds the ability to load cross domain iframes in the
background to make the top level documents finish earlier.
This is an experiment feature that we'll keep it disabled by default.
Differential Revision: https://phabricator.services.mozilla.com/D24938
--HG--
extra : moz-landing-system : lando
I think that, given ::part() right now (without forwarding) cannot affect
descendants (and eager pseudo-elements are handled as part of the normal element
restyling process), it is not worth the effort to add more complex invalidation.
But we can always re-evaluate.
Depends on D32642
Differential Revision: https://phabricator.services.mozilla.com/D32643
--HG--
extra : moz-landing-system : lando
The idea is to check IsBidiSplittable() in more places to prevent fixed
continuations created by column-span from becoming fluid ones.
Differential Revision: https://phabricator.services.mozilla.com/D34093
--HG--
extra : moz-landing-system : lando
This reverts the modification to nsBidiPresUtils.cpp in Bug 1520722 Part
2, but keeps the test added. Next part will fix the problem in a proper
way.
Differential Revision: https://phabricator.services.mozilla.com/D34092
--HG--
extra : moz-landing-system : lando
UnsuppressAndInvalidate updates focus state among others, so it needs to be called even if paint suppression itself
isn't used. An example of a such case is when PresShell is created after Document's readyState is already Document::READYSTATE_COMPLETE.
Differential Revision: https://phabricator.services.mozilla.com/D34426
--HG--
extra : moz-landing-system : lando
This code predates our use of a static clone to print. Nowadays we never
navigate in the (dedicated) print preview tab.
Differential Revision: https://phabricator.services.mozilla.com/D34433
--HG--
extra : rebase_source : f4b8c03e0dde5b96e2e848892623e6f88a365095
Now they both work in opt builds, and they both work with advanced layers.
For consistency, layers.dump-client-layers is also modified to work in
opt builds.
Differential Revision: https://phabricator.services.mozilla.com/D34413
--HG--
extra : moz-landing-system : lando
For now I added everything to the same bucket, but I wrote this so it should be
easy to add more buckets as needed (either to mArenaSizes, or more specific ones
like the style system has). But this is probably enough for now.
Differential Revision: https://phabricator.services.mozilla.com/D34126
--HG--
extra : moz-landing-system : lando
"Cancelled" sounds like it's a query and should return a bool. In fact this
method sets state in response to a nsIWebBrowserPrint.cancel() being called.
Differential Revision: https://phabricator.services.mozilla.com/D34137
--HG--
extra : rebase_source : 97797d906b84ed18a258881a31722179d50943f7
extra : amend_source : c0e1b61f13b2a8ccaec7cc995841948deabbe041
The crash reports just tell us that the crash occur due to referring around
address 0 in `PresShell::EventHandler::MaybeFlushThrottledStyles()`.
Therefore, I'm not sure which is the actual reason of the crashes though,
this patch makes it null-check root `PresShell` and its `Document` before
accessing the latter.
Differential Revision: https://phabricator.services.mozilla.com/D33735
--HG--
extra : moz-landing-system : lando
Make nsIWebBrowserPrint included unconditionally for addressing nsIDocShell.rs build failure.
Remove direct_call of PPrinting and PRemotePrintJob. Their ipdl are built unconditionally, but their derived classes are not built with --disable-printing.
Differential Revision: https://phabricator.services.mozilla.com/D33391
--HG--
extra : moz-landing-system : lando
In preparation for an <html> root node in browser.xhtml, we need to react to lwtheme changes correctly.
Differential Revision: https://phabricator.services.mozilla.com/D33693
--HG--
extra : source : afa5d3807c8b5810203718e158fa4b185e109f55
In preparation for an <html> root node in browser.xhtml, we need to react to lwtheme changes correctly.
Differential Revision: https://phabricator.services.mozilla.com/D33693
--HG--
extra : moz-landing-system : lando
This is a drive-by fix to turn a division into a multiplication. It also
is more correct in that the existing code attempts a divide-by-zero if
aNewViewport.width is zero. The updated code will instead return a zoom
of zero in such a case.
Differential Revision: https://phabricator.services.mozilla.com/D32909
--HG--
extra : moz-landing-system : lando
The existing math is attempting to adjust the display scale ratio to
prevent the new size from landing outside the min/max zoom bounds. This
introduces unwanted side effects that can be avoided by simply clamping
to min/max at the end. The remaining math correctly handles the case
where the zoom has ALREADY been clamped, which is the only important
case.
Differential Revision: https://phabricator.services.mozilla.com/D32908
--HG--
extra : moz-landing-system : lando
This is a drive-by fix to turn a division into a multiplication. It also
is more correct in that the existing code attempts a divide-by-zero if
aNewViewport.width is zero. The updated code will instead return a zoom
of zero in such a case.
Differential Revision: https://phabricator.services.mozilla.com/D32909
--HG--
extra : moz-landing-system : lando
The existing math is attempting to adjust the display scale ratio to
prevent the new size from landing outside the min/max zoom bounds. This
introduces unwanted side effects that can be avoided by simply clamping
to min/max at the end. The remaining math correctly handles the case
where the zoom has ALREADY been clamped, which is the only important
case.
Differential Revision: https://phabricator.services.mozilla.com/D32908
--HG--
extra : moz-landing-system : lando
BindContext was going to have way more information at first, but then I realized
that most of the things I wanted to know were basically a flag away using the
parent node.
Still I think it's worth it, now experimenting with BindToTree will only mean
adding a field to a struct that's included from a couple cpp files, instead of a
massive pain.
I also think this is clearer, and doing this highlights quite a few
inconsistencies in our code which I've left untouched, but commented with
FIXMEs.
Steps are:
$ for file in $(rg 'nsresult BindToTree\(' | cut -d : -f 1 | sort | uniq); do sed -i 's#nsresult BindToTree(Document\* aDocument, nsIContent\* aParent,#nsresult BindToTree(BindContext\&, nsINode\& aParent)#g' $file; done
$ for file in $(rg 'nsresult BindToTree\(' | cut -d : -f 1 | sort | uniq); do sed -i 's# nsIContent\* aBindingParent) override#override#g' $file; done
$ for file in $(rg '::BindToTree\(' | cut -d : -f 1 | sort | uniq); do sed -i 's#::BindToTree(Document\* aDocument, nsIContent\* aParent,#::BindToTree(BindContext\& aContext, nsINode\& aParent)#g' $file; done
$ for file in $(rg '::BindToTree\(' | cut -d : -f 1 | sort | uniq); do sed -i 's#nsIContent\* aBindingParent)##g' $file; done
$ for file in $(rg '::BindToTree\(' | cut -d : -f 1 | sort | uniq); do sed -i 's#::BindToTree(aDocument, aParent, aBindingParent)#::BindToTree(aContext, aParent)#g' $file; done
$ ./mach clang-format
Then manual fixups.
Depends on D32948
Differential Revision: https://phabricator.services.mozilla.com/D32949
WebRender support will be finished in the following commit.
Differential Revision: https://phabricator.services.mozilla.com/D32476
--HG--
extra : rebase_source : f40ab9946e946d137aa2522f9fce0aa268e22937
extra : intermediate-source : ea63d3d6b85fd3c4456275638e968e0eed045b37
extra : source : 79be6c27e0f9e262b75723c120786e2256ee4700
This is a drive-by fix to turn a division into a multiplication. It also
is more correct in that the existing code attempts a divide-by-zero if
aNewViewport.width is zero. The updated code will instead return a zoom
of zero in such a case.
Differential Revision: https://phabricator.services.mozilla.com/D32909
--HG--
extra : rebase_source : 83ab76092596d7feda11f66d83c022d3d1e4acd3
extra : source : 2a85e3af81bbe475217ecdf16ce7c5a1a7985a21
The existing math is attempting to adjust the display scale ratio to
prevent the new size from landing outside the min/max zoom bounds. This
introduces unwanted side effects that can be avoided by simply clamping
to min/max at the end. The remaining math correctly handles the case
where the zoom has ALREADY been clamped, which is the only important
case.
Differential Revision: https://phabricator.services.mozilla.com/D32908
--HG--
extra : rebase_source : 3767a50a7d88ceced7b0b3d5979020296f91d7a2
extra : source : 262d2cad64079c343e35b757ac642b231d50e0df
This doesn't clean up as much as a whole, but it's a step in the right
direction. In particular, it allows us to start using simple bindings for:
* Filters
* Shapes and images, almost. Need to:
* Get rid of the complex -moz- gradient parsing (let
layout.css.simple-moz-gradient.enabled get to release).
* Counters, almost. Need to:
* Share the Attr representation with Gecko, by not using Option<>.
* Just another variant should be enough (ContentItem::{Attr,Prefixedattr},
maybe).
Which in turn allows us to remove a whole lot of bindings in followups to this.
The setup changes a bit. This also removes the double pointer I complained about
while reviewing the shared UA sheet patches. The old setup is:
```
SpecifiedUrl
* CssUrl
* Arc<CssUrlData>
* String
* UrlExtraData
* UrlValueSource
* Arc<CssUrlData>
* load id
* resolved uri
* CORS mode.
* ...
```
The new one removes the double reference to the url data via URLValue, and looks
like:
```
SpecifiedUrl
* CssUrl
* Arc<CssUrlData>
* String
* UrlExtraData
* CorsMode
* LoadData
* load id
* resolved URI
```
The LoadData is the only mutable bit that C++ can change, and is not used from
Rust. Ideally, in the future, we could just use rust-url to resolve the URL
after parsing or something, and make it all immutable. Maybe.
I've verified that this approach still works with the UA sheet patches (via the
LoadDataSource::Lazy).
The reordering of mWillChange is to avoid nsStyleDisplay from going over the
size limit. We want to split it up anyway in bug 1552587, but mBinding gains a
tag member, which means that we were having a bit of extra padding.
One thing I want to explore is to see if we can abuse rustc's non-zero
optimizations to predict the layout from C++, but that's something to explore at
some other point in time and with a lot of care and help from Michael (who sits
next to me and works on rustc ;)).
Differential Revision: https://phabricator.services.mozilla.com/D31742
PresShell::EventHandler::HandleEventWithCurrentEventInfo is the only possible
place will do such handling; other places pass either a nullptr or a
non-MouseDown/Up event.
Differential Revision: https://phabricator.services.mozilla.com/D32431
--HG--
extra : moz-landing-system : lando
With desktop zooming, we need to separate the concepts of "may have a distinct
visual viewport" from "has mobile viewport sizing logic applied to it".
This can be thought of as completing the disentanglement of zooming from meta
viewport support started in bug 1459260.
Differential Revision: https://phabricator.services.mozilla.com/D32770
--HG--
extra : moz-landing-system : lando
This doesn't clean up as much as a whole, but it's a step in the right
direction. In particular, it allows us to start using simple bindings for:
* Filters
* Shapes and images, almost. Need to:
* Get rid of the complex -moz- gradient parsing (let
layout.css.simple-moz-gradient.enabled get to release).
* Counters, almost. Need to:
* Share the Attr representation with Gecko, by not using Option<>.
* Just another variant should be enough (ContentItem::{Attr,Prefixedattr},
maybe).
Which in turn allows us to remove a whole lot of bindings in followups to this.
The setup changes a bit. This also removes the double pointer I complained about
while reviewing the shared UA sheet patches. The old setup is:
```
SpecifiedUrl
* CssUrl
* Arc<CssUrlData>
* String
* UrlExtraData
* UrlValueSource
* Arc<CssUrlData>
* load id
* resolved uri
* CORS mode.
* ...
```
The new one removes the double reference to the url data via URLValue, and looks
like:
```
SpecifiedUrl
* CssUrl
* Arc<CssUrlData>
* String
* UrlExtraData
* CorsMode
* LoadData
* load id
* resolved URI
```
The LoadData is the only mutable bit that C++ can change, and is not used from
Rust. Ideally, in the future, we could just use rust-url to resolve the URL
after parsing or something, and make it all immutable. Maybe.
I've verified that this approach still works with the UA sheet patches (via the
LoadDataSource::Lazy).
The reordering of mWillChange is to avoid nsStyleDisplay from going over the
size limit. We want to split it up anyway in bug 1552587, but mBinding gains a
tag member, which means that we were having a bit of extra padding.
One thing I want to explore is to see if we can abuse rustc's non-zero
optimizations to predict the layout from C++, but that's something to explore at
some other point in time and with a lot of care and help from Michael (who sits
next to me and works on rustc ;)).
Differential Revision: https://phabricator.services.mozilla.com/D31742
--HG--
extra : moz-landing-system : lando
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
This includes style system and layout update. I add 3 extra reftests
because the original tests use ray() function as the offset-path, but we
don't support it. It'd be better to add tests using a different type of
offset-path.
The spec issue about the serialization:
https://github.com/w3c/fxtf-drafts/issues/340
Differential Revision: https://phabricator.services.mozilla.com/D32212
--HG--
extra : moz-landing-system : lando
D29542 fixed the bogus checks that was making nested pseudo-elements match
author rules. This adds tests and ends up being just a cleanup, though as it
turns out we it also fixes an issue with ::slotted() matched from
Element.matches.
Differential Revision: https://phabricator.services.mozilla.com/D27529
--HG--
extra : moz-landing-system : lando
I think these should hold, everything that runs under them should just schedule
other stuff to some later date:
* Synth mouse events -> scheduled as refresh driver observers.
* Scroll events -> Scheduled as well.
* Caret state change events -> Also scheduled after last patch.
* IME and accessibility stuff -> I don't think they can reenter layout.
We can always revert this if it causes troubles, plus it shouldn't crash on
release so should be fine.
Differential Revision: https://phabricator.services.mozilla.com/D31090
--HG--
extra : moz-landing-system : lando
Instead, post the event for the next turn of the event loop.
In this case, what killed the frame is ActionBarHandler.jsm via
Selection.toString().
Depends on D31088
Differential Revision: https://phabricator.services.mozilla.com/D31089
--HG--
extra : moz-landing-system : lando
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
ScrollToShowRect already considers that possibility, so not doing it on the
caller is a bug.
Ideally scroll observers shouldn't be able to run script, more to that in a
second.
Differential Revision: https://phabricator.services.mozilla.com/D31088
--HG--
extra : moz-landing-system : lando
This will save us some time from figuring out what's the best thing to do in
bug 1552587, so that other patches I have in flight (mainly bug 1552708) can
land, since we cannot add a single byte to nsStyleDisplay right now otherwise.
The code removed here is well isolated and not that complicated, so it seems to
me that should be easy to bring back should we have an emergency (and I commit
to doing that while preserving the nsStyleDisplay size limit if we need to :)).
Differential Revision: https://phabricator.services.mozilla.com/D32026
--HG--
extra : moz-landing-system : lando
I did this instead of just (ab)using the fact that every list item has at least
one counter-increment node because:
* I don't have the bullet frame around by the time we initially compute the
counter increment, which means that I'd need to grow nsBlockFrame / add a
frame property for the list item ordinal, which I think would be unfortunate.
* It feels more consistent with the way regular CSS counters work and with the
way we want ::marker to eventually work.
Differential Revision: https://phabricator.services.mozilla.com/D31990
--HG--
extra : moz-landing-system : lando
When you have a ::after::marker, and you compare one against the other we ended
up with the wrong result because of the pseudotype stuff.
I think this is cleaner now that DoCompareTreePosition handles pseudos properly
(which is really the thing this was working around).
Differential Revision: https://phabricator.services.mozilla.com/D31989
--HG--
extra : moz-landing-system : lando
I'm going to need it to fix the counters code in presence of nested
pseudo-elements.
Differential Revision: https://phabricator.services.mozilla.com/D31988
--HG--
extra : moz-landing-system : lando
I thought I was going to need it but turns out I don't. Still this is worth it I
think.
Differential Revision: https://phabricator.services.mozilla.com/D31987
--HG--
extra : moz-landing-system : lando
We don't store post-transform overflow areas for frames within preserve-3d, but we do store pre-transform overflow areas.
Rather than just recomputing the changed overflow for the root, we should recompute overflows for all ancestors up to the 3d root.
Differential Revision: https://phabricator.services.mozilla.com/D31213
--HG--
extra : moz-landing-system : lando
Unpack StyleMotion and move its members into nsStyleDisplay, use
cbindgen to generate StyleOffsetPath.
Differential Revision: https://phabricator.services.mozilla.com/D31164
--HG--
extra : moz-landing-system : lando
This stops nsPrintJob::PrintPreview from duplicating work done in
nsDocumentViewer::PrintPreview.
Differential Revision: https://phabricator.services.mozilla.com/D31811
--HG--
extra : rebase_source : 062cbac323a2a1a0bcc85039b3671c650c408efa
extra : amend_source : 39d5b8c316f518aa72d560ae4eeec171561ab8fd
According to the procedure to update animations and send events[1] the UA should
update all timelines first and _then_ run a microtask checkpoint.
As a result, when we run callbacks for the finished promise on an Animation they
should see the fully up-to-date state of all animations, regardless of which
timeline they are attached to.
However, that is currently not the case since we run a microtask checkpoint
after updating each individual timeline.
This difference will become more significant later in this patch series when we
introduce another step--removing replaced animations--that _also_ should happen
before we run the microtask checkpoint (so that the promise callbacks always see
a fully-up-to-date state).
This patch makes our handling a little more in line with the spec. It's not
quite the same because it's possible there may be other refresh driver observers
that trigger a microtask checkpoint in between ticking the different timelines
but that case is expected to be rare and fixing it would require maintaining
a separate queue for timeline observers that we run after all other observers--
so it is probably not necessary to fix that case at this stage.
The test added in this patch fails without the code changes in this patch.
[1] https://drafts.csswg.org/web-animations-1/#update-animations-and-send-events
Differential Revision: https://phabricator.services.mozilla.com/D30319
--HG--
extra : moz-landing-system : lando
Most of it is not used at this point, this leaves the parts that are used by
MathML, which are minimal.
Differential Revision: https://phabricator.services.mozilla.com/D31706
--HG--
extra : moz-landing-system : lando
This happens in one test on try server that has some iframes that navigate.
I audited everywhere else that we change the view tree, this seems like the only place it can happen.
Differential Revision: https://phabricator.services.mozilla.com/D31399
--HG--
extra : moz-landing-system : lando
We could use ArcSlice if wanted I guess, your call. Though will change is not
supposed to be used very frequently.
Differential Revision: https://phabricator.services.mozilla.com/D30548
--HG--
extra : moz-landing-system : lando
Amend several test files for triggering eval() assertion through simpletest.js
Differential Revision: https://phabricator.services.mozilla.com/D30474
--HG--
extra : moz-landing-system : lando
This happens in one test on try server that has some iframes that navigate.
I audited everywhere else that we change the view tree, this seems like the only place it can happen.
Differential Revision: https://phabricator.services.mozilla.com/D31399
--HG--
extra : moz-landing-system : lando
However, we continue to only respect a <meta name="viewport"> tag if
dom.meta-viewport.enabled is set.
Differential Revision: https://phabricator.services.mozilla.com/D30988
--HG--
extra : moz-landing-system : lando
If an XPIDL interface has a method or attribute that is [notxpcom],
then it is implicitly treated as [builtinclass], even if it is not
marked as such. For clarity, this patch goes through and marks every
place that relies on this behavior (aside from some test code).
Differential Revision: https://phabricator.services.mozilla.com/D30714
--HG--
extra : moz-landing-system : lando
There are three test cases;
1) Two iframes are swapped
2) Changing the visibility of the parent document doesn't clobber a child
document's visibility in the case where the child document has been hidden
by another element in the parent document
3) an iframe is initially inside a visibility:hidden element in the parent
document
Depends on D26253
Differential Revision: https://phabricator.services.mozilla.com/D27842
--HG--
extra : moz-landing-system : lando
Amend several test files for triggering eval() assertion through simpletest.js
Differential Revision: https://phabricator.services.mozilla.com/D30474
--HG--
extra : moz-landing-system : lando
This enables destructors for tagged unions in cbindgen, implemented in:
* https://github.com/eqrion/cbindgen/pull/333
Which allow us to properly generate a destructor for the cbindgen-generated
StyleBasicShape (which now contains an OwnedSlice).
For now, we still use the glue code to go from Box<BasicShape> to
UniquePtr<BasicShape>. But that will change in the future when we generate even
more stuff and remove all the glue.
I could add support for copy-constructor generation to cbindgen for tagged
enums, but I'm not sure if it'll end up being needed, and copy-constructing
unions in C++ is always very tricky.
Differential Revision: https://phabricator.services.mozilla.com/D29769
--HG--
extra : moz-landing-system : lando
This reduces the amount of code that assumes that BrowserParent implements nsIRemoteTab.
Differential Revision: https://phabricator.services.mozilla.com/D31430
--HG--
extra : source : 5f1c1b609ec1ecc28734e1b6daeeb3f6854ded38
This reduces the amount of code that assumes that BrowserParent implements nsIRemoteTab.
Differential Revision: https://phabricator.services.mozilla.com/D31430
--HG--
extra : rebase_source : d639864ba86001cf90a8b3d42b6eda97a7f829ac
extra : histedit_source : 6f6f1e0b6d3561e478391ce9e72a8a2dbc280983
Unfortunately, `EventChainVisitor` does not grab the `nsPresContext` with
`RefPtr` by itself. Therefore, there is no guarantee of the lifetime without
checking the origin when its subclasses are instantiated. This patch changes
it and subclasses to `MOZ_STACK_CLASS` since only `EventDispatcher::Dispatch()`
creates them in the stack with given `nsPresContext`. Additionally, it's
already been marked as MOZ_CAN_RUN_SCRIPT_BOUNDARY`. Therefore, the
`nsPresContext` instance has already been guaranteed its lifetime by the
caller. For making this fact stronger, this patch marks their constructors
as `MOZ_CAN_RUN_SCRIPT`. Therefore, nobody can create those instances without
guaranteeing the lifetime of `nsPresContext` and `dom::Event`. Note that
it may look like that `mPresContext` of `EventChainPostVisitor` is not
guaranteed. However, `EventChainPreVisitor` which gives `nsPresContext` to it
is also a stack only class. So, it won't be deleted before
`EventChainPostVisitor` instance.
Differential Revision: https://phabricator.services.mozilla.com/D30010
--HG--
extra : moz-landing-system : lando
This patch is generated by running the following script under layout/,
and then manually delete the FIXME comment in LayoutConstants.h
#!/bin/bash
function rename() {
find .\
-type f\
! -path "./obj*"\
! -path "./.git"\
! -path "./.hg"\
\( -name "*.cpp" -or\
-name "*.h" \)\
-exec sed -i -e "s/$1/$2/g" "{}" \;
}
rename NS_INTRINSIC_WIDTH_UNKNOWN NS_INTRINSIC_ISIZE_UNKNOWN
Differential Revision: https://phabricator.services.mozilla.com/D29746
--HG--
extra : moz-landing-system : lando
This patch makes widget use `mozilla::PresShell` directly rather than via
`nsIPresShell` and changes some pure virtual methods of `nsIPresShell` which
called by widget to `mozilla::PresShell`'s non-virtual methods.
Differential Revision: https://phabricator.services.mozilla.com/D29112
--HG--
extra : moz-landing-system : lando
We always include the combinator for pseudo-elements now (not including it was
just an optimization) in order to not match when nested pseudo-elements are
involved.
We could add a more generic check in `matches_simple_selector` like:
```
if element.is_pseudo_element() {
match *selector {
Component::PseudoElement(..) |
Component::NonTSPseudoClass(..) => {},
_ => return false,
}
}
```
But even that wouldn't be enough to make selectors like `:hover::marker` not
match on the `::before::marker` pseudo-element, plus that code is really hot.
So for now do the check on the `next_element_for_combinator` function. It's a
bit hacky but it's the best I could came up with...
While at it, simplify some checks to use is_pseudo_element() instead of
implemented_pseudo_element() directly.
Only the Rust patch as-is would make markers for ::before and ::after on list
items not show up, so we also need to switch ::marker to use ProbeMarkerStyle()
rather than ProbePseudoElementStyle(), since the marker should exist even if it
matches no rules.
Differential Revision: https://phabricator.services.mozilla.com/D27529
--HG--
extra : moz-landing-system : lando
`CapturingContentInfo` struct is used only in `PresShell.cpp` so that we can
make it a private struct of `PresShell` if we move all users of them,
i.e., API to access them, from `nsIPresShell` to `PresShell`.
Differential Revision: https://phabricator.services.mozilla.com/D29111
--HG--
extra : source : 91ac1bb728ef0c25e230bae50297794dd631f8f6
extra : amend_source : 920f6137dba0e2f63182297d373f4f59be783113
`nsIPresShell::ScrollAxis` can be used anywhere and it's used by some
utils actually. So, it should be in `mozilla` namespace and perhaps,
`PresShellForwards.h` is a good place to move it rather than creating
new header file.
Differential Revision: https://phabricator.services.mozilla.com/D29110
--HG--
extra : source : d89587999df100be804a749694ac08fffd5ab39d
`CapturingContentInfo` struct is used only in `PresShell.cpp` so that we can
make it a private struct of `PresShell` if we move all users of them,
i.e., API to access them, from `nsIPresShell` to `PresShell`.
Differential Revision: https://phabricator.services.mozilla.com/D29111
--HG--
extra : moz-landing-system : lando
`nsIPresShell::ScrollAxis` can be used anywhere and it's used by some
utils actually. So, it should be in `mozilla` namespace and perhaps,
`PresShellForwards.h` is a good place to move it rather than creating
new header file.
Differential Revision: https://phabricator.services.mozilla.com/D29110
--HG--
extra : moz-landing-system : lando
This change was originally added as a drive-by optimization in Bug 1501665.
The early-exit apparently routes around a needed side effect in the case
where resolution is re-set to its current value.
Differential Revision: https://phabricator.services.mozilla.com/D28566
--HG--
extra : moz-landing-system : lando
And also this patch moves some related methods which use the inline methods
and member variables used only by them.
Differential Revision: https://phabricator.services.mozilla.com/D29201
--HG--
rename : layout/base/nsIPresShellInlines.h => layout/base/PresShellInlines.h
extra : moz-landing-system : lando
There is the following usage of nsIPresShell:
```
nsCOMPtr<nsIPresShell> presShell = do_QueryReferent(mPresShellWeak);
```
So, for changing this to:
```
RefPtr<PresShell> presShell = do_QueryReferent(mPresShellWeak);
```
PresShell should have its own IID.
Differential Revision: https://phabricator.services.mozilla.com/D29197
--HG--
extra : moz-landing-system : lando
Refactor several occurences of `setTimeout()` to avoid triggering the `eval()` assertion.
Differential Revision: https://phabricator.services.mozilla.com/D28851
--HG--
extra : moz-landing-system : lando
We need to do this separately in the WR and non-WR codepaths for picking up
scroll updates for skipped paints.
Differential Revision: https://phabricator.services.mozilla.com/D29061
--HG--
extra : moz-landing-system : lando
Gerald Squelart
Mirko Brodesser
Makoto Kato
Kris Maglione
Sean Feng
Cameron McCormack
Csoregi Natalia
Kagami Sascha Rosylight
Narcis Beleuzu
Botond Ballo
Cosmin Sabou
Emilio Cobos Álvarez
Masayuki Nakano
Brendan Dahl
Coroiu Cristina
Mihai Alexandru Michis
Nicholas Nethercote
Hiroyuki Ikezoe
Ryan Hunt
Kartikaya Gupta
Ting-Yu Lin
Logan Smyth
Bas Schouten
Oana Pop Rus
Peter Van der Beken
Jean-Yves Avenard
Dorel Luca
Boris Zbarsky
Olli Pettay
Jonathan Watt
Brindusan Cristian
Matt Woodrow
Jonathan Kew
Bob Owen
Miko Mynttinen
shindli
sotaro
Brian Grinstead
Daniel Varga
Neil Deakin
Andrea Marchesini
Brad Werth
Gurzau Raul
Andreea Pavel
Ehsan Akhgari
Mark Banner
Edgar Chen
Sylvestre Ledru
arthur.iakab
Boris Chiou
Razvan Maries
Noemi Erli
Brian Birtles
Timothy Nikkel
Jonas Allmann
Ciure Andrei
Andrew McCreight
Nicolas Silva
Michael Kaply
Gijs Kruitbosch
Sebastian Hengst