For it doesn't guarantee a smooth playback with a little data buffered.
MozReview-Commit-ID: 5NNQ4Q8uz39
--HG--
extra : rebase_source : dab53162cc06ddc74cca08e910a19eff01446703
The tests expected that the error code would be MEDIA_ERR_DECODE whenever we fail to open a video. However, MEDIA_ERR_DECODE is to be used only when "An error of some description occurred while decoding the media resource, after the resource was established to be usable."
All those files have errors in their metadata. Which makes the resource unusable to start with.
Similarly, networkState would be set to NETWORK_NO_SOURCE if the metadata couldn't be read.
MozReview-Commit-ID: KXVJmD3ZQlT
--HG--
extra : rebase_source : 1ec3d7e764d832702e662f0b650363498e0b0761
There's no such step defined in the spec. Despite, this code can no longer be called when readyState is HAVE_NOTHING
MozReview-Commit-ID: 2fDoNHt1COp
--HG--
extra : rebase_source : d8b79acee85b00331f55153626038e26cd4a72c7
Will simplify the code in the following patch, not having to perform unnecessary test.
MozReview-Commit-ID: 5zUzSZgzrG9
--HG--
extra : rebase_source : c409a70d1aa5975b1a990a884856b3b5712bc190
This part just sets a cutoutregion property on the element node and schedules a paint.
The next part will check for that property and create a display item for the element
in question.
MozReview-Commit-ID: EbPr8it5Lpw
This should also fix bug 1296775 and bug 1290359.
There's a very good chance it will also fix bug 1293386, bug 1292855, bug
1289452, and bug 1303340: those would get hit if we happened to start _another_
gc after the expando died but while it was still in the Rooted. All of them
seem to be dying under the domClass->mGetProto call, which could finish up a GC
that kills the expando and then do _another_ one, causing the Rooted to try to
mark a dead object.
Conditions may have changed (such as currentTime moving since the last attempt). So we try again.
MozReview-Commit-ID: 2zexl1FzOd7
--HG--
extra : rebase_source : 5c21f6edc438fb012e18eda45237383fc8b83794
Passes the profile dir to the content process as a -profile CLI
option so that the correct profile dir can be used in the OS X content
sandbox rules. Only enabled on OS X for now.
On Nightly, profile directories will now be read/write protected
from the content process (apart from a few profile subdirectories) even
when they don't reside in ~/Library.
xpcshell tests invoke the content process without providing a
profile directory. In that case, we don't need to add filesystem
profile dir. read/write exclusion rules to the sandbox.
This patch adds two new macros to the content sandbox rule set:
|profileDir| holds the path to the profile or the emptry string;
|hasProfileDir| is a boolean (1 or 0) that indicates whether or
not the profile directory rules should be added. If |hasProfileDir|
is 0, profile directory exclusion rules don't need to be added
and |profileDir| is not used.
MozReview-Commit-ID: rrTcQwTNdT
--HG--
extra : rebase_source : 3d5b612c8eb3a1d0da028eba277cd9d6f0c9ac00
Additionally, mark non fatal decoding error as such.
Due to the complexity of WMF decoder error handling, this will be done in a follow up bug.
MozReview-Commit-ID: KHWORM8899c
--HG--
extra : rebase_source : 77ada9bb95ba4d44d1bca209e4a7d28369f24f6e
Will allow to pass detailed failure causes in a followup patch.
MozReview-Commit-ID: 5yGjzZNcYWg
--HG--
extra : rebase_source : fdd76c98900320352ee3c349de1c40df29122ca9
We provide even further details for the GMP decoder. Other decoders to follow.
MozReview-Commit-ID: 7NxJPec8xWv
--HG--
extra : rebase_source : f44120983070e5c107ecd5cafc762da90aab44bf
Instead of "not visible", "approximately visible", and "visible" (in display port) we now have "approximately not visible", and "approximately visible" which includes "visible".
- Fixes a crash that occurred when WebVR frames were rendered prior to
setting up the WebGLContext for mirroring back to the 2d display.
MozReview-Commit-ID: Fq4c2287KBL
--HG--
extra : rebase_source : e0e0416f1d6a5f9058c7ed89581b700f32712e72
We currently allow nested event loop to delay ContentChild::RecvShutdown
which in turn might cause content process shutdown hang. This patch
attempts to annotate the crash report that a shutdown hang was after we
have received RecvShutdown but never reach SendFinishShutdown or the
hang happened before or after RecvShutdown.
MozReview-Commit-ID: 8pGqwzLlYpK
--HG--
extra : rebase_source : 78fdec0c29ded1abbd6651c67fe5c97f63555635
When swapping content from <iframe mozbrowser> to <xul:browser>, we now stop the
frame scripts that implement the content side of the browser API since they are
no longer needed and can cause issues if they remain active.
MozReview-Commit-ID: JrecxA4MI93
--HG--
extra : rebase_source : cc68b975c7d82035410a647ff66eab130055ed04
It wasn't immediately obvious to me that BrowserElementIsReady was correctly
guarding against re-running the browser element scripts in a frame. After more
testing, it was working, but I've added some debug lines for future clarity.
No functionality changes in this patch.
MozReview-Commit-ID: CW4o2TsGKmj
--HG--
extra : rebase_source : 62ec06d4b75f90b3478e403906efaa2f3c3658e2
In general, the audio competing should only be for audible media and it helps user can focus on one media at the same time. However, we hope to treat all media as the same in the mobile device.
First reason is we have media control on fennec and we just want to control one media at once time. Second reason is to reduce the bandwidth, avoiding to play any non-audible media in background which user doesn't notice about.
MozReview-Commit-ID: yB3181cmVE
--HG--
extra : rebase_source : 0f7bc1d4e9fc3f68e2085f59eb0a313d44a1c058
Use 'media-playback' event to control the media control interface on Fennec.
MozReview-Commit-ID: D8SU96RrkbQ
--HG--
extra : rebase_source : 16a13e3b1a450a2949cb62b77a53311797daaaf2
If initializing DXVA fails, we end up destroying the DXVA2Manager on the
decode task queue. The DXVA2Manager asserts that it's destroyed on the
main thread, so we should dispatch a task to destroy it on the appropriate
thread instead of destorying it on the wrong one.
MozReview-Commit-ID: 2pbeMOm74et
--HG--
extra : rebase_source : c4a6871877747d4e04494c638d83b225decaf249
So we have only one place to transition to the SHUTDOWN state which is Shutdown().
MozReview-Commit-ID: 6MNISCea94Q
--HG--
extra : rebase_source : 3e5a2084a158fc9569b3b7d3b95033d7fe4233b2
Following bug 1301307, exception is properly thrown when buffer is full, giving the opportunity to the JS player to adjust accordingly. Confirmed to work with YouTube with an audio threshold of only 1MB.
MozReview-Commit-ID: 77K8UPhb9zj
--HG--
extra : rebase_source : 64b75f7f563ba9d6fc0c6feeaf7c945894fd6a06
There is no point in scheduling an addition cycle to do that.
Also remove the annoying debugging message which is not helpful.
MozReview-Commit-ID: BMjeTNg6HCY
--HG--
extra : rebase_source : df1be5984072fd64070bd5da98e7e27a46c59756
extra : source : 93c2408e698b0e597b6ab8cb47255c53cf65e67d
We don't want to run MDSM cycles anymore once shutdown begins.
MozReview-Commit-ID: 7Py20oqWNBG
--HG--
extra : rebase_source : 42793b4463593cf4efa7eae6d59c79dc528a82b2
We don't want to receive notifications from MediaEventSource or WatchManager once shutdown begins.
MozReview-Commit-ID: LiKUjOGuxyX
--HG--
extra : rebase_source : 05af4df691f174e8c4c6082bafc14c04534ce8fa
We can't guarantee any data will be written, it should suffice to just
make sure that the socket closes immediately and then verify that
a complete set of data wasn't read.
MozReview-Commit-ID: CHHuJEGRVgX
--HG--
extra : rebase_source : 2269b73a4497011c9604628710055a0fc08e0470
Currently, ContentEventHandler::OnQueryTextRectArray() is used only in e10s mode (at caching necessary character rects in ContentCacheInChild). Therefore, this bug occurs only in e10s mode.
ContentEventHandler::OnQueryTextRectArray() applies CSS transform only to each frame rect. Therefore, character rect's width and height are not applied.
This patch makes the loop apply CSS transform to each character or line breaker rect (i.e., each item of charRects). Then, we need to rewrite the lastCharRect hack. It stores the last charRect value for computing next line breaker rect if next line breaker is caused by a block level element or something, i.e., not caused by a <br> frame. So, when brRect is computed with lastCharRect, the loop needs to apply CSS transform of the last text frame to the following brRect because it tries to compute a caret rect immediately after the last character. For doing this, this patch adds lastFrame which stores the last frame for lastCharRect and set it to baseFrame. Then, at applying CSS transform to each charRect, it can apply CSS transform of expected frame.
Similarly, when brRect is computed with last text frame, this patch looks for the last text frame from lastTextContent and use it as base frame to apply to CSS transform.
MozReview-Commit-ID: 5Yr2HMrooHd
--HG--
extra : rebase_source : fa643f442036d9167a1df3a4383b0802a1729a3e
There are too many cases where the MP4 is improperly muxed and frames are incorrectly reported as keyframe.
Instead we now look inside the H264 stream and check for IDR frames.
We also ensure that the first frame returned after a seek is always a true keyframe.
For plain MP4, seeking in those broken files will lead to broken A/V sync. The only way to fix this would be to check for the frame type when reading the samples table. However, this would require to read the entire stream which isn't viable.
MozReview-Commit-ID: Cpv5y7HVD0N
--HG--
extra : rebase_source : 2f92032fe39ed6ad6c2b82438f405040b5e7d30c
The WMF decoder doesn't handle well the case where a single frame was given to decode.
When draining, the output is a correctly decoded frame but with a time of 0 and a duration set at 1/30th.
This is a workaround
MozReview-Commit-ID: JbjgNmPXKIM
--HG--
extra : rebase_source : f25a1fd503678383265ec5053b41f3116ff52da0
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
- 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
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've had large numbers of shutdown hangs with the Windows H.264 decoder stuck
calling IMFTransform::ProcessOutput(), blocking shutdown. I can reproduce this
with videos with dimensions less than 32 pixels.
Chrome also encountered this with the WMF decoder:
https://bugs.chromium.org/p/chromium/issues/detail?id=373288
The WMF H.264 Decoder is documented to have a minimum resolution of 48x48 pixels.
So this patch causes us to reject H.264 files with either width or height less
than 48 pixels.
I have been able to play files down to 34x34 pixels on Windows 10, but it seems
safest to just follow the what's documented in MSDN, and reject files that are
smaller than the documented minimum.
MozReview-Commit-ID: 5peP6UGnAaB
--HG--
extra : rebase_source : 6e29812642bc3f8ca0f5b39b36064a6d50e09ea7
After using enum class, a switch-case warning in CombineBreakType is caught.
This is one of such kind safty checks that we would like to gain.
Fix it by adding default case for switch-case in CombineBreakType.
MozReview-Commit-ID: BdS3LPN6qzX
--HG--
extra : rebase_source : 17f24a0d482ed6eb51b23e6942d0ac1c87375e0b
Enable nsAttrValue::EnumTable to be initialized with enum. So, we could get rid
of the castings in EnumTable. Fix EnumTable initialization comment.
For those untyped enumerations, declare them with uint8_t, as to other typed
enumerations with type size larger than int16_t, force casting to int16_t.
Use {nullptr,0} instead of {0} to represent the last entry.
MozReview-Commit-ID: 7Dma3Apkmxj
--HG--
extra : rebase_source : b2289866c4c33d80c8e170727bf109d018d92f67
Jean-Yves Avenard
JW Wang
Julian Hector
Kershaw Chang
Wes Kocher
Markus Stange
Eric Faust
Boris Zbarsky
Jim Chen
Aaron Klotz
Sebastian Hengst
Nicolas Silva
Carsten "Tomcat" Book
Alexandre Lissy
Michael Layzell
Nathan Froyd
Andreas Pehrson
Jan de Mooij
Andi-Bogdan Postelnicu
Benoit Girard
Ben Kelly
George Wright
Daosheng Mu
Thomas Wisniewski
Frederik Braun
Stone Shih
David Anderson
Haik Aftandilian
Mantaroh Yoshinaga
Mike Hommey
Hiroyuki Ikezoe
bechen
Ho-Pang Hsu
Olli Pettay
Andrea Marchesini
Morris Tseng
Ninad Bhat[:ninad101]
Byron Campen [:bwc]
Phil Ringnalda
Igor
Kaku Kuo
Kannan Vijayan
Paul Adenot
kearwood
Kan-Ru Chen
J. Ryan Stinnett
Alastor Wu
Chris Pearce
Shing Lyu
Gerald Squelart
Nicholas Nethercote
Matt Woodrow
Brad Werth
Eric Rahm
Jessica Jong
James Cheng
Dylan Roeh
Jeff Gilbert
Ehsan Akhgari
Shih-Chiang Chien
Mike de Boer
Matteo Ferretti
William Lachance
Masayuki Nakano
Brian Grinstead
Mike Conley
Bryce Van Dyk
Chun-Min Chang
KuoE0
Tom Tung
cku
Alex Chronopoulos
ctai
Alfredo.Yang
Henry Chang
John Lin
Jeremy Chen