This test has been disabled because it was failing intermittently with a pretty high
frequency on the Windows platform, the reasons behind the failures have been fixed
in Bug 1435100.
MozReview-Commit-ID: 6Dxm8nTVXgq
We currently report a useful location in error reports when extensions fail to
resolve a promise or call a response callback, but in some slightly
less-than-ideal ways. We currently generate a complete stack and parse its
string value (which is expensive), and then report the caller location as part
of the message, rather than as the error's location and stack.
This patch changes that behavior to store a single SavedStack frame, and to
properly report that as the location of the error.
MozReview-Commit-ID: Jmtf4C1O6pW
Currently, when we create an error object at the end of an aysnc operation, we
only get a useful caller location if async stacks are enabled.
This patch changes our behavior to use the saved caller location we've already
stored when creating an Error object based on a plain string message.
MozReview-Commit-ID: DDO0lAUHYRO
When we report errors generated by async API operations, they are currently
not tied to any relevant extension source location. Instead, the locations in
the error reports point to the location in the framework code which reported
the error, which makes things extremely difficult to diagnose.
This change saves the extension caller location at the beginning of async API
operations, and adds it to the error reports genearted by that operation. This
should give extension developers a useful starting point for debugging them.
MozReview-Commit-ID: AkknkKEosFt
This patch implements the preference "browser.tabs.insertAfterCurrent" which,
when set to true, will cause all tabs (related and unrelated) to be opened next
to the current tab.
It also implements the browserSettings API "newTabPosition", which allows
extensions to control both "browser.tabs.insertRelatedAfterCurrent", and
"browser.tabs.insertAfterCurrent" via values for "afterCurrent",
"relatedAfterCurrent" and "atEnd".
The code for "browser.tabs.insertAfterCurrent" including the test for it is
mostly taken from a patch attached to bug 933532 written by Masayuki Nakano.
MozReview-Commit-ID: KQE7M2FGpc7
Now, callers of EventUtils.synthesizeKey() don't need to specify
KeyboardEvent.code value anymore if they assume that active keyboard layout
is US keyboard layout.
Note that this patch changes the meaning of only test_bug551434.html.
Some callers in it don't match the key value and code value but that looks
like that they don't checking such odd keyboard events. So, they must be
bug of the test.
MozReview-Commit-ID: Itxo7yZ9rkK
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <![CDATA[, """ or '''. The first two
cover comments, the third one covers JS, the fourth covers JS embedded
in XUL, and the final two cover JS embedded in Python. This also
applies if the removed line was the first line of the file.
It covers the pattern matching cases like "var {classes: Cc,
interfaces: Ci, utils: Cu, results: Cr} = Components;". It'll remove
the entire thing if they are all either Ci, Cr, Cc or Cu, or it will
remove the appropriate ones and leave the residue behind. If there's
only one behind, then it will turn it into a normal, non-pattern
matching variable definition. (For instance, "const { classes: Cc,
Constructor: CC, interfaces: Ci, utils: Cu } = Components" becomes
"const CC = Components.Constructor".)
MozReview-Commit-ID: DeSHcClQ7cG