Cleaning up compiler warnings for nICEr. Major highlights:
- set _WINSOCK_DEPRECATED_NO_WARNINGS define in nicer.gyp for Windows
builds of nICEr to avoid warnings about inet_addr use in ice_ctx.c:102,
ice_ctx.c:297, ice_parser.c:465, and transport_addr_reg.c:143.
- move nr_ice_accumulate_count from ice_ctx.{h|c} to stun_util.{h|c}
as nr_accumulate_count to quiet warnings in turn_client_ctx.c and
stun_client_ctx.c.
- stun_msg.{h|c} - change nr_stun_attr_data_.length,
nr_stun_message_attribute.encoding_length and nr_stun_message_.length
from int to UINT2 (not size_t since other lengths in this header are
UINT2).
- stun_codec.{h|c} - lengths and offsets changed from int to UINT2 to
match changes in stun_msg.{h|c}
- r_data.{h|c} - change Data.len from int to size_t
- nr_crypto.{h|c} - change nr_ice_crypto_vtbl_ lengths from int to size_t
MozReview-Commit-ID: EF5v79RpqbI
--HG--
extra : rebase_source : ead30e2359ea6a6aada4dd222137302ba86fb972
As requested by the WebDriver specification any beforeunload prompt
has to be automatically dismissed for the close and navigate commands.
MozReview-Commit-ID: 1qp0nzIYTaM
--HG--
extra : rebase_source : 418dca8e9fa61df6d5423c8c5cce6a97a0001821
Currently the remote check only gets performed for the very last page
of each bfcache test. Instead it has to be executed for each individual
web page as loaded.
MozReview-Commit-ID: IIqnLy4RhZ5
--HG--
extra : rebase_source : eaed841979d65b6b2aab4e3ba2bc43679a7ba3a4
To allow Session.start() to be called multiple times the originally
requested capabilities for the driver have to be stored. Currently
those are overwritten with the ones as returned by the driver.
That means that custom entries which are getting extracted by the
driver (eg preferences) to setup the browser profile, are lost and
tests themselves cannot internally end a session and start it again.
MozReview-Commit-ID: Fi0cf6MaOc6
--HG--
extra : rebase_source : 91e18d628cceca800a99f70e580f0af4b0d8a2e8
In case the driver already deleted the session (eg last window closed)
make sure to also invalidate the internal session id.
MozReview-Commit-ID: EIbrEDk73jN
--HG--
extra : rebase_source : a54ec3f877f09bdc1c3467b0c8301255bedae781
Regardless of the size of an encoded image, SourceBuffer::Compact would
try to consolidate all of the chunks into a single chunk. If an image is
quite large, it can be actively harmful to do this, because we want a
very large contiguous chunk of memory for no real reason, and spend
extra time on the main thread doing the memcpy/consolidation.
Instead we now cap out the chunk size at 20MB. If we start allocating
chunks of this size, we will not perform compacting when we have
received all of the data. (Save for realloc'ing the last chunk since it
probably isn't full.)
On a related note, if we hit an out-of-memory condition in the middle of
appending data to the SourceBuffer, we would swallow the error. This is
because nsIInputStream::ReadSegments will succeed if any data was
written. This leaves the SourceBuffer out of sync. We now propogate this
error up properly to the higher levels.
fixup
All animated images on a page are currently registered with the refresh
driver and advance with the tick refresh. These animations may not even
be in view, and if they are large and thus cause redecoding, cause a
marked increase in CPU usage for no benefit to the user.
This patch adds an additional flag, mCompositedFrameRequested, to the
AnimationState used by FrameAnimator. It is set to true each time the
current animated image frame is requested via
FrameAnimator::GetCompositedFrame. It is set to false each time the
frame is advanced in FrameAnimator::AdvanceFrame (via
FrameAnimator::RequestRefresh). If it is true when
FrameAnimator::RequestRefresh is called, then it will advance the
animation according to the normal rules. If it is false, then it will
set the current animation time to the current time instead of advancing.
This should not cause the animation to fall behind anymore or skip
frames more than it does today. This is because if
FrameAnimator::GetCompositedFrame is not called, then the internal state
of the animation is advancing ahead of what the user sees. Once it is
called, the new frame is far ahead of the previously displayed frame.
The only difference now is that we will display the previous frame for
slightly longer until the next refresh tick.
Note that if an animated image is layerized (should not happen today) or
otherwise uses an ImageContainer, this optimization fails. While we know
whether or not we have an image container, we do not know if anything is
actively using it.
Can be used:
ac_add_options --enable-linker=lld-7
or
ac_add_options --enable-linker=lld
MozReview-Commit-ID: GfDevGeooU4
--HG--
extra : rebase_source : ee2aad5f8f721a6fe5840affde6b29a3b940fb91
Summary:
In essence, we're allowing a new field in the task definition,
which is trusted over the one that's passed in with the config. This
wouldn't make much sense if it had a real date in, but allows us to
set an empty string for the kind that needs it
Reviewers: bhearsum
Reviewed By: bhearsum
Bug #: 1458854
Differential Revision: https://phabricator.services.mozilla.com/D1214
--HG--
extra : rebase_source : 82145a94fa91957ffe57112a1c0d327d99e32b23
