Similar to lines (see previous patch), floats from next-in-flow or overflow
frames have probably not been marked dirty (as ReflowInput hasn't dealt with
them when it was constructed), so we need to mark them dirty for proper reflow.
If we don't do that, and they don't fit in the current column, the next column
will only mark its current children dirty, so when pulling back its first
floats from the previous column they will not be reflowed as needed.
MozReview-Commit-ID: KKrwtzeQMrI
--HG--
extra : rebase_source : ec99f380c978c6d28135490401beb0bb54c8e2b3
Lines pulled from next-in-flow or overflow frames have probably not been marked
dirty (as ReflowInput hasn't dealt with them when it was constructed), so we
need to mark them dirty for proper reflow.
If we don't do that, and they don't fit in the current column, the next column
will only mark its current children dirty, so when pulling back its first lines
from the previous column they will not be reflowed as needed, which causes this
bug.
MozReview-Commit-ID: 8GFO1ZWuZ1b
--HG--
extra : rebase_source : ee55a9ae7408e1f2603c1b2bc80ddcd8dbc837f0
In Bug 1188240 we disabled autoplay on Android < API version 16 because of a
vulnerability in old libstagefright, but as of Firefox 55 our minimum supported
Android version is 4.1, or API verion 16.
We've renamed the media.autoplay.enabled pref, so we can just remove the
check on media.autoplay.enabled added in bug 1188240 as it's testing for a
version of Android we no longer support anyway..
MozReview-Commit-ID: Gc8ZnlOiiMn
--HG--
extra : rebase_source : 12817b6e782331f3e4f26be0b97181418ec3287f
We're planning on enabling block autoplay on desktop by default, so in order to
be consistent across platforms, we think we should also enable it on mobile by
default.
The change here makes us allow autoplay in tabs which have had user
interaction, rather than the legacy block autoplay implementation which
"blessed" media elements which had certain functions called in a user generated
event handler.
Current plan is to enable this on Nightly only (desktop & mobile) and solicit
feedback and then decide on whether to let it ride the trains.
MozReview-Commit-ID: IkusfUOrcgO
--HG--
extra : rebase_source : 0c0a8f80d3670fffe66540f66954eaa980a42e74
We're going to enable block autoplay of HTMLMediaElements by default in Nightly,
but lots of our tests assume they are allowed to playback media without requiring
user interaction. After we've enabled block autoplay that assumption won't be valid.
So configure the prefs that control block autoplay so that we allow media to
autoplay.
This means the existing tests we have don't need to be rewritten to work when
we enable block autoplay by default.
MozReview-Commit-ID: 50yydubQjkS
--HG--
extra : rebase_source : a19e6c5b60d3b89e754be786281ca3242baa3830
We want to solicit feedback on our doorhanger implementation, so enable block
autoplay by default on Nightly only.
MozReview-Commit-ID: Kq5T8BS5Esm
--HG--
extra : rebase_source : b55a3fa34c4687a4ad4a74f38d4e46fe194aee30
Pending figuring out how we want to block autoplay of WebAudio content, we
should just not block it by default for the initial release of block autoplay,
and follow up once we've figured out how to not break the web.
MozReview-Commit-ID: ClfdrHcugLs
--HG--
extra : rebase_source : 54f61b0765f1d0ed9c754c90da9c2809a7de8676
We download the update APK into the public downloads directory and normally the
only relevant app consuming that URI should be the system package installer, but
just to be safe we only switch usage from Nougat onward, too.
This patch had already landed as part of bug 1450449, but subsequently got
overwritten during the refactoring in bug 1407046.
MozReview-Commit-ID: Ipmmlpm91zK
--HG--
extra : rebase_source : 426d98084fd26d5312e1aa5809256a5f29cd7b4d
On 10.9 and 10.10, grant global read access to the Flash sandbox.
Change Flash sandbox levels by adding a new level 1 that includes
global read access which will be the default on 10.9/10.10.
Level 2 is the new default for 10.11 and above with file read
access enabled by file dialog activity.
MozReview-Commit-ID: LvXhd6Vf7mo
--HG--
extra : rebase_source : 946f89937e5bb4506fd6bc8b2c050c86a8b29cc8
This patchset changes the MediaDevice type names from "audio" and "video" to "audioinput" and "videoinput". GeckoSession has been updated to expect the new string names. In parallel a new type "audiooutput" has been added but it is not important for this patch.
MozReview-Commit-ID: FUdG5QtD9re
--HG--
extra : rebase_source : 2a4bec49ef12898ef7aea7747ff7407577521916
MediaRawData is never subclassed, so it's pointless to have these
methods be virtual.
--HG--
extra : rebase_source : ef55196831f5ff96e75b46f304541e1cb8fafada
extra : source : ccef9e2643a19668dc06426aa0e55ed5d61ae535
AV1 support is behind a pref, as such, the result of canPlayType should depends on the value of that pref.
Additionally to this change we remove AOMDecoder::IsSupportedCodec as it implied confusion on what a codec mimetype is. There are two type of codec mimetype: the one describing the container content ("av1") and the one describing the codec itself "video/av1")
AOMDecoder shouldn't know anything about containers (e.g. mp4 or webm)
--HG--
extra : rebase_source : 72ebe662f76fb6c9d8be1f753890601aac440061
The current code for resizing PLDHashTable modifies the cached hash for
all entries in the old hash table. This is unnecessary, because we're
going to throw away the old hash table shortly, and inefficient, because
writing to memory we're never going to use again just wastes time and
memory bandwidth. Instead, let's avoid the write by pulling out the
cached key and doing the necessary manipulation on local variables,
which is probably slightly faster.
