convert webcompat-reporter to a webextension
Differential Revision: https://phabricator.services.mozilla.com/D6575
--HG--
rename : browser/extensions/webcompat-reporter/skin/lightbulb.svg => browser/extensions/webcompat-reporter/icons/lightbulb.svg
extra : moz-landing-system : lando
Automatic changes by ESLint, except for manual corrections for .xml files.
Differential Revision: https://phabricator.services.mozilla.com/D4439
--HG--
extra : moz-landing-system : lando
This adds the basic framework for defining IPC actors which are lazily
instantiated for the appropriate frame loaders based on DOM events, message
manager messages, and observers. Actual actors are defined in follow-up
commits.
MozReview-Commit-ID: Jb6CWWW7v3v
--HG--
extra : rebase_source : 6c465c492ef423616346d70047c4fd4b074af303
This is also gone from the parent process because previously it was forced to be early loaded by the fact that process-content.js also runs in the parent. Now the parent side is first initialized by the Cu.import from the Activity Stream code, which is later in the startup process
MozReview-Commit-ID: FEypEi0Eemc
--HG--
extra : rebase_source : 6a682dff38370410c91cac44f1f5b2739f0247d1
This inlines and simplifies the call to XPCOMUtils._getFactory,
because otherwise passing PdfStreamConverter appears to resolve it
immediately, loading the JSM. (The stream converter prototype does not
have a property _xpcom_factory, so there's no need for the check.)
Once that is done, we can just lazily load the stream converter JSM to
keep it from being loaded on startup.
This patch also checks that the stream converter is not loaded at
startup in the main process or the content process, and that PdfJs.jsm
is not loaded at startup in the content process. It needs to be loaded
in the main process to watch for some prefs.
MozReview-Commit-ID: EA0pSgs4AWH
--HG--
extra : rebase_source : ebc99d6dc5c00cd45192ec0580f887d8970d9dd0
This inlines and simplifies the call to XPCOMUtils._getFactory,
because otherwise passing PdfStreamConverter appears to resolve it
immediately, loading the JSM. (The stream converter prototype does not
have a property _xpcom_factory, so there's no need for the check.)
Once that is done, we can just lazily load the stream converter JSM to
keep it from being loaded on startup.
This patch also checks that the stream converter is not loaded at
startup in the main process or the content process, and that PdfJs.jsm
is not loaded at startup in the content process. It needs to be loaded
in the main process to watch for some prefs.
MozReview-Commit-ID: EA0pSgs4AWH
--HG--
extra : rebase_source : fd79cf660e55a3b4e033b3f112228f36942169ea
We've improved the startup IO situation in bug 887889 by not synchronously
initializing a connection to the contentprefs db. However, this means
we are loading Sqlite.jsm earlier than we were, which isn't ideal and
can be avoided. However, this isn't completely trivial so I'd like to
move this work to a follow-up.
MozReview-Commit-ID: 6Em0rN26Qj3
--HG--
extra : rebase_source : 8f66552ce809b15df51fff28d08f9f84e83f557d
The current shutdown handling code is susceptible to deadlocks, since it spins
the event loop while it holds mMonitor, and other main thread methods which
try to acquire mMonitor can be called from code that runs while the event loop
is spinning.
My initial solution was just to release mMonitor before spinning the event
loop, but at this point I think it makes more sense to switch to the
standardized AsyncShutdown routines, which provide better diagnostics and
allow us to avoid one more nested event loop during shutdown.
MozReview-Commit-ID: 1RtFN585IR7
--HG--
extra : rebase_source : 978f3bf7cef73e56b3e1c1c838c2bc6efcefb0c0
extra : amend_source : 2b7c9422004b58ad1d38d7dd705ad446bc47cb23
extra : histedit_source : 7a4e80de7d5aa48e074ea03821bb78e5e287842e%2C92c1119a131adaa33f5691c0e534bb243115817b
This patch enables startupRecorder.js to collect data on
loaded and shown raster and SVG images on startup via events
from native code. It also adds a test that uses this data
to find images that are unnecessarily loaded.
I've not fixed any of the affected images yet, there's a
fairly comprehensive whitelist that I want to gradually
decrease by opening bugs in the respective components.
MozReview-Commit-ID: 9KqQvKLtZhu
--HG--
extra : rebase_source : 5f75fcd1152f569a5b48e21d4e4821a24f768ecd
This patch enables startupRecorder.js to collect data on
loaded and shown raster and SVG images on startup via events
from native code. It also adds a test that uses this data
to find images that are unnecessarily loaded.
I've not fixed any of the affected images yet, there's a
fairly comprehensive whitelist that I want to gradually
decrease by opening bugs in the respective components.
MozReview-Commit-ID: 9KqQvKLtZhu
--HG--
extra : rebase_source : 856f06320c78ed88c4578fce985b2a526566e825
This patch enables startupRecorder.js to collect data on
loaded and shown raster and SVG images on startup via events
from native code. It also adds a test that uses this data
to find images that are unnecessarily loaded.
I've not fixed any of the affected images yet, there's a
fairly comprehensive whitelist that I want to gradually
decrease by opening bugs in the respective components.
MozReview-Commit-ID: 9KqQvKLtZhu
--HG--
extra : rebase_source : 345066e07855bc49975393ec401553981e1138b3