This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13073
--HG--
extra : moz-landing-system : lando
This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13073
--HG--
extra : moz-landing-system : lando
This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13073
--HG--
extra : moz-landing-system : lando
As in part 1, this no longer serves any purpose.
This patch also removes the otherwise unused WrappersEnabled() method, which
was similarly only useful before we had compartment-based security isolation.
Its functionality is now handled by compartment flags.
Differential Revision: https://phabricator.services.mozilla.com/D10796
--HG--
extra : rebase_source : e4c85eda6cdf430844dea828e2eee3a083f2616d
The ID table is managed in BindToTree / UnbindFromTree.
I guess this was more important when XUL templates were a thing.
Differential Revision: https://phabricator.services.mozilla.com/D10056
I left GetMethodInfo, GetConstant as they are still useful as separate methods.
Differential Revision: https://phabricator.services.mozilla.com/D9638
--HG--
extra : moz-landing-system : lando
Removes the now unused platformHTMLBindings.xml.
Differential Revision: https://phabricator.services.mozilla.com/D8932
--HG--
extra : rebase_source : a61de540b9b179af37ceefc59cbb60f08c8ef184
extra : intermediate-source : 15811bce212a0bbe0603ff31f3f95934050afe95
extra : source : 09a985b890cd7be3c5c63d6e59df77e3ac05aa54
platformHTMLBindings attaches event handlers directly to the <input> and
<textarea> elements. This matches that by making TextInputListener look up and
call the <input> and <textarea> event handlers from the static C array.
There is a slight difference in that the event handlers are added to the system
bubbling phase as opposed to the regular bubbling phase but in tests this does
not seem to cause problems.
Differential Revision: https://phabricator.services.mozilla.com/D8931
--HG--
extra : rebase_source : ced468c778aea2f616c2fc544c7c908f969f268c
extra : intermediate-source : 2224ee809328bf70ded5648d0a2896d507def220
extra : source : 0e16c555c00a0321e96c9b62e3df9508dd4ba06a
Rather than loading an XBL binding for <browser> and <editor> elements this
generates the handlers from static C arrays.
Differential Revision: https://phabricator.services.mozilla.com/D6181
--HG--
extra : rebase_source : 690dee71ad81fad157052f342451047f10ef3811
extra : intermediate-source : ac56492b6ed6f03cd61389db83a73e0fdf970089
extra : source : a33e19d9f6d584e51153205efc7b5693119818cc
Copies the keybindings from platformHTMLBindings.xml into an array of C structs
that can be easily used to instantiate an nsXBLPrototypeHandler (done in later
patches).
These were mechanically generated.
Differential Revision: https://phabricator.services.mozilla.com/D8930
--HG--
extra : rebase_source : 01b31333c7b59120976e4aa1481047abe8292e52
extra : source : 72ccc94449163738199ec04886f2f5513bce5122
Removes the now unused platformHTMLBindings.xml.
Differential Revision: https://phabricator.services.mozilla.com/D8932
--HG--
extra : rebase_source : 302ea62c1d8eeb120715c64e9d041e43cfd180fb
extra : intermediate-source : 330598d8c8d934de9fedc0e4342d09f58a7f60dc
extra : source : 09a985b890cd7be3c5c63d6e59df77e3ac05aa54
platformHTMLBindings attaches event handlers directly to the <input> and
<textarea> elements. This matches that by making TextInputListener look up and
call the <input> and <textarea> event handlers from the static C array.
There is a slight difference in that the event handlers are added to the system
bubbling phase as opposed to the regular bubbling phase but in tests this does
not seem to cause problems.
Differential Revision: https://phabricator.services.mozilla.com/D8931
--HG--
extra : rebase_source : cd3cff63cb6a1da1d9130a04bd7ebe9cd7b62b4e
extra : source : 0e16c555c00a0321e96c9b62e3df9508dd4ba06a
Rather than loading an XBL binding for <browser> and <editor> elements this
generates the handlers from static C arrays.
Differential Revision: https://phabricator.services.mozilla.com/D6181
--HG--
extra : rebase_source : 2467fb1c8c1f02ab52a96f44f94d8ee9d6ed33d3
extra : source : a33e19d9f6d584e51153205efc7b5693119818cc
Copies the keybindings from platformHTMLBindings.xml into an array of C structs
that can be easily used to instantiate an nsXBLPrototypeHandler (done in later
patches).
These were mechanically generated.
Differential Revision: https://phabricator.services.mozilla.com/D8930
--HG--
extra : rebase_source : 51b167b1d4a471e8926b34935c895093b02b29a0
If class A is derived from class B, then an instance of class A can be
converted to B via a static cast, so a slower QI is not needed.
Differential Revision: https://phabricator.services.mozilla.com/D6861
--HG--
extra : moz-landing-system : lando
Various places in dom/ use the pattern:
already_AddRefed<NodeInfo> ni = ...;
which is supposed to be disallowed by our static analysis code, but
isn't, for whatever reason. To fix our static analysis code, we need to
eliminate instances of the above pattern.
Unfortunately, eliminating this pattern requires restructuring how Nodes
are created. Most Node subclasses take `already_AddRefed<NodeInfo>&` in
their constructors, and a few accept `already_AddRefed<NodeInfo>&&`. We
need to enforce the latter pattern consistently, which requires changing
dozens of source files.
For browser.xhtml, we have extra whitespace text nodes that appear inside of
mBoundElement, which was causing XBL content to be incorrectly dropped.
Differential Revision: https://phabricator.services.mozilla.com/D5546
--HG--
extra : moz-landing-system : lando
For browser.xhtml, we have extra whitespace text nodes that appear inside of
mBoundElement, which was causing XBL content to be incorrectly dropped.
Differential Revision: https://phabricator.services.mozilla.com/D5546
--HG--
extra : moz-landing-system : lando
The 'x' prefix makes it clearer that these are infallible.
A couple of nsJSID methods are now also infallible.
--HG--
extra : rebase_source : fcce44a00212d6d341afbf3827b31bd4f7355ad5
What's going on is that nested XBL insertion points are completely unsound, and
we leave all sorts of kids in mInsertedChildren when bindings dynamically
change.
So if bindings change in a particular way so that the innermost insertion point
is cleared, but the outermost bindings aren't, like this, we end up with an
inconsistent flattened tree.
This prevents the inconsistent flattened tree in this case, though what ought
to happen in the SetXBLInsertionPoint(nullptr) case is setting the insertion
point to the outer insertion point.
But we don't keep track of all our insertion points, and I don't think it's
worth to fix that given XBL is going away unless it gives us more problems. See
also bug 1425362 & co.
Differential Revision: https://phabricator.services.mozilla.com/D3163
--HG--
extra : moz-landing-system : lando
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
We want to be able to enter the Realm we were in when the callback was created
before calling it, but if the callback stores a cross-compartment wrapper we
don't really have a good way to find that Realm. So we store it explicitly by
storing a global when the callback is created.
The changes to the constructor signatures to use JSObject* instead of
JS::Handle<JSObject*> are so we can avoid having to root the global for these
calls. These changes make two of the constructors ambiguous when nullptr is
being passed for the first arg; this patch adds casts to disambiguate.
Mostly automatic via sed. Only parts which I touched manually (apart from a
couple ones where I fixed indentation or which had mispelled arguments) are the
callers. I may have removed a couple redundant `virtual` keywords as well when
I started to do it manually, I can revert those if wanted.
Most of them are just removing the argument, but in Element.cpp I also added an
assertion for GetBindingParent when binding the ShadowRoot's kids (the binding
parent is set from the ShadowRoot constructor, and I don't think we bind a
shadow tree during unlink or what not which could cause a behavior difference).
Differential Revision: https://phabricator.services.mozilla.com/D2574
MozReview-Commit-ID: 2oIgatty2HU
GetOrCreateMapEntryForPrototype is the only caller where the object could be a CCW. However there cx and proto are same-compartment (GetOrCreateMapEntryForPrototype asserts this) so I changed that code to use JS::CurrentGlobalOrNull.
