The creation of a new index or an object store may trigger a
ConstraintError if any of those elements already exists. Unfortunately,
the information provided by the ConstraintError is not enough to
determine the conditions that triggered the error.
This patch overrides the generic ConstraintError message with more
specific information about the duplicated index or object store.
The WG rejected this extension.
--HG--
rename : dom/canvas/test/webgl-mochitest/ensure-exts/test_WEBGL_compressed_texture_es3.html => dom/canvas/test/webgl-mochitest/ensure-exts/test_WEBGL_compressed_texture_etc.html
The sandbox blocks GetTempFileName's prior response, causing the system to end up searching a number of (inaccessible) folders to use as a replacement for the temp folder. This patch provides a path to a new folder on the command line for the plugin process. This new temp folder, specific to this plugin process instance, is then communicated to the system via the TEMP/TMP environment variables. This is similar to what is done for the content process but avoids nsDirectoryService, which doesn't exist in plugin processes.
Differential Revision: https://phabricator.services.mozilla.com/D7532
--HG--
extra : moz-landing-system : lando
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
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
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
P2 changed the way the H264Converter would be calling the decoder. The assumption in the EMEDecryptor was pretty incorrect to start with.
Depends on D7865
Differential Revision: https://phabricator.services.mozilla.com/D7882
--HG--
extra : moz-landing-system : lando
When used with the LowLatency option, we guarantee that the stream will contain no B-frame, as such we can reduce the re-ordering queue to zero. The apple VT decoder already returns frames in decode order making this change trivial.
Depends on D7861
Differential Revision: https://phabricator.services.mozilla.com/D7862
--HG--
extra : moz-landing-system : lando
The H264Converter can be used on a thread that isn't a nsThread or a TaskQueue, so having the H264Converter dispatching tasks isn't going to work
So instead we run all the code on the decoder's taskqueue using promise chaining.
All internal methods are made to assert that they are running on the task queue accordingly
Depends on D7860
Differential Revision: https://phabricator.services.mozilla.com/D7861
--HG--
extra : moz-landing-system : lando
The service workers spec mandates that calling ServiceWorkerRegistration.update()
on a registration whose newest worker is in the 'installing' state fail immediately.
This commit implements this requirement and tests it.
Differential Revision: https://phabricator.services.mozilla.com/D5241
--HG--
extra : moz-landing-system : lando
Check if we have permission from the OS to access the camera and microphone after the user has granted access to a site.
If permission is denied at the OS level, but granted to the site within Firefox, return NotFoundError.
Differential Revision: https://phabricator.services.mozilla.com/D5458
--HG--
extra : moz-landing-system : lando
This was a bug in the original design that just hadn't shown up yet.
If I were to listen to, say "notification-a", and then try to remove
my listener for "notification-a" and "notification-b", we would end
up with a dead listener staying in the list. This fixes that.
MozReview-Commit-ID: KhYQSJaBDF9
Differential Revision: https://phabricator.services.mozilla.com/D4605
--HG--
extra : moz-landing-system : lando