This patch changes 'TEST 3' so that instead of testing that all the
documents' document.fonts.ready Promises are resolved at a certain time, that
instead it just waits for them to resolve and then checks that they resolved
to the correct object.
The test previously assumed that calling SpecialPowers.pushPrefEnv on the
page's 'load' and waiting for pushPrefEnv's callback would be enough time
for document.fonts.ready to have been resolved for the top-level document and
all of its frames. That is not necessarily the case. Even the Promise in the
top-level document itself is not guaranteed to have resolved by that point.
The Promises will not have been resolved at least until style and layout has
been flushed, and in fact in Mozilla's implementation it frequently won't
happen until the first refresh driver tick after layout has finished. The
result of this is that the CI machine 'Linux x64 QuantumRender opt' was
failing 'TEST 3' intermittently.
Crash reports indicate that SourceBuffer::mStatus is not set, and thus
SourceBuffer::AppendFromInputStream crashes due to dereferencing an
invalid Maybe<nsresult> object. Since SourceBuffer::Append cannot fail
without mStatus being set (or already set), it must mean that the input
stream failed to read all the data, and swallowed any internal errors.
While we used to assert in this situation, we also silently swallowed
the error historically. This patch will check mStatus, but if it is
unavailable, it will assert like before, and silently return otherwise.
And use the C++ ErrorReporter only to actually output errors.
ErrorReporter was so complicated because well, it was always enabled and had to
do a bunch of caching to not be (more) slow.
But since bug 1452143 it's disabled by default, so we can simplify this setup a
lot.
Also while at it make the error reporting pref a static pref so that we don't
mutate globals from CSS parsing unless we're actually reporting errors.
MozReview-Commit-ID: AuIyvJwt7AU
This would cause properties to change the value semantics between, e.g.,
@keyframes and non-@keyframes, which would be observable.
It happens not to be observable since the animation-* and transition-*
properties are not allowed in @keyframes, nor have bits in `contain`, and none
of the two properties are allowed in @page. But I think it's the right thing to
do.
This still causes a quirk like a property value in chrome / user origins being
potentially different if the value is specified via CSS var functions. But I
think that is fine.
MozReview-Commit-ID: GhoPt0I34oO
This testcase used to fatally assert, but doesn't anymore. Hooray!
Let's keep it that way.
--HG--
extra : rebase_source : dad40f528fc56b0d8c4430053d87fbbc4873fe40
extra : amend_source : 8417dcfd116303645fe3d2825e94d2ddf5c3123d
Because of modifications to the DataTransfer constructors, the status of the tests that use DataTransfer objects had to be changed to reflect the fact that those tests now pass. Additionally, a test had to be deleted because it tested an obscure situation using the old Chrome only constructor.
MozReview-Commit-ID: LOWuPwh0NeW
Deleted the old Chrome DataTransfer constructor because it was only used
for some tests which can be easily changed. Added a new constructor that
is not Chrome Only.
MozReview-Commit-ID: HjcgafSiWfM