This sets verbose=True (used by the mach formatter) and compact=False (used by tbplformatter) if
only a single test is specified with either |mach test| or |mach mochitest|.
This way all TEST_STATUS and log lines will be visible when developers are writing a new test.
MozReview-Commit-ID: 2nuKs9DLnx0
--HG--
extra : rebase_source : 1fc594b465a2a94dfcd85d56d042969af47f6f65
This consolidates the printing of status logs, which was previously handled
differently in 3-4 places. This also fixes a few of the annoyances listed in
the bug 1445624 description. Finally this also fixes a few edge cases that I
noticed when writing the tests.
MozReview-Commit-ID: APudT8yBqVS
--HG--
extra : rebase_source : 943a71c762dd27a7f7ebea86d467e81a0b27d400
extra : source : 61ba86fc1366a62a429a7daab7d6b1c198c69593
This adds a basic test for the mach formatter. This will ensure that changes to
this format are intentional. It will also make it easier for reviewers of these
changes to see a diff of the old vs new format.
MozReview-Commit-ID: LBSfdyvOPVV
--HG--
extra : rebase_source : 5529ad1f03306dcf867d88af579b69d6005091c0
For the sake of coherence with the rest of FirefoxDataProvider interface, to avoid future bugs like the one this commit refers to.
MozReview-Commit-ID: EX8JQvoIeTb
--HG--
extra : rebase_source : e398cf76137bc5009ed1614a9cc97d0c4edfa67f
With bug 1444489, there is no longer a need to load the full xul.css into HTML
documents. This patch remove that ability and keep it as an assertion.
MozReview-Commit-ID: ChBdRts6PFX
--HG--
extra : rebase_source : b6b35af4c66d8a097f8b4787305bba2e948de554
For bug 1438688, I need to statically initialize all of the data types
in xpt_struct.h. It turns out that the approach I was using for unions
is C99 and not C++. While for some reason Clang and GCC are okay with
that, MSVC is not.
One of the unions is a gnarly anonymous union in
XPTTypeDescriptor. However, every arm of this union is either 1 or 2
uint8_t, so I think it is reasonable to eliminate the union and
replace it with two fields, mData1 and mData2. I've fixed up the
places that read this data to use accessor methods with nice asserts
about the tag on the variant, so if anything I think that part is
nicer.
The code in xpt_struct.cpp that writes to this data is maybe less
nice, but I'm deleting it in bug 1438688 so I think that's okay. We
also lose some detail in the comments about the relationship between
what is stored in memory compared to what is stored on disk, but I
think that's okay, too.
MozReview-Commit-ID: DGi19f8HnMi
--HG--
extra : rebase_source : e3535ecb3d7f02bdb643df153e8aba3e106d9104
* Removes mSpecEncoding since the spec is always ASCII encoded
* nsStandardURL::InitGlobalObjects is now called from nsNetStartup
* Removes prefObserver from nsStandardURL
* mDisplayHost is now initialized every time that we change the hostname
* Adds locking to the gAllURLs list
MozReview-Commit-ID: 93mwECxYxWl
* * *
[mq]: overfix
MozReview-Commit-ID: 98nyTYa5ZeR
--HG--
extra : rebase_source : 82045e10771038d7168d1f235143c24c72dd5a45
We risk a shutdown hang without any clues if a dangling reference somewhere
keeps a SharedThreadPool alive past xpcom-shutdown-threads. This because
xpcom-shutdown-threads waits for all SharedThreadPool to be destroyed before
advancing shutdown further. nsCycleCollector::Shutdown comes after
xpcom-shutdown-threads so it is possible that a reference-cycle unexpectedly
keeps a SharedThreadPool alive and blocks shutdown indefinitely.
This patch attempts to help diagnose future cases like this by printing which
SharedThreadPools we are going to wait for to stderr.
MozReview-Commit-ID: CwTApYUMikA
--HG--
extra : rebase_source : f29d04508cf492c82d65f324d7b1990849a0da13
For now we preserve the current code structure and function signatures to make
review simpler. That's about to get cleaned up.
MozReview-Commit-ID: 4epLHQiEwDV
test_bug609794.html was testing a behavior that the method before the current
method of attaching InstallTrigger to windows depended on. We don't really
need that behavior, which is good, because this change is not producing it.
MozReview-Commit-ID: GPzif89UYYl
The only caller of nsDOMConstructor::nsDOMConstructor is
nsDOMConstructor::Create which has no callers.
Also removes the now-unused nsDOMConstructorSH class.
MozReview-Commit-ID: GgOO8ugXFKb
We only have classinfo left for DOMConstructor and DOMPrototype, both of which
use nsDOMConstructorSH, which overrides PostCreatePrototype.
To avoid -Werror build failures, this changeset also removes static functions
that were only reachable from PostCreatePrototype.
MozReview-Commit-ID: JpJOuMHAAuo
We don't resolve it normally, because nsDOMConstructorSH overrides
PostCreatePrototype to be a no-op, so nsWindowSH::GlobalResolve never actually
defines the relevant property on the window. We also hide it in
nsWindowSH::NameStructEnabled. But in the Xray-to-window case we attempt to
define it. We shouldn't do that.
MozReview-Commit-ID: 3tnMnSQuvuT
The only caller is nsDOMClassInfo::RegisterClassProtos. The only caller of
that is nsDOMClassInfo::Init. In nsDOMClassInfo::Init this is called after we
have done the RegisterClassName call for "DOMConstructor".
Since the only bits of classinfo left are DOMConstructor and DOMPrototype, and
both use nsIDOMDOMConstructor as their interface, we call RegisterClassProto
with "DOMConstructor" as aClassName, find the existing nsGlobalNameStruct, and
return without doing anything. So this entire codepath can be removed.
MozReview-Commit-ID: JfXmIex7tLC
nsFrameLoader is on WebIDL bindings, so those QIs are no-ops anyway, unless the given object is no a frameloader to start with.
MozReview-Commit-ID: IPiW70H5NPc
