Move functionality out of XULDocument::AddElementToDocumentPost:
1) Convert all XUL link elements into HTML link elements which have
code to handle when they are added to the DOM.
2) Move handling of the end of a linkset element into nsXULElement's DoneAddingChildren callback.
3) Move document direction reset to where the root element is created.
Differential Revision: https://phabricator.services.mozilla.com/D19739
--HG--
extra : moz-landing-system : lando
Replacing js and text occurences of asyncOpen2
Replacing open2 with open
Differential Revision: https://phabricator.services.mozilla.com/D16885
--HG--
rename : layout/style/test/test_asyncopen2.html => layout/style/test/test_asyncopen.html
extra : moz-landing-system : lando
With these changes, XBL just runs in the window scope of whatever document it's
attached to. Since (outside of tests and "remote XUL") we no longer attach XBL
to web documents, this is fine. And "remote XUL" already ran without the XBL
scope.
Native anonymous content, which used to be placed in the XBL scope to hide it
from the page, is now placed in the unprivileged junk scope, so it stays hidden
from the page.
dom/xbl/test/test_bug944407.xul is being removed because we are changing the
behavior it's trying to test for. Since we now always put the XBL in the same
scope as the page, script is enabled for the XBL if and only if it's enabled for
the page.
dom/base/test/test_bug419527.xhtml, dom/events/test/test_bug391568.xhtml,
dom/xbl/test/test_bug1086996.xhtml are being switched to a chrome test because
otherwise the XBL can't see the getAnonymousNodes method.
All the XBL bits are being removed from test_interfaces because we no longer
have a separate XBL scope to test the behavior of.
js/xpconnect/tests/mochitest/test_nac.xhtml is being removed because XBL no
longer has access to NAC unless the page it's attached to does too, so the test
doesn't really make sense.
layout/xul/test/test_bug1197913.xul is being switched to a chrome test because
its XUL elements use bindings that rely on APIs that are not exposed to normal
web content.
layout/reftests/bugs/495385-2f.xhtml is being removed because I can't think of
a sane way to test that in the new world, short of running the reftest as
chrome. And it doesn't seem worthwhile to look for a way to do that.
dom/xbl/test/test_bug1098628_throw_from_construct.xhtml now needs to
expectUncaughtException(), because the exception is now being thrown in Window
scope.
dom/xbl/test/test_bug1359859.xhtml needs to expectUncaughtException() as needed
and not use XPCNativeWrapper (which it doesn't need to anyway now).
dom/xbl/test/test_bug389322.xhtml, dom/xbl/test/test_bug400705.xhtml,
dom/xbl/test/test_bug401907.xhtml, dom/xbl/test/test_bug403162.xhtml,
dom/xbl/test/test_bug526178.xhtml, dom/xbl/test/test_bug639338.xhtml don't need
to use XPCNativeWrapper anymore.
dom/xbl/test/test_bug821850.html is being removed because it exists only to test XBL scopes.
dom/xbl/test/file_bug950909.xml is being changed to work without a separate XBL
scope (though whether the test still makes sense at that point is a bit questionable).
Differential Revision: https://phabricator.services.mozilla.com/D19260
--HG--
extra : moz-landing-system : lando
I am not a huge fan of the UnwrapReflectorToISupports setup here. Maybe we
should introduce two differently-named methods that make it somewhat clear what
the limitations of not taking a JSContext are? I couldn't think of sane
naming...
Differential Revision: https://phabricator.services.mozilla.com/D17885
--HG--
extra : moz-landing-system : lando
I am not a huge fan of the UnwrapReflectorToISupports setup here. Maybe we
should introduce two differently-named methods that make it somewhat clear what
the limitations of not taking a JSContext are? I couldn't think of sane
naming...
Differential Revision: https://phabricator.services.mozilla.com/D17885
--HG--
extra : moz-landing-system : lando
I am not a huge fan of the UnwrapReflectorToISupports setup here. Maybe we
should introduce two differently-named methods that make it somewhat clear what
the limitations of not taking a JSContext are? I couldn't think of sane
naming...
Differential Revision: https://phabricator.services.mozilla.com/D17885
--HG--
extra : moz-landing-system : lando
This patch cleans up the assertion added in bug 1426492.
With that we have disallowed all bindings in content HTML.
The XMLPrettyPrint binding was removed in bug 1503019.
Depends on D17575
Differential Revision: https://phabricator.services.mozilla.com/D17576
--HG--
extra : moz-landing-system : lando
This patch removes the XBL pluginProblem binding and have the in-content
UI always created by the UA Widget.
Depends on D17573
Differential Revision: https://phabricator.services.mozilla.com/D17574
--HG--
extra : moz-landing-system : lando
This patch removes the XBL marquee binding and always uses
UA Widget for the internal "gut" of the marquee element.
Depends on D17572
Differential Revision: https://phabricator.services.mozilla.com/D17573
--HG--
extra : moz-landing-system : lando
This patch removes the datetimebox binding and always use
UA Widget for the job.
Depends on D17571
Differential Revision: https://phabricator.services.mozilla.com/D17572
--HG--
extra : moz-landing-system : lando
This patch removes the XBL videocontrols binding and make <video>
to always use the UA Widget to generate controls.
DevTools tests that look for NAC is switched to use <input type=file>.
Differential Revision: https://phabricator.services.mozilla.com/D17571
--HG--
extra : moz-landing-system : lando
***
Bug 1514594: Part 3a - Change ChromeUtils.import to return an exports object; not pollute global. r=mccr8
This changes the behavior of ChromeUtils.import() to return an exports object,
rather than a module global, in all cases except when `null` is passed as a
second argument, and changes the default behavior not to pollute the global
scope with the module's exports. Thus, the following code written for the old
model:
ChromeUtils.import("resource://gre/modules/Services.jsm");
is approximately the same as the following, in the new model:
var {Services} = ChromeUtils.import("resource://gre/modules/Services.jsm");
Since the two behaviors are mutually incompatible, this patch will land with a
scripted rewrite to update all existing callers to use the new model rather
than the old.
***
Bug 1514594: Part 3b - Mass rewrite all JS code to use the new ChromeUtils.import API. rs=Gijs
This was done using the followng script:
https://bitbucket.org/kmaglione/m-c-rewrites/src/tip/processors/cu-import-exports.jsm
***
Bug 1514594: Part 3c - Update ESLint plugin for ChromeUtils.import API changes. r=Standard8
Differential Revision: https://phabricator.services.mozilla.com/D16747
***
Bug 1514594: Part 3d - Remove/fix hundreds of duplicate imports from sync tests. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16748
***
Bug 1514594: Part 3e - Remove no-op ChromeUtils.import() calls. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16749
***
Bug 1514594: Part 3f.1 - Cleanup various test corner cases after mass rewrite. r=Gijs
***
Bug 1514594: Part 3f.2 - Cleanup various non-test corner cases after mass rewrite. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16750
--HG--
extra : rebase_source : 359574ee3064c90f33bf36c2ebe3159a24cc8895
extra : histedit_source : b93c8f42808b1599f9122d7842d2c0b3e656a594%2C64a3a4e3359dc889e2ab2b49461bab9e27fc10a7
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.
This needs to add a few of includes in other places which were relying on the
massive (now gone) list in nsDocument.h.
I also needed to move an AnimationTimeline destructor out of line because it
relied on dom::Animation being defined, yet Animation.h includes
AnimationTimeline.h, so include hell.
Differential Revision: https://phabricator.services.mozilla.com/D15366
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
Dorel Luca
Jonathan Kingston
Emilio Cobos Álvarez
Brendan Dahl
Boris Zbarsky
Gurzau Raul
Ciure Andrei
Cosmin Sabou
Timothy Guan-tin Chien
Kris Maglione
Ehsan Akhgari
Sylvestre Ledru
Jon Coppeard
Mark Banner
Mats Palmgren
Andreea Pavel
Peter Van der Beken
Gabriele Svelto
Adrian Wielgosik
Dave Townsend
Daniel Varga