We haven't logged KeymapWrapper::HandleKeyPressEvent() nor
KeymapWrapper::HandleKeyReleaseEvent(). Therefore, this patch makes them
put their behavior into the log.
Additionally, KeymapWrapper::InitKeyEvent() does not log enough the result
of initialized WidgetkeyboardEvent. This patch makes it log more.
With those changes, we can get the log of:
- detail of dispatched keyboard events
- which key event didn't cause keyboard events
- which keyboard event was consumed
Note that the utility methods are copied from widget/windows. Perhaps,
we should create XP logging helper for keyboard/IME later.
Differential Revision: https://phabricator.services.mozilla.com/D15324
--HG--
extra : moz-landing-system : lando
Move all implementation of nsWindow::OnKeyPress() and nsWindow::OnKeyRelease()
into KeymapWrapper because the implementation is a little bit complicated
but not loggable. When we get bug reports which depend on environment around
IME/key handling like bug 1498823, it's useful to log those methods behavior
too.
Differential Revision: https://phabricator.services.mozilla.com/D15323
--HG--
extra : moz-landing-system : lando
This test ensures that IsSameBinaryAsParentProcess works correctly when
information about the current process's parent is no longer available.
It uses three processes which are outlined in the block comment at the top of
TestSameBinary.cpp.
Differential Revision: https://phabricator.services.mozilla.com/D15448
--HG--
extra : moz-landing-system : lando
'mWasAllowedToStart' would be set to false if AudioContext is not allowed to start, and would be set to true if AudioContext has been allowed to start.
Differential Revision: https://phabricator.services.mozilla.com/D14636
--HG--
extra : moz-landing-system : lando
Check whether web audio starts when calling calling resume() or
AudioScheduledNode.start() after granting user activation.
Differential Revision: https://phabricator.services.mozilla.com/D14332
--HG--
extra : moz-landing-system : lando
Wrap 'nsContentUtils::ReportToConsole()' to reduce necessary input parameters and call it when we need to log error or warning message. Show the warning when autoplay is blocked.
For web audio, this restores the console messages removed in part4 and also reports the same message when the AudioContext is blocked in the constructor.
Differential Revision: https://phabricator.services.mozilla.com/D14330
--HG--
extra : moz-landing-system : lando
AudioContext won't need to ask permission request anymore, and we will report error message in patch5.
Differential Revision: https://phabricator.services.mozilla.com/D14329
--HG--
extra : moz-landing-system : lando
These tests were added in bug 1493766 for testing caching temporary autoplay permission.
Differential Revision: https://phabricator.services.mozilla.com/D14326
--HG--
extra : moz-landing-system : lando
We're going to remove all autoplay temporary permission related codes, so we don't need to cache it anymore.
Differential Revision: https://phabricator.services.mozilla.com/D14325
--HG--
extra : moz-landing-system : lando
We made the profiler buffer resizable before that patch but then we decided that
it's not a good idea to do since we are spending so much time to allocate memory.
Since buffer size is constant, we don't need to add "max" anymore.
Differential Revision: https://phabricator.services.mozilla.com/D15656
--HG--
extra : moz-landing-system : lando
Per our discussion, this patch splits out the state management bits of
WebRenderLayerManager, allowing for them to be maintained per-document.
Differential Revision: https://phabricator.services.mozilla.com/D13577
--HG--
extra : moz-landing-system : lando
All that is really required for this ticket is to invoke |mach android
archive-geckoview| after |mach package| in the right place.
But it's actively unhelpful to have this magic in mozharness --
especially since the documentation in `locales.rst` is subtly
incorrect (the environment variables and Make variables don't quite
work as written). So this commit adds a Mach command to do the actual
work and replaces most of the mozharness magic with that command.
Since the l10n Make targets check out the l10n HG repositories
locally, this basically Just Works without the mozharness checkout
steps when developing locally.
Differential Revision: https://phabricator.services.mozilla.com/D12455
--HG--
extra : moz-landing-system : lando
At some point we made L10NBASEDIR required. That means that
env L10NBASEDIR=... make chrome-AB_CD
takes the value set by configure. That is different than
make chrome-AB_CD L10NBASEDIR=...
which uses the value passed on the command line. Rather than making
the latter style work with `mach build`, we instead set the "correct"
value for L10NBASEDIR in automation.
We could remove the --with-l10n-base stanzas from many automation
mozconfigs, but there's some small advantage to keeping them explicit.
Perhaps eventually we will remove them -- hopefully after
standardizing l10n vs l10n-central!
Differential Revision: https://phabricator.services.mozilla.com/D15776
--HG--
extra : moz-landing-system : lando
There's a guard to prevent action, but it's confusing to ask for it
and then not take the action. Let's not ask. I'm leaving the guard,
pointless as it should be, just in case.
Differential Revision: https://phabricator.services.mozilla.com/D14828
--HG--
extra : moz-landing-system : lando
As originally written, the keychain-backed secret storing implementation would
not overwrite a secret if prompted to generate or recover one with a label that
was already in use. Since libsecret and credential manager both do this by
default, this change makes the keychain-backed implementation behave the same
way.
Differential Revision: https://phabricator.services.mozilla.com/D15697
--HG--
extra : moz-landing-system : lando
