DOM/Engineering: Difference between revisions

DOM/Engineering (view source)

Revision as of 20:41, 4 August 2018

2,769 bytes added , 4 August 2018

m

some details on xpcom and webidl

Andrew Sutherland

Confirmed users

360

edits

@@ Line 33: / Line 33: @@
 * Remember to [https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Using_Icecream#Building update your configuration] so that "make" knows how many jobs to spawn in parallel!
-== Spec-Work ==
+== Spec-Work: Implementing for Content ==
 === Communication: Participate in Spec Development ===
@@ Line 51: / Line 51: @@
 * [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
+== Browser Chrome-Work: Implementing for Privileged Browser UI ==
+"Browser chrome" is the browser UI.  (This is the etymology of Google's "Chrome" browser, which will forever require you to make clarifications whenever you say the word "chrome".)
+=== XPConnect versus WebIDL ===
+Some inaccurate but workable definitions:
+* XPIDL ".idl" files in the tree define XPCOM interfaces.  These interfaces define methods, constants, and getters and setters, as well as meta-data about them.  These are conceptually language agnostic but in practice you'll see a lot of C++-specific details included in the files.
+* XPCOM covers both a bunch of important system glue code as well as the mechanics that make the interfaces and their language-specific calling conventions work.
+* XPConnect is a binding layer implemented in C++ that allows JavaScript to interact with XPCOM.  JS doesn't have the low level ability to do this on its own.  XPConnect is single-threaded and only available on the main thread of each process.  Any JS code running on other threads is either running in a privileged [https://developer.mozilla.org/en-US/docs/Web/API/ChromeWorker ChromeWorker] or regular DOM [https://developer.mozilla.org/en-US/docs/Web/API/Worker Worker], [https://developer.mozilla.org/en-US/docs/Web/API/SharedWorker SharedWorker], [https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API ServiceWorker], or [https://developer.mozilla.org/en-US/docs/Web/API/Worklet Worklet].
+* Firefox's WebIDL bindings are a high-performance binding layer created to expose APIs to web page content with low overhead.  They trade increased code size for speed.  XPConnect dynamically interprets memory-mapped type definitions every time calls are made which is slower but avoids bloating Firefox's on-disk or in-memory size (because the type definitions are more compact than the comparable machine code used by WebIDL).
+As covered above, we have a mechanism to expose WebIDL only to system-privileged contexts by marking WebIDL interfaces or methods [https://developer.mozilla.org/en-US/docs/Mozilla/WebIDL_bindings#Exposed Exposed=System].  This raises the question of when you should use XPIDL/XPCOM and when you should use WebIDL for APIs that are only exposed to privilege execution.
+* The shortest answer is that you should use XPConnect unless your API is going to be called so frequently from system-privileged JS code that you are certain the XPConnect overhead would show up in a profile.  Or, better, you already tried XPCOM and it did show in profiles.
+* If the API needs to be exposed to C++ and/or Rust in addition to JS, you should consider XPCOM anyways because the WebIDL bindings are designed for consumption by JS, not C++ and Rust code.
 == Bugs ==