Summary: Switch to autograph mar hash signing.
Test Plan:
X pin nightly updates
_ autoland this patch
_ uplift this patch to central
_ wait for nightlies to spin
_ test nightlytest channel
_ unpin nightly updates
Reviewers: catlee
Tags: #secure-revision
Bug #: 1471197
Differential Revision: https://phabricator.services.mozilla.com/D8251
--HG--
extra : rebase_source : 755efd3d2cb350d9d70bb7841a0c173b6244384f
This patch makes EventStateManager handle middle click paste as a default
action.
Unfortunately, we cannot remove the call of HandleMiddleClickPaste() in
EditorEventListener because it's important to consume middle click event
before any elements in the editor. For example, if clicked HTMLEditor has
non-editable <a href> element, middle click event needs to be handled by the
editor rather than contentAreaUtils which handles click events of <a href>
elements. The cause of this kind of issues is, any click event handlers
which handle non-primary button events still listen to "click" events.
Therefore, this patch makes HandleMiddleClickPaste() do nothing if the mouseup
event is fired on an editor.
Differential Revision: https://phabricator.services.mozilla.com/D7855
--HG--
extra : moz-landing-system : lando
This is preparation of the last patch. Even if no editor is clicked with
middle button, we need to do:
- collapse Selection at the clicked point.
- dispatch "paste" event.
Therefore, HandleMiddleClickPaste() should dispatch ePaste event by itself
and each editor methods should have a bool argument which the caller wants
ePaste event automatically.
Note that Chromium dispatches "paste" event and pastes clipboard content
into clicked editor even if preceding "auxclick" event is consumed.
However, our traditional behavior is not dispatching "paste" event nor
pasting clipboard content. Unless Chromium developer keeps their odd
behavior, we should keep our traditional behavior since our behavior is
conforming to DOM event model.
Differential Revision: https://phabricator.services.mozilla.com/D7854
--HG--
extra : moz-landing-system : lando
The event argument of only EditorEventListener::MouseClick() can be replaced
with WidgetMouseEvent simply. So, for avoiding unnecessary RefPtr in
EditorEventListener::HandleEvent(), we should fix this now.
Differential Revision: https://phabricator.services.mozilla.com/D7853
--HG--
extra : moz-landing-system : lando
EventStateManager needs to handle middle click paste without editor.
Therefore, the handler should be in EventStateManager.
Differential Revision: https://phabricator.services.mozilla.com/D7852
--HG--
extra : moz-landing-system : lando
We need to move EditorEventListener::HandleMiddleClickPaste() into
EventStateManager to handle middle click paste after all click events are
dispatched. This is preparation of the change.
HandleMiddleClickPaste() uses UIEvent::GetRangeParent() and
UIEvent::RangeOffset() to collapse Selection at clicked point. However,
EventStateManager cannot access them since EventStateManager can handle it
with WidgetMouseEvent. Fortunately, only WidgetMouseEvent is necessary for
implementing them. Therefore, we can move the implementation into
nsLayoutUtils and merge them.
Differential Revision: https://phabricator.services.mozilla.com/D7851
--HG--
extra : moz-landing-system : lando
EventStateManager::InitAndDispatchClickEvent() sends given nsEventStatus to
nsIPresShell::HandleEventWithTarget(). Then, it sends the status to
EventStateManager::PreHandleEvent() before dispatching the event. At this
time, EventStateManager::PreHandleEvent() resets the state to
nsEventStatus_eIgnore. Therefore, for example, if eMouseClick event is
consumed but eMouseAuxClick is ignored, the event status result is
nsEventStatus_eIgnore. So, neither DispatchClickEvents() nor
PostMouseUpEventHandler() cannot check whether at least one click event
is consumed.
This patch makes EventStateManager::InitAndDispatchClickEvent() sends
local variable of nsEventStatus to nsIPresShell::HandleEventWithTarget().
Then, merge the result with current status.
If we'd change nsEventStatus to enum class, we could make this change as
custom "operator|=" or something.
Differential Revision: https://phabricator.services.mozilla.com/D7850
--HG--
extra : moz-landing-system : lando
This patch splits EventStateManager::CheckForAndDispatchClick(). One is for
handling default action of eMouseUp, the other is for dispatching click events.
This makes it easier to add other default actions after dispatching click
events.
Differential Revision: https://phabricator.services.mozilla.com/D7849
--HG--
extra : moz-landing-system : lando
Depends on D7875
I would like to make the adb addon dependency transparent to the scanner consumers
Differential Revision: https://phabricator.services.mozilla.com/D7876
--HG--
extra : moz-landing-system : lando
Depends on D7873.
This fixes the following scenario:
- install ADB
- connect a Device
- start about:debugging
=> device shows up in sidebar
- start WebIDE
=> device should show up in WebIDE
Differential Revision: https://phabricator.services.mozilla.com/D7875
--HG--
extra : moz-landing-system : lando
Depends on D7872. This fixes the bug where about:debugging thinks the addon
is uninstalled the first time it starts.
Differential Revision: https://phabricator.services.mozilla.com/D7873
--HG--
extra : moz-landing-system : lando
This allows to cleanly disable the scanner when you have several users.
Without this if you start both WebIDE and about:debugging, the first listeners
set in enable() can never be removed.
Differential Revision: https://phabricator.services.mozilla.com/D7872
--HG--
extra : moz-landing-system : lando
getter_AddRefs for nsCOMPtr does an AssertNoQueryNeeded check when its
temporary is destroyed. For the mReaderThread, this happens at a time when
control of the member variable has been handed over to the reader thread,
which causes a data race in the query needed check when the reader thread
shuts itself down and clears the member.
Switching to RefPtr solves this problem by removing the unnecessary check.
Differential Revision: https://phabricator.services.mozilla.com/D8135
--HG--
extra : rebase_source : 0532d152b6be57451e5729bf6b72e2056f3ed300
Summary:
This resolves the two problems of MediaRecorder:
1. MediaRecorder does not fire pause/resume events when the corresponding methods are called, as mentioned in D7910.
2. The WebIDL for MediaRecorder does not specify onpause/onresume event handler attributes neither.
DispatchSimpleEvent() is used because there are no event attributes needed.
Test Plan: The MediaRecorderTest.html attached in the bug report will be enough to test if the events work well as intended.
Reviewers: jya, bzbarsky
Reviewed By: jya, bzbarsky
Bug #: 1458538
Differential Revision: https://phabricator.services.mozilla.com/D7971
--HG--
extra : rebase_source : d010d5889a5395da0abbabb7067e8de516fc64f1
extra : histedit_source : 583e34b4990345bea28a7710b2e68fab4c32c233
