This adds two properties to the Tab object:
- isArticle indicates whether the document in the tab is likely able to be
rendered in reader mode.
- isInReaderMode indicates if the document in the tab is being rendered in
reader mode.
It also adds a toggleReaderMode() which toggles a tab into and out of reader mode.
There is also a new case in which tabs.onUpdated will fire. When the isArticle
status of a tab changes, an onUpdated event will fire with data {isArticle: boolean}.
MozReview-Commit-ID: AaAQ0V5qm2Z
--HG--
extra : rebase_source : f9cbed6dff56781ecd86281cb46f23f0ec8aecf6
Currently tabs.onActivated (for the tab that becomes active after a tab is removed) fires before
tabs.onRemoved (for the tab that was removed). This is neither the order in which Chrome fires
these events, nor is it the order in which the internal TabSelect and TabClose happen in Firefox.
This bug fixes this so tabs.onActivated fires *after* tabs.onRemoved.
Note that this does introduce an issue in in-process mode, where window.close() will not
trigger a tabs.onRemoved event for the window, but Kris says "Meh" about that.
MozReview-Commit-ID: CrFR3jqL2u5
--HG--
extra : rebase_source : 5cc3d2a138bf812d13779e8ca1188b89ddbcdcc1
The current timeout was added to deal with some shutdown deadlocks that were
happining in the wild, but were hard to reproduce locally and therefore
diagnose. It's not clear whether the bulk of those have been fixed, so I'm
reluctant to remove the timeout entirely.
But the current 1s timeout is quite short, and doesn't allow for proper
cleanup in a lot of legitimate cases. The async shutdown service starts to
emit warnings at 10s, so 8s gives us enough time to avoid at least that.
MozReview-Commit-ID: 94zZjYUY8qZ
--HG--
extra : rebase_source : 980cce2af1117d6d46f6083910672e3ef8702981
extra : histedit_source : d8d9b2d7f6312b5d8801e4e26d2b0c0a32a538c2
The main change here is to disconnect stream filters immediately if we try to
send start or data events to a window that's already been destroyed.
It also fixes a race where we end up in the wrong state if a stop event
arrives while the channel is being disconnected.
MozReview-Commit-ID: LwxXxoRUDgQ
--HG--
extra : rebase_source : 8c04e4be2f74850f28d642350b9ff268ab3206e4
extra : histedit_source : d0c18c9a190179431b81fdb32262a0324dc35762
If we don't do this explicitly, the channel is automatically disconnected when
it's GCed. However, if we start shutdown while a stream is being processed,
the stream may not be GCed before we shut down the parent process's message
loop. In that case, we get a shutdown crash because the StreamFilterParent's
data channel is still open when we shut down its message loop.
Explicitly disconnecting the StreamFilter when the context is closed prevents
this, since app shutdown is automatically blocked on extension shutdown, and
extension shutdown explicitly closes all extant contexts.
MozReview-Commit-ID: 5JPrSUooq1j
--HG--
extra : rebase_source : d9af8c6b1c2107a726fead2aa0bbf9cc6f7b72e2
Normally, we try to use the same thread for the IO and actor threads, which
means there's some basic assurance that OnStopRequest is always dispatched
after the last OnDataAvailable call. However, in cases where callers retarget
data delivery to a different background thread, it's possible for the main
thread to process the OnStopRequest runnable before the IO thread has
processed the last OnDataAvailable runnable, which can cause problems.
Dispatching the OnStop runnable through the IO thread guarantees at last basic
consistency in order of dispatch. In the case where the IO thread is the same
as the actor thread, the runnable is processed synchronously, and there's no
behavior change. In other cases, it's dispatched to the IO thread first, and
waits in the same queue as the already-dispatched OnDataAvailable events.
MozReview-Commit-ID: H2GD66WKxNn
--HG--
extra : rebase_source : 0c79d3467b92e9fe53842a642a5c1eac2f3ee54c
We currently call has() every time we do a DefaultMap/DefaultWeakMap lookup,
which unfortunately shows up a lot in profiles. We only actually need to
check, though, if get() returns an undefined value.
Similar things in other places, where we only need to do a has() call if
another operation fails.
MozReview-Commit-ID: 9qFWsb4vlZj
--HG--
extra : rebase_source : 94c231fa007744f733faa9fdbde38a3875e10e7d
Aside from moving this logic closer to the place the input data is generated,
this significantly reduces the number of cross-compartment wrappers involved
in creating those messages, especially with JSM global sharing enabled.
MozReview-Commit-ID: 6IvetcHnMfC
--HG--
extra : rebase_source : 0f97464ee9840ac40a6882e70e99d5b6c566c5ef
This adds a browserSetting.imageAnimationBehavior API which accepts one of three
values: "normal", "none", "once". Behind the scenes it sets the image.animation_mode
preference to the same value.
MozReview-Commit-ID: GLT6oJgpF3
--HG--
extra : rebase_source : 2ff27f7667556f0294959b1130df17c839734dbd
With JSM global sharing, the object returned by Cu.import() is a
NonSyntacticVariablesObject, rather than a global. Various code tries
to use properties from a JSM global via an import.
Cu.importGlobalProperties can also be used in some places.
MozReview-Commit-ID: HudCXO2GKN0
--HG--
extra : rebase_source : 6b5fa6f5509397504cb461a761f6cc2399f18c40
This adds a browserSetting.imageAnimationBehavior API which accepts one of three
values: "normal", "none", "once". Behind the scenes it sets the image.animation_mode
preference to the same value.
MozReview-Commit-ID: GLT6oJgpF3
--HG--
extra : rebase_source : e1675bf4042e7e5fcee768231ffeccf19dc77c69
This updates the browserSettings API to report the current value of the home page and the new tab page regardless of whether they are currently overridden by an extension.
MozReview-Commit-ID: 3usY3F4oIxl
--HG--
extra : rebase_source : f8a04b4d7e70db7133c664d60cd46f8b4cd5471f
Ehsan, can you please review the (trivial) WebIDL changes, and Shane the
WebRequest logic?
The change to allow strings in MatchPattern arguments removes a huge amount of
XPConnect overhead that accumulates when creating nsIURI objects for
WebRequest processing.
The change to re-use existing URI objects removes a huge amount of URI
creation overhead.
MozReview-Commit-ID: 3DJjAKJK1Sa
--HG--
extra : rebase_source : 585a1c3c136ed1c5014f680ae81f635c8d1a2931
Ehsan, can you please review the DOM bindings, and Shane the request logic?
The bulk of the overhead WebRequest API is in its access to nsIChannel and
friends through XPConnect. Since it's not really feasible to convert channels
to use WebIDL bindings directly, this generic channel wrapper class serves the
same purpose.
MozReview-Commit-ID: 4mNP8HiKWK
--HG--
extra : rebase_source : 111687dd0925619b5d93447aecffacd5d53532ef
This introduces an implementation of the clipboard.setImageData API.
I did not find any complete documentation about how copying and
pasting images is supposed to work in Firefox, so I added many lines
of documentation based on experimenting and reading the source code.
The implementation is very similar to the Add-on SDK's implementation,
save for one difference: The third parameter to setTransferData is 0
instead of -1. Its significance is elaborated in ext-clipboard.js.
The newly added tests serve the following purposes:
- Verification that clipboard.setImageData is working as expected.
There is no way to test that pasting in an external application
really works, so we just check whether Firefox recognizes the
special image data by pasting in a contentEditable area.
- Test coverage for reading clipboard data via the "paste" event and
using event.clipboardData to access the pasted data, because this is
the only way to read non-text data in a WebExtension extension.
MozReview-Commit-ID: Ldrx7LCIta2
--HG--
extra : rebase_source : f76fe85e5c9a525c159255c29698f4bdbdede8bc
The extension policy services uses atoms internally for permission names, so
using them directly rather than strings is considerably cheaper.
MozReview-Commit-ID: Io8EuOXHKVy
--HG--
extra : rebase_source : 577b4bdf7f899729e4cf92961a8e9e25bf886a72
Going through the extension policy service rather than using
WebExtensionPolicy objects directly adds a lot of unnecessary overhead to
common operations on extension principals, and also makes the code more
complicated than it needs to be.
We also use weak references to policy objects here, since principals should
ideally lose as much of their elevated privileges as possible once the
extension instance that created them has been destroyed (which is something we
couldn't handle easily when we simply tracked ID strings).
MozReview-Commit-ID: KDNvVdvLkIt
--HG--
extra : rebase_source : 1b567919d2461bd0315d1a7d89f330cbd585f579
Also adds a mozilla/ResultExtensions.h header to define the appropriate
conversion functions for nsresult and PRResult. This is in a separate header
since those types are not available in Spidermonkey, and this is the pattern
other *Extensions.h headers follow.
Also removes equivalent NS_TRY macros and WrapNSResult inlines that served the
same purpose in existing code, and are no longer necessary.
MozReview-Commit-ID: A85PCAeyWhx
--HG--
extra : rebase_source : a5988ff770888f901dd0798e7717bcf6254460cd
This allows MOZ_TRY and MOZ_TRY_VAR to be transparently used in XPCOM methods
when compatible Result types are used.
Also removes a compatibility macro in SimpleChannel.cpp, and an identical
specialization in AddonManagerStartup, which are no longer necessary after
this change.
MozReview-Commit-ID: 94iNrPDJEnN
--HG--
extra : rebase_source : 24ad4a54cbd170eb04ded21794530e56b1dfbd82
This introduces browser.browserSettings.homepageOverride and browser.browserSettings.newTabPageOverride
which will return the values of the overridden home page and the overridden new tab page.
These browserSettings are read-only.
MozReview-Commit-ID: A9vJP2QIaoA
--HG--
rename : browser/components/extensions/test/browser/browser_ext_url_overrides_home.js => browser/components/extensions/test/browser/browser_ext_chrome_settings_overrides_home.js
extra : rebase_source : 7c3fc91a5ca489b909a8b60d5b4a882180a0276e
When we implemented this API we converted dashes in the language code to underscores because that is what Chrome did.
Chrome no longer does this, so we need to remove the code that does the replacing.
MozReview-Commit-ID: DuOQ218zXby
--HG--
extra : rebase_source : 7a6727d83bc1959569bd3e4ac47db6911d6cf13d
With the removal of the old addonHistograms, all histograms are now registered.
So removing registered(Keyed)Histograms should be straightforward?
Unfortunately not, as this was how we filtered data based on dataset
(opt-in/opt-out), so a little more fiddling was needed to get C++ to only
serialize dataset-appropriate data (instead of post-facto filtering it in JS).
MozReview-Commit-ID: HDplhmzmzJl
--HG--
extra : rebase_source : 9c38c97e39e3c4fb192288d751505e1f0f2a2c6d
This part hooks up the parent side of the StreamListener protocol to the
channel, and implements the event handling and actual IO work.
Dragana, can you please review the network portions, particularly the thread
sanity, and Shane, the integration with the rest of the patch set?
MozReview-Commit-ID: DFuALpSSgA7
--HG--
extra : rebase_source : 14a42ae82dcec171a8a2ec771b0ebaccf7a8a649
This part implements the IPC state logic for the stream filters.
Bill, can you please review the IPC and thread sanity, and Shane, the state
logic?
MozReview-Commit-ID: KrVOrdnuwC5
--HG--
extra : rebase_source : d83f89a92ca858792ab378615ca9e6d70b1ab965
This interface will allow extensions running into a content process to attach
a filtering stream listener to an HTTP request in the parent process. The
content process attaches a listener by sending a message from the content
process containing the ID of the request to filter, and the ID of the add-on
making the request. The permissions and request mappings for this are handled
by the web request service added in part 2.
MozReview-Commit-ID: B7Dd3ywwCBX
--HG--
extra : rebase_source : bf67c87f03c8355109bcc1193fbcb0b1c70ef224
In order to allow extensions running in a content process to connect extension
filters, we need to be able to track which requests they have permissions to
modify, and which processes they have permissions to modify them from.
This interface allows us to register channels that we've dispatched webRequest
listeners for, and the TabParent (and, by proxy, content parent) we've
dispatched them to. Extensions will only be able to filter those channels, and
only from those processes.
MozReview-Commit-ID: 46HTVeQ5ndi
--HG--
extra : rebase_source : aadfadef3b72044302b3f4e6c88a5a06ff138c84
Change webextensions experiments test to use the shimmed certficiate DB
instead of the extensions.legacy.enabled pref.
In builds that don't honor the extensions.legacy.enabled pref, disable
test_legacy.js since that tests that flipping that preference works properly.
Finally, remove a now doubly-obsolete test of plugins embedded in xpis.
MozReview-Commit-ID: JiRdgCXyjKR
--HG--
extra : rebase_source : f0c7672b0755993bd20f9fc84e242eb76cb949ef
Provides access to the browser's internal Find APIs. Can search,
get range data and rect data on found results, and highlight results.
--HG--
extra : amend_source : dfa2b36794543378db58e411ca4e317a64921831
The base Extension class now handles adding shutdown blockers and waiting for
extension startup before beginning shutdown, so the redundant logic only
causes problems.
MozReview-Commit-ID: 2gBWlmIs1KQ
--HG--
extra : rebase_source : 404174754735b8477abf6f13d312bc6b3aebdb83
This may or may not fix the intermittent, but hopefully it will.
MozReview-Commit-ID: BR0BtV4BPdq
--HG--
extra : rebase_source : 017933bd5f53e1e3ea6c082e2240519b25168255
Like part a, but for `choices` messages rather than error messages.
MozReview-Commit-ID: 7dJ0NL2fUh5
--HG--
extra : rebase_source : 477f1364c0904bde78d54eae083bdb8e49ee5732
extra : histedit_source : 38c336b3a59481b6f2523798367159fb757c6485
For choices types, when one choice fails, we don't need the original error
string, since another choice may succeed, and we generate the final error
based on all of the options. Nevertheless, we spend a lot of time generating
JSON strings for the failed inputs in those cases, which adds up to about 12%
of the remaining overhead at this point.
MozReview-Commit-ID: 6nXBAv2W20V
--HG--
extra : rebase_source : 5894bc4b9e8d64ac9505f27240ea4fabfcb5f02f
extra : histedit_source : 0e8b5e0315abd672a57a60420453a1e0681c9df6
The Array and ArrayBuffer type checks we do in getBaseType add up to a
significant amount of overhead given the number of times we call them,
especially when X-ray overhead comes into play. These changes allow us to
avoid X-ray overhead altogether.
MozReview-Commit-ID: KlRuxeElIfp
--HG--
extra : rebase_source : c7f00fb8c35965476e7c7b888b6af36714c1323f
extra : histedit_source : fc559e665e60e9bbb688eebe6c6e6da5dacec748
The FrameLoaderOwner interface has been implemented in WebIDL for several
years now, so these QIs are simply unnecessary overhead.
MozReview-Commit-ID: LAzvfm5Qhy0
--HG--
extra : rebase_source : 2495c07df21c474f5fabc257ff4db43b0d8047e4
The existing functions work with C strings but almost all the call sites use
Mozilla strings.
The replacement function has the following properties.
- It works with Mozilla strings, which makes it much simpler and also improves
the call sites.
- It appends to the destination string because that's what a lot of the call
sites need. For those that don't, we can just append to an empty string.
- It is declared outside the |extern "C"| section because there is no need for
it to be in that section.
Note: there is no 16-bit variant of nsAppendEscapedHTML(). This is because
there are only two places that need 16-bit variants, both rarely executed,
and so converting to and from 8-bit is good enough.
The patch also adds some testing of the new function, renaming
TestEscapeURL.cpp as TestEscape.cpp in the process, because that file is now
testing other kinds of escaping.
--HG--
rename : xpcom/tests/gtest/TestEscapeURL.cpp => xpcom/tests/gtest/TestEscape.cpp
extra : rebase_source : 51145ae2c9b0b4573c7ea0c342dcb246f9f14fb9
It turns out that stringifying a paths object is much cheaper than normalizing
it, and has the added benefit of allowing us to use cached CSS text for the
result.
MozReview-Commit-ID: 5gIqcDmPiKr
--HG--
extra : rebase_source : 59f6a75eac976abb85fe37440469e589282f7b01
We already do this check at the schema level, so the added check in
IconDetails is unnecessary.
MozReview-Commit-ID: JTEE0xWH0a4
--HG--
extra : rebase_source : baad0a75438cdf126e0ba8df4055be50f3281d2a
Lots of little bits of overhead add up to a significant amount of overhead
over the many, many times this function is called.
MozReview-Commit-ID: BYTWxqc8rH9
--HG--
extra : rebase_source : 3b22f9ca1de504a383eef5760e43dc783c2b3b93
There is no longer any file in components/extensions/ext-* that use require().
Therefore it should be ok to stop exposing it.
MozReview-Commit-ID: EgZYBludlcy
--HG--
extra : source : 50a36fb7c7f97682ea9d2651b0edec306d466b5c
extra : amend_source : af2184bbf188df138b3a2b23d7031b2de5534e25
There is no longer any file in components/extensions/ext-* that use require().
Therefore it should be ok to stop exposing it.
MozReview-Commit-ID: EgZYBludlcy
--HG--
extra : rebase_source : f83d8bf4bb413c246efe3c25767cc203f127423e
checkLoadURIStrWithPrincipal runs URLs through the URI fixup services and
checks against each of the results. This is both expensive and unnecessary for
our purposes.
MozReview-Commit-ID: 4L2Z4KuMZhQ
--HG--
extra : rebase_source : 9b72c8e4c6b0a48541b94871f507ce029be664c7
extra : amend_source : d20b032a6ddf9b9804a14e528094bc6867d5b728
Web contetnt processes only need access to a small amount of schema data, but
we currently send them the approximately 600K of full schema data that is
mostly useless to them.
This patch limits the schema data sent to web content processes to what they
actually need, and sends the rest only to extension content processes.
MozReview-Commit-ID: 6G0LThNTOu1
--HG--
extra : rebase_source : 36672ad6323e6466bba3e463fa4f0a16e3fd9090
These getters are checked very rarely, and not at all in most sessions. They
don't justify the overhead of adding lazy getters at startup.
MozReview-Commit-ID: 9XVlLapNJCE
--HG--
extra : rebase_source : edff8e878528952aeec851203edaa4d41e37e24d
We always load one when we load the other, so there's no need for the overhead
of a separate JSM.
MozReview-Commit-ID: 8u4OhJJEN3b
--HG--
extra : rebase_source : f2c7afc7aba3b86af8be0345ad8f596c31adc206
This performs main thread IO to make sure that directories exist, which is not
something we should be doing on the startup path.
MozReview-Commit-ID: 2NrgRgY5ua6
--HG--
extra : rebase_source : beded8238f62ab9134748ac5a96b95b0826fa74b
Modify test_ext_experiments.js to use a non-lowercase id and name to catch a future regression
MozReview-Commit-ID: BRy2XNOtBXO
--HG--
extra : rebase_source : 12d5037626e7360e673cf05019db3588ddb1b492
This moves it to the same compartment as the code that it interfaces with the
most often, and allows for much more effective JIT optimizations.
MozReview-Commit-ID: FZcogI4d4rv
--HG--
rename : toolkit/components/extensions/ExtensionTabs.jsm => toolkit/components/extensions/ext-tabs-base.js
extra : rebase_source : 9928f7e36e4d65401ebb420dddfbcfcdbb11226f
The combination of "match_about_blank": true and "run_at": "document_start"
can potentially cause content scripts to run twice for the same document, once
for the intermediate about:blank document created by the document.open() call,
and again for the same document with its final URL after it's been fully
setup.
This test ensures that that behavior doesn't regress.
MozReview-Commit-ID: 9XSfW3rEL4f
--HG--
extra : rebase_source : e206bccd8fad648ebb152418c8784b0a4739fcab
This is also the first step in moving async startup/shutdown tracking into the
add-on manager.
MozReview-Commit-ID: Uf4ecSW77S
--HG--
extra : rebase_source : 16029f3c84feec4b98b23b3beabf763978a6b60d
extra : histedit_source : a7478fd19ebd6fa827856f299ebb824f29db5575
This will modify the "dom.popup_allowed_events" preference to control whether events from
user actions are allowed to open pop-up windows or not. If set to `false` then pop-ups from
user actions will not be allowed and will result in a doorhanger being displayed informing
the user that a pop-up was blocked. If set to `true` then all of the default events
will be allowed to open pop-up windows.
MozReview-Commit-ID: 8UFziq23zug
--HG--
extra : rebase_source : 01fce52f35aa1ce5af14e5f883214f4dcd5261ce
