Importing this object is unnecessary after the updates to the WebIDL console from Bug 1425574
and the follow-ups blocking Bug 1430810. There are still callers that access Console.jsm
to create custom ConsoleAPI objects, but those will be handled separately.
MozReview-Commit-ID: 9ojFxtkpPId
--HG--
extra : rebase_source : 971bf99f709b8d2afe300f3693665724f747aa5e
This is enough to get the stylo-enabled build green.
There's still some orange in WPT with stylo disabled (due to interfaces not
exposed and that) that I'll update tomorrow.
Will send a different patch on top of this for that, though I'll land together.
MozReview-Commit-ID: CsN5CM93RUz
The hack caused bytecode for block declaration instantiation to be assigned the
location of the first statement inside the block. Unfortunately it made the
source view of the debugger client seem out of sync with the Scopes panel: when
paused after hitting a breakpoint on that line or stepping there, the source
panel showed our location as being inside the block, but the Scopes panel did
not show a block scope.
Two server tests required fixes (also r=jimb, in a separate patch in the same
bug).
test_stepping-08.js assumes that stepping into a function stops at the first
statement in the function. This is usually true. However, now we are removing a
hack, such that our actual behavior for this *particular* function is to stop
at the opening curly brace. This causes the test to fail, without anything
really being broken.
The test is intended to test the interaction of stepping and breakpoints, so
the fix that stays truest to the purpose of the test is to change the debuggee
here to a function with no prologue instructions, so that we don't stop at the
opening brace.
test_blackboxing-01.js is a similar story.
--HG--
extra : rebase_source : 7afc6cc039f313889ee08cdd93ce114691efa1e9
extra : histedit_source : dc274b7cefbb96574c8207a78db05d80238d291d
See the comment on "Address test failures caused by bumping timer precision to 2 ms"
for more details.
MozReview-Commit-ID: LrsucEPdZIo
--HG--
extra : rebase_source : 8147c034f7dc93f678eebc80b0afabf55729d804
There are a few different reasons why tests needed updating (not an exhaustive list):
- Tests assume that successive operations take place at different times.
- Tests assume that an operation took a minimum amount of time.
- Tests hardcodes a specific delay.
In most cases we hardcode the preference off. In some cases this is the best approach,
in others, we would like to improve. The bug for tracking those improvements is Bug 1429648
An improvement that is present in some tests is to hardcode a specific precision reduction
that is acceptable based on the confides of the test. (Obviously this needs to be a fix for
the test framework and not a requirement on the feature being tested.)
In a few places, the test itself can be fixed, for example to no longer require the end
time of an operation to be strictly greater than the start time, and allows it to be equal
to it.
MozReview-Commit-ID: J59c7xQtZZJ
--HG--
extra : rebase_source : df8a03e76eaf9cdc9524dbb3eb9035af237e534b
This affects several tests, and in all but one case merely disables timer precision
reduction on those tests.
In the other singular test, it no longer requires the end time of an operation to
be strictly greater than the start time, and allows it to be equal to it.
MozReview-Commit-ID: J59c7xQtZZJ
--HG--
extra : rebase_source : c82310ce0269798a9c5bfffaec1f63a24ddc98e5
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
--HG--
extra : rebase_source : d9c41878036c1ef7766ef5e91a7005025bc1d72b
FunctionDeclarations are instantiated when we enter a scope, before any of the
code in that block/script/function is evaluated. The spec calls this phase
"declaration instantiation"; sometimes it's informally called "hoisting".
Before this patch, stepping would show this. You would step into a function,
and hitting the Step Over button a few times would visit all the nested functions
in that function. Then you would jump back to the top of the outer function and
actually start running the statements. This is so confusing that we are
changing it; now opcodes that instantiate functions don't have location
information, so stepping doesn't stop on those opcodes.
--HG--
extra : rebase_source : d8de1fc50573b82bf76dc7464355bfba068eaa30
extra : source : b94db3c0c2c0752915e2f4401269a0d24cbef882
Inspector actor traits were used for backward compatibility, with
versions of Firefox older than 45. Our policy is to support servers
up to the last ESR version, which is 52 at the moment so these
should be safe to remove.
MozReview-Commit-ID: 6MwUp8vbW29
--HG--
extra : rebase_source : b36799130e66e4abdaee628d48ad1b056bc1afcd
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
extra : intermediate-source : 34c999fa006bffe8705cf50c54708aa21a962e62
extra : histedit_source : b2be2c5e5d226e6c347312456a6ae339c1e634b0