This defines a few additional globals but also turns on the browser environment
for everything in browser and toolkit. This may lead to some false negatives
but we have lots of code that runs in a browser context so in the name of
getting rules turned on I think this is a useful step.
MozReview-Commit-ID: BdWouZGK6d
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
While working on turning on no-undef I discovered that the various rules we
have for defining globals are a little inconsistent in whether the files they
load recurse through import-globals-from directives and none of them imported
eslint globals directives.
I think we're better off putting all this global parsing code in a single place
rather than spread across multiple rules. Have one rule to turn it on for
parsed files and one function to load globals from other files and make them
share most of the code so we won't get inconsistent. If we find us needing to
turn on/off individual features we can figure out a way to do that in the
future.
This patch does that, the globals.js file does all global parsing with a shared
object that receives events from the AST, either through from an ESlint rule
or from a simple AST walker using estraverse.
MozReview-Commit-ID: 9KQZwsNNOUl
We can't run Docker-in-Docker, so this is a clone of
https://hub.docker.com/r/sonatype/nexus, modified to run additional
commands. Sonatype Nexus officially supports the Oracle JDK but the
OpenJDK appears to work as well, so we use it.
This bakes a build.sh and Gradle-specific dependencies into the docker
image. This makes sense in a future where the dependencies this
fetches are baked into the image used to build Fennec. It makes less
sense right now, when the dependencies are uploaded to tooltool and
subsequently consumed. It's not critical that we get this right
immediately.
The actual build.sh script runs the Gradle wrapper for a special
dependency project. The wrapper installs Gradle itself, downloads a
large number of Gradle dependencies, and uses Jake Wharton's
https://github.com/JakeWharton/sdk-manager-plugin/ to download and
install the Android SDK. (We could use |mach bootstrap|, but that
doesn't (yet) support non-interactive use, and I want to try to use
the SDK Manager more generally.) These outputs are then packaged for
further use: right now, they're exposed as artifacts, but eventually
we'll upload them directly to tooltool.
MozReview-Commit-ID: 7upsk1ANuxN
Be warned. Do not attemp to change the .js "test" source code in ./js
They are meant to check
- the outdated 0666 octal constant is still parsed correctly,
- the outdated 0666 octal constant raises syntax error flag
in strict mode, etc.
So leave them alone.
We can't run Docker-in-Docker, so this is a clone of
https://hub.docker.com/r/sonatype/nexus, modified to run additional
commands. Sonatype Nexus officially supports the Oracle JDK but the
OpenJDK appears to work as well, so we use it.
This bakes a build.sh and Gradle-specific dependencies into the docker
image. This makes sense in a future where the dependencies this
fetches are baked into the image used to build Fennec. It makes less
sense right now, when the dependencies are uploaded to tooltool and
subsequently consumed. It's not critical that we get this right
immediately.
The actual build.sh script runs the Gradle wrapper for a special
dependency project. The wrapper installs Gradle itself, downloads a
large number of Gradle dependencies, and uses Jake Wharton's
https://github.com/JakeWharton/sdk-manager-plugin/ to download and
install the Android SDK. (We could use |mach bootstrap|, but that
doesn't (yet) support non-interactive use, and I want to try to use
the SDK Manager more generally.) These outputs are then packaged for
further use: right now, they're exposed as artifacts, but eventually
we'll upload them directly to tooltool.
MozReview-Commit-ID: 7upsk1ANuxN
Opt-in by adding --enable-gradle-mobile-android-builds.
Gradle dependencies (including the Android-Gradle plugin) are assumed
to be present. Local developers will fetch them from the jcentral
repository.
Android-specific Maven dependencies are shipped as "extras" with the
Android SDK, and should be found automatically by the Android-Gradle
plugin.
MozReview-Commit-ID: 966XgddWgEu
This patch introduces a small utility program to extract a guid from a shared library
or executable on windows to identify the correct symbol file to read in fix_stack_using_bpsyms.py.
In order for this to work correctly on windows, the library name provided by
MozDescribeCodeAddress needs to be a full path, so the LoadedImageName field
from the IMAGEHLP_MODULE64 structure is used here instead of the ModuleName
field.
EventUtils.js previously allowed you to override the Window object
reference through passing it as an optional argument to its functions.
This change fixes certain uses of implicit globals that reside on Window.
MozReview-Commit-ID: EJT8iIs85ej
This change removes almost all the remaining uses of loadSubScript and
global scope pollution. The only remaining use is for common.js, which
is resolved by a later bug for evaluating scripts.
MozReview-Commit-ID: 96h0yLElauq
To simplify the dependency chain and reduce the number of duplicate
functions in Marionette, a number of functions have been removed from
interactions.js and added to elements.js. This makes them more easily
re-usable and works around a circular dependency issue.
MozReview-Commit-ID: TZc3VZzHqM
Through some very clever hacking of the arguments to each of the atoms,
we are able to contain this in a JS module: Atoms normally extract their
arguments directly from the function scoped `arguments' variable, but
by explicitly naming `window' as the last argument in the functions'
prototype we are able to set the `window' variable used inside.
This is obviously a big hack, but it encapsulates the atoms and we are
moving away from atoms in the long term.
MozReview-Commit-ID: KGO77fjRN2d
testing/marionette/sendkeys.js has been merged into the
new testing/marionette/event.js module, together with
testing/marionette/EventUtils.js.
There is a lot of functionality still left in this module that we can
probably remove, as it is not in use by Marionette.
MozReview-Commit-ID: GrjNuK9VPjp
Generally, Error prototypes that are not based on WebDriverError must
be wrapped so that they can be serialised across the AsyncMessageChannel.
MozReview-Commit-ID: EtkpEOBhrST
Due to a previous programming error, error.isError only recognised
the base Error prototype. It must also test for the other built-in
prototypes, such as TypeError et al.
MozReview-Commit-ID: HLkiOAg0Jl1
