Bug 1517241 renamed nsIDocument to mozilla::dom::Document but unfortunately in
the process it messed up the ordering of includes which, according to the coding
style[1], should be alphabetically sorted.
Also, in TimingParams.cpp it didn't add the dom::* prefix so when the unified
build chunking changes, if the "using namespace mozilla::dom" declaration
disappears from the chunk, it will fail to build.
[1] https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#CC_practices
Depends on D15902
Differential Revision: https://phabricator.services.mozilla.com/D15903
--HG--
extra : moz-landing-system : lando
As of bug 1203009 / changeset 37b6deedaab6 and per spec, we no longer reset the
animation index when an Animation re-enters the idle state and kNoIndex is no
longer defined.
Depends on D15898
Differential Revision: https://phabricator.services.mozilla.com/D15899
--HG--
extra : moz-landing-system : lando
The staging balrog server got reset to match production, so update the rules to match.
Differential Revision: https://phabricator.services.mozilla.com/D15764
--HG--
extra : moz-landing-system : lando
There are 2 parts of the patch:
1) we should not try to use websockets over h2 if we already know that they are not supported.
2) make sure that we clean up websockets waiting for the settings frame when we close a h2 connection. (the part 1) will fix the issue, this part is only to be 100% that we some how do not retrigger the issue)
Differential Revision: https://phabricator.services.mozilla.com/D15296
--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
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
