This adds more of the scripts that browser.js relies on and also makes
browser-chrome head files import the browser.js globals.
The MOZ_JSDOWNLOADS block in contentAreaUtils only seems to hide a single
function, I don't see any need to keep hiding that now we're on by default.
MozReview-Commit-ID: 5zvF3JtJrZG
To properly lint XBL files we need to support things like import-globals-from
and other ESlint comment directives so we have to pass comments through to the
code blocks that ESlint parses. Unfortunately the way the XBL processor works
now is by passing a separate code block for every method/property/etc. in the
XBL and ESlint doesn't retain state across the blocks so we would have to prefix
every block with every comment. Instead this change makes us output just a
single block that roughly looks like this:
<comments>
var bindings = {
"<binding-id>": {
<binding-part-name>: function() { ... }
}
}
This has some interesting bonuses. Defining the same ID twice will cause a lint
failure. Same for the same field in a binding. The line mapping is a little
harder and there are still a few lines that won't map directly back to the
original file but they should be rare cases. The only downside is that since
some bindings have the same binding declared differently for different platforms
we have to exclude those from linting for now.
MozReview-Commit-ID: CAsPt5dtf6T
This adds more of the scripts that browser.js relies on and also makes
browser-chrome head files import the browser.js globals.
The MOZ_JSDOWNLOADS block in contentAreaUtils only seems to hide a single
function, I don't see any need to keep hiding that now we're on by default.
MozReview-Commit-ID: 5zvF3JtJrZG
To properly lint XBL files we need to support things like import-globals-from
and other ESlint comment directives so we have to pass comments through to the
code blocks that ESlint parses. Unfortunately the way the XBL processor works
now is by passing a separate code block for every method/property/etc. in the
XBL and ESlint doesn't retain state across the blocks so we would have to prefix
every block with every comment. Instead this change makes us output just a
single block that roughly looks like this:
<comments>
var bindings = {
"<binding-id>": {
<binding-part-name>: function() { ... }
}
}
This has some interesting bonuses. Defining the same ID twice will cause a lint
failure. Same for the same field in a binding. The line mapping is a little
harder and there are still a few lines that won't map directly back to the
original file but they should be rare cases. The only downside is that since
some bindings have the same binding declared differently for different platforms
we have to exclude those from linting for now.
MozReview-Commit-ID: CAsPt5dtf6T
The main change here is that nodeFronts that have already been displayed
in the timeline are stored in a WeakMap so they can be retrieved from it
next time they're displayed and avoid a server-side round trip which, in
turn, causes the UI to flicker.
The other change is that now, it is possible to tell the animations actor
what is the current walker actor, which allows animation player actors to
directly send the NodeActor ID as part of their forms. Which, in most cases,
completely eliminates the server round-trip, because the corresponding
NodeFronts are already known on the client, so we get them from there.
The last change done here is that AnimationTargetNode now becomes a thin
wrapper on top of the new DomNodePreview component that was extracted so
it can be reused in other places.
Devtools has a lot of eslint failures right now that would block us from turning
on compile time eslint checks in bug 1229588. For now I'd like to just ignore
the directory and then you can work to clean up the warnings and re-enable
checks at whatever pace you like.
The base .eslintrc is essentially a merge of the root Toolkit .eslintrc and
the devtools .eslintrc, with some minor changes to match our prevalent style.
For the most enforces the coding styles that we've been using most
consistently. There are a couple of significant differences, though:
* The rule for opening brace alignment can only be applied globally, and
doesn't make exceptions for top-level functions. I chose to turn it on, and
change the brace style of existing top-level functions that violated it,
since the rule seemed worth using, and that's the direction most Toolkit JS
code has been headed anyway.
* The rule for switch/case statements requires an added indentation level for
case statements. Most of our switch statements did not use an extra level
of indentation, and I initially wrote the rule to enforce that style, until
I came across case statements that used blocks, and required the extra
indentation level for sanity.
