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
Refactor the tests to make them work with pytest directly rather than
also depending on unittest. Fix the helper functions to work with the
current state of metadata.py. Add some tests for update of assertion
count and lsan data.
MozReview-Commit-ID: 1XcMqSbqr43
Previously we were holding a map of test id -> test and test ->
expectation data. But this is an unnecessary layer of indirection, and
it works perfectly well to map test id to the expectation data
directly. This makes the code simpler and may also help make the
update a little faster.
MozReview-Commit-ID: 5PymX6Lxkgu
In this case we want to take the existing value into account, and update
to 1 more than the new value (in the max-asserts case).
MozReview-Commit-ID: 1RtJ2gU1ZbH
The `stop` method is always called to shutdown firefox, but the
cleanup method is only called at the end of a test run. Therefore we
need all the leak processing stuff ot happen in stop().
MozReview-Commit-ID: 5OE54cEygNy
LSAN data differs from existing expectation data because the data is
only generated when the browser exits, so the problems reported can
happen at any point in the current session. We use the `scope`
property in the log message to determine the path to a __dir__.ini
file that covers all the tests run in the session, and add the LSAN
exclusion rules to there.
The rules themselves are generated by taking the topmost frame of any
stack that's reported as unexpectedly leaking, and adding that to the
list of permitted frames in the lsan-allowed property. We never remove
entries from this list since intermittents may be present which won't
appear on a specific run. Instead we rely on humans fixing the issues
to also clean up the expectation files.
MozReview-Commit-ID: Kxm0hFXlGE3
This initially contains a scope entry which is set to the base directory of
the tests being run. Typically this is /, but with run_by_dir, it's the
path to the current run_by_dir group e.g. /html/semantics/form_elements/
MozReview-Commit-ID: JEFJByKTUsH
This adds a property lsan-allowed to the expectation manifest files
that takes a list of strings. Any entry in the list that matches a
frame in an LSAN stack will cause that stack to be regarded as an
expected failure.
MozReview-Commit-ID: 2oUw0joThha