In cases where data transfer finishes immediately after we close a request, we
can sometimes wind up overwriting that state information with
"finishedtransferringdata", which allows scripted callers to break certain
invariants and cause crashes.
MozReview-Commit-ID: Do3GttF3M9S
It currently isn't possible to suspend a channel from onHeadersReceived for a
cached response. And since it's not possible to add a new stream filter after
a response has started, adding a stream filter at that point will crash if the
channel is still registered.
This test is a basic sanity check for that scenario.
MozReview-Commit-ID: ALYUtxX7mci
Our current StreamFilter code doesn't behave well when data delivery is
targeted to a thread pool, rather than a single thread.
Thread pools don't guarantee ordered processing of events. It's theoretically
always possible for multiple events dispatched to a pool to be processed in
parallel, or even slightly out of order.
For the most part, this should only be a theoretical concern, unless several
data events are dispatched at the same time, and the pool has enough available
threads to service all of them (which is an unlikely scenario in this code).
However, when data delivery is targeted to a thread pool, the OnDataAvailable
callbacks do not have access to the thread pool itself, only the thread that
the callback was dispatched to. This means that after each OnDataAvailable
call, we likely store a new IO thread, and writes end up queued to a different
single thread depending on exactly when they happen.
Threads in thread pools often wind up executing long-running runnables, such
as synchronous IO or network operations. Which means that we introduce
arbitrary delays for some writes, and are likely to wind up with highly
arbitrary ordering.
This patch solves both of these problems by introducing strict event queue
ordering, and also dispatching IO events to the original explicit delivery
target, rather than whatever the current thread happened to be at the time of
the last data event.
MozReview-Commit-ID: 1SdYjS6ltqw
This patch changes the behavior of the downloads.download API's saveAs option. Previously, the behavior when neither value is provided (the "default behavior") was not defined by our documentation or Chrome's. Now, the default behavior is changing to rely on the Firefox "Save As" pref (browser.download.useDownloadDir). If Firefox is configured to open the "Save As" dialog for all downloads (browser.download.useDownloadDir == false), that behavior will be the default for the downloads.download API. Otherwise, the default behavior will be not to show the dialog.
This patch also moves some test functionality out of test_chrome_ext_downloads_saveAs.html. Previously, that test would test the saveAs option and also the conflictAction:"uniquify" option. In order to add testing for the new default behavior, it was necessary to move the testing of the conflictAction:"uniquify" option to a new test: test_chrome_ext_downloads_uniquify.html
MozReview-Commit-ID: u6VA4kexlr
Prior to this, if getLevelOfControl was called before the setting was defined to the EPM, an
exception was thrown. This fixes it by returning a level of control of "not_controllable"
if the setting has not yet been defined.
MozReview-Commit-ID: 96jXLoJlUI
This avoids a lot of mismatches between nsAString and char16_t*, thus removing
many getter_Copies() and ToNewUnicode() and get() calls, and generally making
things simpler.
Note: the patch removes GetDefaultPrinterNameFromGlobalPrinters() by simply
inlining it at its two callsites, which is easy with the changed types.
Sending MessageManager messages is expensive, but a lot of the overhead is
per-message more than it's tied to the complexity of the message. In
particular:
- Each sendAsyncMessage call incurs separate XPConnect method call overhead.
- Each message requires acquiring a lock, and separate message setup overhead
for IPC.
- The message data itself must be structured cloned, which requires
(expensive) allocation of buffers to hold the serialized data. Each buffer
segment is 4KB, which is generally enough to hold multiple serialized
messages, so coalescing messages means fewer buffer allocations.
Moving some of this work into idle slices also means less likelihood of
interfering with UI responsiveness.
MozReview-Commit-ID: 5SAMZNLVaY3
This task assigns new GUIDs to items with missing or invalid ones, and
bumps the Sync change counter for the affected items and their parents.
We also invalidate the GUID cache for the affected items, and write
tombstones for invalid GUIDs that have already been synced.
MozReview-Commit-ID: 7Jm3enYchAz
There are currently some corner cases where channels that are eventually
loaded into documents (mainly <img src="data:image/svg+xml,") can inherit
expanded principals from a caller. Since documents aren't allowed to have
expanded principals, this causes crashes.
This patch is a short term workaround for the issue, until we have a longer
term solution that prevents the channels from inheriting the expanded
principals to begin with.
MozReview-Commit-ID: JwqqtVynLjj
- Send a ping when user type in "Home page" box.
- String is longer than 4 letters and with at least one ".".
- String is not deleted after 3 seconds.
- Send a ping when "Use Current Page" is clicked.
- Send a ping when "Use Bookmark" is clicked.
- Send the number of "|" is detected in "Home page" box.
MozReview-Commit-ID: 6bYK0eCkYym
This adds a new sync function to AttributionCode.jsm that returns the cached
attribution data. The cached data is then used to populate the environment
instead of relying on the async function.
MozReview-Commit-ID: F0se7kXspo2
