Fixes problem with the initial computed value of font-family
being empty and not matching the later value in
test_value_storage.html.
MozReview-Commit-ID: HOHvMZPP1GD
Many tests rely on the minimum size of widgets to
be set. Also, the precise size seems to matter for some
tests that have hard coded offsets.
MozReview-Commit-ID: BglZD1cKdY9
This better emulates a window manager and triggers the
required activated/deactivated events on the proper windows as
they are closed or hidden.
MozReview-Commit-ID: 1A2JTp8i4VE
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
--HG--
extra : rebase_source : 22ef41b1655641fb5f73034d076f3bb6e148a626
extra : absorb_source : 5ca805e93d4d5feed9a5bd7e7f292104cd1bdd11
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
--HG--
extra : rebase_source : 120889fd8f9edd097a7dae807b54eb3fd283f0f6
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
--HG--
extra : rebase_source : a92aeff88b21ad41f2eef71a732fdf60f447789a
After data delivery for a request has been retargeted, there's no reliable way
to get the appropriate event target to re-dispatch data events after
asynchronous processing.
While it's technically possible to retrieve the current thread from
OnDataAvailable callbacks and re-use that for later dispatch, that approach
has some issues:
1) It's not currently possible to reliably map the current thread to the
thread pool that owns it. That means that if data delivery is being targetted
to a thread pool, attempts to redispatch events to the previous delivery
thread might lead to long delays when one thread in a pool is blocked.
2) If a filter wishes to dispatch data events to the wrapped listeners before
it's recieved any data (as extensions StreamFilters sometimes do), there's no
way to determine the proper event target without waiting for initial data to
be received.
Simply returning the correct event target from the request solves both of
these problems.
MozReview-Commit-ID: CJxq7O4399R
--HG--
extra : rebase_source : db2f659ecad16daafdbcc108d7b1a51ea1af31f9
