Android's Settings.canDrawOverlays() returns true/false for one of the packages with the same
sharedUserId. There's no guarantee that this is actually the current package.
Instead of relying on Settings.canDrawOverlays() we just try to add and remove an invisible
view through WindowManger. If this succeeds then we obviously can draw overlays and if this
fails then we seem to not have the permission.
MozReview-Commit-ID: 1jdrQ7iV3ek
--HG--
extra : rebase_source : cc3161ad659c20c6a6c4fcb1bb1548b4f7a5ca5c
When opening the context menu (and displaying the "copy" menu entry)
or when receiving a copy event, we now check if the current target
is a textarea. (multiline inplace editor relies on textarea)
Modified existing test to check this new use case.
MozReview-Commit-ID: Cgm67JCdN4c
--HG--
extra : rebase_source : 4955f910e5428b92587b408ffd1b62cd668faf2a
The default inplace-editor autocomplete behavior is not userfriendly
when combined with a multiline inplace-editor. Navigating up/down might
trigger an autocomplete suggestion.
Also, the autocomplete popup is not displayed at the correct position and
should take the multiline into account.
MozReview-Commit-ID: JTiCQ3HK5bn
--HG--
extra : rebase_source : 001becbe7cfde064b2163e7c2ebcc4aa82e22610
The inplaceEditor now supports a maxWidth configuration option which can either
be a number or a method returning a number. This maxWidth will be applied to the
hidden element used in order to autosize the input.
MozReview-Commit-ID: JTiCQ3HK5bn
--HG--
extra : rebase_source : dcf7ba4a897cd77b43b333ec3b5633dc9043e51d
extra : source : a93558488cf7fc9f54165bd5f98055e8a3901dac
The Adobe GMP unencrypted decoder can't decode unencrypted input which has
valid crypto data attached; it thinks the sample is encrypted, and returns a
crypto error and decoding fails. The sample should be decrypted by the time
we pass it to the wrapped decoder, so decoding should succeed without the
crypto data.
MozReview-Commit-ID: KjZcQyYiRqp
The hack was supposed to avoid clobbers when landing bug 967556, which
might have worked somehow back then, but doesn't do anything useful
anymore. In fact, it now breaks the display of some results in
old-configure.
Gonk, Android, and the generic cross-compilation setup all were using a
different yet similar way to prefix the toolchain. The latter was even
wrong, since the target and target alias usually don't match actual
toolchain prefixes (which don't include the machine part of the target).
Note that this removes force-setting cross_compiling to yes in
old-configure, which wasn't working because every AC_TRY_COMPILE
resets it with $ac_cv_prog_cc_cross or $ac_cv_prog_cxx_cross.
Recent config.sub better handles all the broken android triplets (which
would have worked around bug 1257793), and added the -ios variant that
we've been relying on since bug 1257051, but that bug 1257648 broke by
using config.sub, which didn't support it)
The new config.guess interestingly now returns pc instead of unknown as
maching type on linux, which will, unfortunately, make objdir names
change when they are not manually set.
_DefineDataProperty was used to ensure that modifying Array's setter wouldn't
impact sorting, however, this is both not necessary and against the spec.
--HG--
extra : rebase_source : f7d1301abf3207e2091f4c1e3b7e3949c0961ec8
In some of these cases, this increase isn't strictly necessary, because we only
check state immediately after creating the animation, before it could have
completed (regardless of its duration). Still: we should consistently use long
durations for any animations that aren't expected to complete during the test
run, because short durations might accidentally get copypasted into new tests
where they might cause intermittent failures.
MozReview-Commit-ID: 8wSRqHMI12L
--HG--
extra : rebase_source : 12e6a054dce047351b06e064bcedd9cdec58150f
MozReview-Commit-ID: HXLTybsEb4R
This patch exchanges all old and deprecated API calls with the ones in PlacesUtils. As a side-effect we can also condense some other code by using promises.
--HG--
extra : rebase_source : 36c0ca5704c6f94734bc0796e97cabf776bf42f5