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
By default Eclipse CDT will scan the source tree for binaries so that it can
add those binaries to the list of things that it can run. This scanning is a
constant interuption and can last several seconds. Besides that, it's
currently useless for our setup since the only binaries that we're interested
in running are in the object directory (which it doesn't scan), and those are
set up during project generation. (The only binaries found in the source tree
are a couple of uninteresting bundled libraries.)
CLOSED TREE
MozReview-Commit-ID: 2WaH8qceALq
By default, scalability mode is activated for files with 5,000 lines or more.
There are quite a few C++ files with more than 5,000 lines, and Eclipse seems
to work fine with them with scalability mode turned off (even
nsCSSFrameConstructor.cpp which is over 13,000 lines long). Increasing the
number of lines before scalability mode is enabled allows Eclipse to handle
these files better.
MozReview-Commit-ID: 8mGYIHStHes
Without this setting, eclipse will refuse to open Objective-C files (it will
defer to an external editor). Adding *.mm to the file types that are treated
as C++ allows Eclipse to open them, and to provide some code assistance for
the bits of the files that it can understand.
MozReview-Commit-ID: ASeXesWxY4g
This setting allows Eclipse to notice when files it has open are changed
externally (such as by hg/git, for example). It can then update the contents
that it has for the open files, avoiding annoying issues such as saving changes
after an `hg pull -u` resulting in either "Resource is out of sync" errors or
else clobbering of the changes hg made to files.
MozReview-Commit-ID: 8WmewM7lbHe
The blocking Welcome screen is quite confusing for a new user. It is not clear
where to find the Mozilla stuff they expect to see when opening Eclipse, or
that the user needs to close the entire content area to get to it. Besides that
the screen isn't very useful for Mozilla people who will find more relevant
help from searching the online documentation, and who won't be creating new
projects in the generated workspace, etc.
MozReview-Commit-ID: 8YssnonAR1d
The setting to ensure that there is a newline at the end of files when they
are saved is very annoying. Besides adding unnecessary and unexpected cruft
to diffs, some parts of the codebase (some of the reftest directories for
example) have a policy of NOT having a newline at the end of their files.
MozReview-Commit-ID: IjIYxDsKS13
This makes us write the code formatter settings into the workspace settings
directory instead of the project settings directory. This is preferable
since when users make settings changes they are more likely to work with the
workspace settings, so we should put them there. Putting them there also
fixes a bug whereby the calls to _write_noindex/_remove_noindex would
overwrite the formatter settings file shortly after it had been created.
To get the formatter to show up in the UI we also need to set the formatter
settings as a one line pref value in the CDT UI settings. This duplication
is what Eclipse does when a new formatter is manually added, and it's
necessary to get the formatter working correctly.
MozReview-Commit-ID: KP4w0VbNCF7
