DOM/Engineering: Difference between revisions

← Older edit

DOM/Engineering (view source)

Revision as of 08:59, 12 September 2019

4,085 bytes added , 12 September 2019

→‎Writing Patches and asking for Code Reviews: Added Landing A Patch section

Sigibln

43

edits

@@ Line 36: / Line 36: @@
 === Communication: Participate in Spec Development ===
-* Listen and participate.
-** Watch the github repo.
-** Join the mailing list.
-=== Mechanics: WebIDL ===
+The [https://whatwg.org/working-mode WHATWG Working Mode] provides a helpful introduction to web standards development.
-WebIDL ([https://heycam.github.io/webidl/ spec]), or the Web Interface Definition Language, defines the APIs that Firefox exposes to JavaScript content.
-'''Understanding'''
+For DOM the main standards are:
-'''Doing'''
+* [https://dom.spec.whatwg.org/ DOM]
+* [https://html.spec.whatwg.org/ HTML]
+* [https://heycam.github.io/webidl/ IDL]
+You can participate in their development through their corresponding GitHub repository (e.g., watching the entire repository, subscribing to relevant issues, filing new issues, etc.). Feel free to chime in as you please and share your views, but confer with colleagues before expressing opinions on behalf of Mozilla.
+=== Mechanics: Web IDL (WebIDL) ===
+[https://heycam.github.io/webidl/ Web IDL] defines the APIs that Firefox exposes to JavaScript content.
+MDN's [https://developer.mozilla.org/en-US/docs/Mozilla/WebIDL_bindings WebIDL bindings] has detailed information on the setup in Firefox.
 === Mechanics: Testing ===
 There are two broad categories of tests you'll deal with.
 * [http://testthewebforward.org/ Web Platform Tests] are cross-browser tests.  The contents of [https://searchfox.org/mozilla-central/source/testing/web-platform/tests testing/web-platform-tests] are periodically automatically synchronized to/from the github repo at https://github.com/web-platform-tests/wpt.
-* Firefox specific tests.  There are actually a number of
+** How:
+** When to write this kind of test:
+* Firefox specific tests.  Sometimes you may be testing Gecko-specific behavior that is explicitly not part of a standard, you may be testing lower-level details of a system (ex: verifying low-level error codes that are not exposed to content), or you may simply be unable to currently reproduce the necessary test conditions using the mechanisms provided to web platform tests (ex: simulating failure modes or controlling e10s process allocation).  There are a number of test types/frameworks we use:
+** mochitests: The most common type of Gecko-specific test, appropriate when your test does not need to orchestrate complicated e10s behavior (use "browser" tests for that).
+*** How: Your test is an HTML file that loads test-framework support JS and any JS files you author.  It runs in its own tab as a content page but can request that privileged operations happen via the SpecialPowers API that is exposed to your content page so that you can flip preferences or even access privileged XPCOM objects via wrapper magic that grants you (wrapped) system principal access.  Your tab will be in a content process if e10s is enabled or the parent process if e10s is not enabled.  There is a desire to get rid of the non-e10s test variants once Fennec is replaced by an (e10s-capable) GeckoView solution.
+*** Helpers:
+**** [https://searchfox.org/mozilla-central/source/testing/mochitest/BrowserTestUtils/BrowserTestUtils.jsm BrowserTestUtils] provides async e10s-aware helpers to open and close tabs and windows as well, wait for or listen for events, generate events, etc.  This is the first place to look for helpers.
+**** [https://searchfox.org/mozilla-central/source/testing/mochitest/BrowserTestUtils/ContentTask.jsm ContentTask] provides ContentTask.spawn, an e10s-aware mechanism to run a (potentially) async function in a system-privileged frame-script whose "content" variable lets you reach into the page directly via wrapper magic.  If you want to run code in the page's global with its principal, you will want to use "content.eval".
+**** [https://searchfox.org/mozilla-central/source/testing/mochitest/BrowserTestUtils/ContentTaskUtils.jsm ContentTaskUtils] provides helpers to spawned content tasks; methods in there are automatically loaded into the scope uses by ContentTask.spawn.
+** "browser" (chrome) tests: Your test is a JS file that is loaded in the parent process with system principal access.  Convenience mechanisms
+** "chrome" tests: Deprecated pre-"browser" mechanism for when your test needed the system principal and the ability to manipulate the browser.  Ideally you should never write new tests of this type and any changes to existing tests are minimal.  If you need to make extensive changes to a test, consider just re-writing it as a "browser" test.
+** marionette-based tests: Marionette is a Mozilla-specific protocol used for implementing a Firefox Webdriver(/Selenium) so that the browser can be remotely scripted at a high-level in a browser-agnostic fashion so that websites can be tested across browsers without having to write a custom-test for each browser.  We also write various high-level QA tests and tests that require the browser to be restarted or shutdown using this mechanism because this test framework runs outside the browser.  It's also the case that we use marionette to actually do most of the legwork of getting all the other test frameworks to setup their in-browser tests and sometimes help get the results and any errors out.
 == Browser Chrome-Work: Implementing for Privileged Browser UI ==
@@ Line 99: / Line 115: @@
-=== Submitting Code Reviews ===
+=== Submitting A Patch For Review ===
 We use Phabricator for code reviews.  Check out the [https://moz-conduit.readthedocs.io/en/latest/phabricator-user.html user guide].
+=== Landing A Patch ===
 == Doing Code Reviews ==