Rather than adding a native type for nsID objects in WebIDL, this patch just
takes the approach of switching consumers over to using 'any' and calling the
APIs defined in Part 1.
Differential Revision: https://phabricator.services.mozilla.com/D2283
We don't need to expose on both Window and System anymore, as Window now
implies System. I don't remove unnecessary [Exposed=Window] annotations, as
WebIDL upstream has removed PrimaryGlobal.
Differential Revision: https://phabricator.services.mozilla.com/D9399
We don't need to expose on both Window and System anymore, as Window now
implies System. I don't remove unnecessary [Exposed=Window] annotations, as
WebIDL upstream has removed PrimaryGlobal.
Differential Revision: https://phabricator.services.mozilla.com/D9399
This patch was generated by my modeline.py script.
MozReview-Commit-ID: EbVjPLwiUAT
Depends on D4159
Differential Revision: https://phabricator.services.mozilla.com/D4161
--HG--
extra : moz-landing-system : lando
ChildProcessMessageManager, ChromeMessageBroadcaster, and ChromeMessageSender
only implement nsIMessageSender and nsIContentFrameMessageManager. Neither one
has QIs in JS now.
ContentFrameMessageManager only implements nsIDOMEventTarget, which there are
no JS QIs for.
ContentProcessMessageManager implements nsIMessageSender and
nsISupportsWeakReference. The only JS QI for nsISupportsWeakReference is
definitely not happening on this object.
MozReview-Commit-ID: 67dxaQlhpGc
All of these have implementations that only QI to nsIDOMNode and nsISupports, and no one QIs things to nsIDOMNode in script anymore.
MozReview-Commit-ID: 2L4VCEEsLkS
BarProp, CaretPosition, Crypto, CSSMozDocumentRule, CSSPrimitiveValue,
CSSStyleDeclaration, CSSStyleRule, CSSValueList, DOMImplementation,
DOMTokenList, FileList, FrameLoader, FormData, HTMLCollection, History,
MimeTypeArray, NamedNodeMap, MutationObserver, MutationRecord, Navigator,
NodeIterator, PaintRequest, PaintRequestList, Plugin, Rect,
SVGAnimatedEnumeration, SVGAnimatedInteger, SVGAnimatedNumber,
SVGAnimatedNumberList, SVGAnimatedPreserveAspectRatio, SVGAnimatedString,
SVGLengthList, SVGNumberList, SVGPathSegList, SVGPoint, SVGPointList,
SVGPreserveAspectRatio, SVGRect, SVGStringList, SVGTransformList, Touch,
TouchList, TreeWalker, ValidityState only implement nsISupports, so
there's no point QIing them.
DOMStringMap, FrameLoader, NodeIterator, SVGPoint, StyleSheet only implement
non-scriptable non-shimmed interfaces (nsIMutationObserver, nsISVGPoint,
nsICSSLoaderObserver), so can't be usefully QIed from script.
EventSource, Notification, OfflineResourceList, Performance, Screen,
WebSocket, XMLHttpRequestUpload only implement nsIDOMEventTarget, and nothing
QIs to that in script.
PluginArray QIs to nsIObserver but doesn't expose any corresponding methods.
None of the QIs to that interface seem to be on PluginArray objects.
Range QIs to nsIDOMRange, but there is no JS code that QIs to that.
NodeList QIs to nsIDOMNodeList, but there is no JS code that QIs to that.
XMLSerializer doesn't even implement nsISupports.
MozReview-Commit-ID: Fil5cBd4K4d
The change in browser_net_view-source-debugger.js is needed because we now use WebIDL callbacks for MessageListener, and they add async creation stack frames.
--HG--
extra : rebase_source : 0adb349b40a0c51bb3d8f4b9b7d98106a3929cbd
extra : source : a88d94ec010a12c1d829708aaf59a85609478477
The change in browser_net_view-source-debugger.js is needed because we now use WebIDL callbacks for MessageListener, and they add async creation stack frames.
--HG--
extra : rebase_source : d7c026d8a77634ef2566feba78168beb8a66a552
XPConnect wrapper overhead for this interface has been showing up heavily in a
lot of my profiles, in some places accounting for 50ms of the 80ms we spend
getting getting <browser> messageManagers. This improves the situation
considerably.
MozReview-Commit-ID: 9d1hCORxsYG
--HG--
rename : dom/base/nsIFrameLoader.idl => dom/webidl/FrameLoader.webidl
extra : rebase_source : d8a1fc1a19632ba36a9fc6f63873f7534671a13b
There hasn't been any traction on this feature, and we keep
paying the maintenance and code size and memory usage penalty
of having this implementation.
We can revive this from VCS history in the future if we decide
to start working on it again. In the mean time, it's better
to remove it.
