I missed a couple of references in cleanup code. This wouldn't have caused any
failures but might result in addons not being cleaned up properly.
MozReview-Commit-ID: BX0oX2GRGWT
--HG--
extra : rebase_source : 2193adb4e96b8e70faa6ffb1afd6db698b10ad2d
Now that the correct filename and line number is being passed to
Cu.evalInSandbox, the stacktrace of the thrown error is correct.
JavaScriptError uses the line number to index the injected source
script, but the line number refers to the file represented by the
"filename" parameter and not to the script.
This effectively means that the line numbers in the produced
stacktrace are wrong because line number 0 was hard-coded as an
argument to Cu.evalInSandbox.
This patch harmonises the stacktraces returned from
WebDriver:ExecuteScript and WebDriver:ExecuteAsyncScript with
stacktraces from normal JavaScript errors, by removing some extra clutter.
MozReview-Commit-ID: 9nm6HeA4YVJ
--HG--
extra : rebase_source : e0f6e0c9595456fb59123adc98cea6d3d32abce3
The basename is not sufficient to locate the file. Using the file's
relative path will match the behaviour of JavaScript stacktraces.
We can't use relative paths on Windows because the source file may
exist on another disk drive, and on Windows you cannot make relative
paths across disk drives because they don't share the same root.
MozReview-Commit-ID: 4EPITa2kH6J
--HG--
extra : rebase_source : 44781ee506b5150b8e48e8a6b63142badee5b172
The injected script may contain a lot of whitespace padding on
either side of the string when using multi-line strings ("""foo""")
in Python. To improve readability of the trace log we can strip
it off before sending it to Marionette.
MozReview-Commit-ID: 2cNlwVzqWTK
--HG--
extra : rebase_source : 1ec06523a6e99e188b8cb7b616b357c1e9dea125
Marionette incorrectly sets the JavaScript context line number to 0.
The line number is provided to us in in the input, so we should
use this. The default fallback if line is not provided is 0 as before.
MozReview-Commit-ID: 8gOt9r4awee
--HG--
extra : rebase_source : 3d268fff56554c76cbcb831dd2c8665dffd2ca08
The test change is needed because there is no notok() function. But the old
nsIDOMEventListener setup would fail to report the exception anywhere, so the
test still passed (albeit without testing what it thought it was testing). The
new setup reports the exception via an error event on the window, and the test
harness notices that.
MozReview-Commit-ID: 3ISmcyhMk0R
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
We could have used the new NS_NewCStringInputStream overload here, but
it seemed nicer to directly transfer ownership into the newly-created
stream. If we're going to be more efficient here, we might as well go
as far as when can without making the code too ugly.
The XXX comment here wants to give up the string data when we create the
outgoing stream. Giving up the string data is legitimate, because
GetEncodedSubmission is the last operation to be called on this object;
mQueryString is effectively dead after this function returns.
Accordingly, we can Move() mQueryString into the outgoing stream for a
nice efficiency boost.
There are several project aliases for taskgraph's `run_on_projects`. Add the
appropriate `comm-*` branches to those aliases.
Differential Revision: https://phabricator.services.mozilla.com/D863
--HG--
extra : source : 918004b0cc5d69f7fb05b1fcbb0adb06f6966bf0
extra : amend_source : 34414fd9ced8b73306836397e3acee26c68bb968
Remote WebExtension panels can cause us to recreate the widget for a view that
already has a size. In the past, popup widgets were always created with an
initial size of 0x0, so setting the initial size of the ChildView to 0x0
resulted in correct behavior because the window would be resized to the correct
size shortly afterwards, and resize the ChildView along with it via its auto
resizing mask.
When we recreate a widget which already has a known size, setting the initial
size to 0x0 is wrong. We need to set the ChildView's size so that it fills the
contentView of the popup window completely.
MozReview-Commit-ID: 53d3AX3z5h2
--HG--
extra : rebase_source : 7720a6dd12ad7f8efc102cd1430a9e1ed2f5ee0f
Test that play() on a media without audio called before
readyState >= HAVE_METADATA will still play.
MozReview-Commit-ID: 1FeDrEfCEum
--HG--
extra : rebase_source : be6d07905aad853ad028eac372e4e380bdeb1a49
extra : source : e98b4a7aaf020fa3d6d59cb0f53680ef6466d154
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
This changes semantics in all sorts of ways (e.g. now we get the right proto
from our |this| value instead of it being baked into the function). But if all
our chrome callers are well-behaved this should be ok.
We _could_ bake the proto id and depth into the function itself by using
js::NewFunctionWithReserved if it were not for Xrays. Those already need the
reserved slots on functions we Xray.
MozReview-Commit-ID: 1bYrKWWIc1P
Right now we do this check pretty much always anyway for isInstance... we do it
twice for anything that actually has [ChromeOnly] bits.
MozReview-Commit-ID: FHbYED4FPJe
We can't make it non-scriptable, becuse we have _one_ case in which we actually
expose a C++ event listener to script: the return value of
nsISessionStoreUtils.createDynamicFrameEventFilter.
MozReview-Commit-ID: KTv2WsvGN52
