1. The return value is not used.
2. It should be called only when mSentFirstFrameLoadedEvent is false.
3. Transition to SEEK if there is any pending seek or DECODER_STATE_DECODING otherwise.
MozReview-Commit-ID: LIO0MPGzhsX
--HG--
extra : rebase_source : 591339cf0c239be618ecf25e384baab9c0bb35be
We move the handling of pending seek from the entry action of DECODING to that of DECODING_FIRSTFRAME.
MozReview-Commit-ID: qMnJ0ON2cK
--HG--
extra : rebase_source : d35985d8d66b201a842aea0eeb0650e8ade5cc5b
It is impossible to finish decoding first frames while waiting for data.
MozReview-Commit-ID: 8eR8Rf9TuD8
--HG--
extra : rebase_source : f8d14b294f0518f48f72828b3e9ed5f2b18a3479
MDSM used to transition to DECODING in the following places:
1. BUFFERING
2. OnMetadataRead()
3. WAIT_FOR_CDM
4. SeekCompleted()
We will transition to DECODING_FIRSTFRAME in case 2 and 3.
For case 1, BUFFERING makes sense only after decoding first frames. So BUFFERING
should never transition to DECODING_FIRSTFRAME.
For case 4, we always finish decoding first frames before completing seek. So
It should not transition to DECODING_FIRSTFRAME either.
MozReview-Commit-ID: 7VnK82wjgZv
--HG--
extra : rebase_source : c92150a2cd989286d680760c6b7dc615fe58b65e
When separating decoding frist frames from the DECODING state, we need
to change the test `mState == DECODER_STATE_DECODING` to
`mState == DECODER_STATE_DECODING || mState == DECODER_STATE_DECODING_FIRSTFRAME`.
However, we don't make changes for those where mSentFirstFrameLoadedEvent is
proven to be true. Because there is no way for mState to be DECODING_FIRSTFRAME
when mSentFirstFrameLoadedEvent is true.
MozReview-Commit-ID: 7jv3SDlmBBG
--HG--
extra : rebase_source : d7212fa84d81cb1874e6a76fb92627255039e859
We currently make the initial browser in a window remote by default. If early
on in the session, that one remote browser goes away (and the content process
was still booting), there's about 5 seconds before the shutdown kill timer
will take that content process out for not quitting fast enough.
There are some cases during startup where the content process is waiting
on information from the parent, so it cannot respond to the request to
quit in time. The parents shutdown kill timer goes off, and the shutdown
kill occurs.
In this bug, what's happening is that the initial browser flips remoteness
from remote to non-remote when it goes to about:sessionrestore. This starts
the shutdown kill timer. The content process runs out of time, and the
shutdown kill timer fires, killing the content process. The TabParent::ActorDestroy
method (which still exists, even though the browser is no longer remote),
interprets this as an abnormal shutdown, and bubbles the oop-browser-crashed
event to the associated <xul:browser>, which causes the page to browser to
about:tabcrashed, when it had already loaded about:sessionrestore.
This patch makes it so that the TabParent::ActorDestroy method first checks
to ensure that the associated remote frameloader is still the one that the
frameloader owner cares about. If not (because, say, the remoteness has
flipped and a new non-remote frameloader has been created), then the
event is not fired, since the user has moved on.
MozReview-Commit-ID: G4jmR6lMMFl
--HG--
extra : rebase_source : 7e752d9854d6c17b2b346cc986c0fbad00292848
I also fixed two test cases while I was looking at the results.
MozReview-Commit-ID: LpUj56UNV3r
--HG--
extra : rebase_source : 7ca9986b96b43f9ec20571dd24d9f8bc8d691288
- Use format() instead of old style formatting (%s, etc).
- Remove unneeded positional args on format strings.
- Break some long lines for pep8 conformance.
- Use brackets instead of \ to continue long lines.
- Log interval on video puppeteer.
- Remove an unneeded media source check. We have explicit media source checks
in tests, and the media source prefix has changed, rendering the check broken.
MozReview-Commit-ID: 4FPVoOD0P5B
--HG--
extra : rebase_source : 3bfdc4a5aee5c419e4ccacc923ec539cbaa1d14f
- Corrects issues with the onvrdisplaypresentationchange events being delayed by up to 5 seconds.
- Caused a delay to enter or exit WebVR presentation on many sites.
MozReview-Commit-ID: 2LACZNwKIxW
--HG--
extra : rebase_source : ec689cd68422a8487a85e70d9e2dbb13b3a1c36c
Repacks of upstream builds of rust 1.11.0 stable with std libraries
for the appropriate targets. Remove the separate rust-std package
references since the new repacks include the necessary targets.
Also update clang and hazard builds to the latest toolchain.
MozReview-Commit-ID: K7oBxQZnLPu
--HG--
extra : rebase_source : 9f339ff52e9e2f6c28d4bb7a734b9f0eae43a47a
Including headers inside anonymous namespaces, especially standard headers,
is super-unusual; let's just move the header to the toplevel instead.
MozReview-Commit-ID: CNykWQA5ndY
--HG--
extra : rebase_source : e5011cd18c1a0d31d4ae15ae3f3697eafac5f575
We currently make the initial browser in a window remote by default. If early
on in the session, that one remote browser goes away (and the content process
was still booting), there's about 5 seconds before the shutdown kill timer
will take that content process out for not quitting fast enough.
There are some cases during startup where the content process is waiting
on information from the parent, so it cannot respond to the request to
quit in time. The parents shutdown kill timer goes off, and the shutdown
kill occurs.
In this bug, what's happening is that the initial browser flips remoteness
from remote to non-remote when it goes to about:sessionrestore. This starts
the shutdown kill timer. The content process runs out of time, and the
shutdown kill timer fires, killing the content process. The TabParent::ActorDestroy
method (which still exists, even though the browser is no longer remote),
interprets this as an abnormal shutdown, and bubbles the oop-browser-crashed
event to the associated <xul:browser>, which causes the page to browser to
about:tabcrashed, when it had already loaded about:sessionrestore.
This patch makes it so that the TabParent::ActorDestroy method first checks
to ensure that the associated remote frameloader is still the one that the
frameloader owner cares about. If not (because, say, the remoteness has
flipped and a new non-remote frameloader has been created), then the
event is not fired, since the user has moved on.
MozReview-Commit-ID: G4jmR6lMMFl
--HG--
extra : rebase_source : 7e752d9854d6c17b2b346cc986c0fbad00292848
We use the FaviconView to fill the majority of the card (i.e. full width, and approx 75% of the height)
- in that scenario rounding the corners looks odd.
MozReview-Commit-ID: 1e5HAwfcV5
--HG--
extra : rebase_source : e6c5168025e1ac3ad941e8fd6207960b37442373
Let's try to load from the legacy loader only if there's one icon left and
the other loads have failed. We will ignore the icon URL anyways and try to
receive the legacy icon URL from the database.
MozReview-Commit-ID: Kr7gHXBuAs7
--HG--
extra : rebase_source : 7fbdd507fa2c0a9aa4223db1da6aa5fbc1aa4907
If we are allowed to load the icon from the network then skip loading from the legacy storage and just
load a fresh icon. This will avoid touching the legacy storage (disk) every time before downloading an
icon.
MozReview-Commit-ID: C9hYqISno6U
--HG--
extra : rebase_source : 6f19839c38d37916deb351b3e080e023e532a83f
Running the color extraction algorithm on a smaller image will be much faster.
MozReview-Commit-ID: A42rzuQ3FDQ
--HG--
extra : rebase_source : 560e5e1a6711d8f34f12803e5aabf4f09e769706
The custom executor behaves like the one returned by Executors.newSingleThreadExecutor().
However the created thread will have a unique name ("GeckoIconTask") and this will make
tracing the thread much easier.
MozReview-Commit-ID: 7y0EMGmNLkG
--HG--
extra : rebase_source : 517d329df12ff101816c3a3f8e27f28aeffb6821
