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
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
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
Currently if there is no default icon at the specified size, the default icon
falls back to the light text icon at that size. This is wrong in two ways:
First, the default theme uses dark text, so it should fallback to the dark icon
Secondly, authors expect the unsized default_icon to be used if specified
This patch fixes both of these issues, so that the default icon first falls back
to the unsized default_icon, and then only if that is not specified falls back
to the dark icon
MozReview-Commit-ID: C3RRTKhYq6r
(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
Webextension-formatted langpacks now store their list of chrome
registry resources in startupData so that those resources can be
registered early in startup.
MozReview-Commit-ID: 80eOiPKLlWu
