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
