This doesn't change behavior but it's simpler. I found it while
debugging a failure with the previous patches.
Depends on D174316
Differential Revision: https://phabricator.services.mozilla.com/D174365
Starts to add part of the basic functionality for popover. Including
[1] :open & :closed CSS pseudo class
[2] showPopover(), hidePopover() and togglePopover() interfaces. Much of the
functionality is still to-do.
[3] PopoverData interface
Differential Revision: https://phabricator.services.mozilla.com/D171719
This should both be faster and simpler. Also will allow us in the future
to animate more pseudos without having to add a gazillion properties.
I think we should try to clear more stuff (maybe the whole animation
data) on unbind, but that's a bit tangential.
Differential Revision: https://phabricator.services.mozilla.com/D169860
This change adds support for `content-visibilty: auto` as well as
showing and hiding content based on the relevancy of the content as
defined in the specification. Changes to relevancy are handled by
triggering updates in a set of `content-visibility: auto` frames stored
in PresShell at the appropriate time in the document lifecycle.
Some tests are now failing due to this feature exposing the failures,
but they will be fixed in later changes.
This change is a reland of an earlier version that properly updates
intrinsic sizes and triggers an update of remembered size for the
purposes of contain-intrinsic-size when content relevancy changes.
Co-authored-by: Jihye Hong <jihye@igalia.com>
Differential Revision: https://phabricator.services.mozilla.com/D159693
This change adds support for `content-visibilty: auto` as well as
showing and hiding content based on the relevancy of the content as
defined in the specification. Changes to relevancy are handled by
triggering updates in a set of `content-visibility: auto` frames stored
in PresShell at the appropriate time in the document lifecycle.
Some tests are now failing due to this feature exposing the failures,
but they will be fixed in later changes.
Co-authored-by: Jihye Hong <jihye@igalia.com>
Differential Revision: https://phabricator.services.mozilla.com/D159693
This is mostly edge-casey, but see bug 1757156 for an example where it's
causing some issues (granted, they could use `href="#"` or something
instead of an empty href).
It feels weird if a link looks like a link (because the CSS definition
of a link matches, which is "has an href") but then mostly doesn't
behave as a link.
We can't navigate anywhere if we don't have a valid URI but maybe JS
handles the relevant events as in bug 1757156.
Use the CSS definition (has href) since that's interoperable across
browsers. This should also make some stuff much faster (since checking
'is link' is now just a bit check instead of a virtual call).
(Awaiting try results, if no tests need adjustments then I need to write
some)
Differential Revision: https://phabricator.services.mozilla.com/D142107
If the element ever gets children, then the live collection would slow
things down.
It's unclear if the collection here is worth it at all, fwiw.
I guess it could if someone writes code looping around
childElementCount, or calls it repeatedly with a lot of children...
But maybe we should just implement it the dumb way? FWIW, WebKit and
Blink both do the equivalent of just walking over the child nodes
counting elements... Perhaps follow-up bug if you think it's worth doing
the same?
Depends on D118032
Differential Revision: https://phabricator.services.mozilla.com/D118033
This was generated with:
```
rg -l -g '*.{cpp,h}' MOZ_XBL . | while read FILE ; do
echo $FILE
unifdef -m -UMOZ_XBL $FILE
done
```
After this, I manually removed the directive in nsContentUtils.cpp due to:
unifdef: ./dom/base/nsContentUtils.cpp: 4630: Unterminated string literal
unifdef: Output may be truncated
Differential Revision: https://phabricator.services.mozilla.com/D51337
--HG--
extra : moz-landing-system : lando
When XBL is disabled, no code in dom/xbl will be built. Also, adds ifdefs
to remove any of the XBL related code elsewhere. There's definitely more
that can be done here, but I think it's better to wait to do the rest of
the cleanup when we actually remove the code.
Depends on D45612
Differential Revision: https://phabricator.services.mozilla.com/D45613
--HG--
extra : moz-landing-system : lando
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
Since sed on multiple lines ended up being such a pain and I didn't end up
writing a script for this because I didn't think it'd end up being so boring, I
may have made a couple cleanups here and there as well...
Differential Revision: https://phabricator.services.mozilla.com/D2887
--HG--
extra : moz-landing-system : lando