Add support for a hidden preference named app.update.notifyDuringDownload
that, when set to true, causes a "Downloading update" message to appear
in the app menu during a MAR download. Clicking the message opens the
about box so the user can see detailed progress information.
Differential Revision: https://phabricator.services.mozilla.com/D77688
This is what I see when running the test:
console.log: Changing zoom for browser from 1 to 0.5
set fullZoom@chrome://global/content/elements/browser-custom-element.js:812:19
set fullZoom@chrome://browser/content/tabbrowser.js:526:7
ZoomManager_setZoomForBrowser@chrome://global/content/viewZoomOverlay.js:60:7
set zoom@chrome://global/content/viewZoomOverlay.js:49:10
@chrome://mochitests/content/browser/browser/components/customizableui/test/browser_947914_button_zoomReset.js:26:5
Async*Tester_execTest/<@chrome://mochikit/content/browser-test.js:1039:34
Tester_execTest@chrome://mochikit/content/browser-test.js:1074:11
nextTest/<@chrome://mochikit/content/browser-test.js:904:14
SimpleTest.waitForFocus/waitForFocusInner/focusedOrLoaded/<@chrome://mochikit/content/tests/SimpleTest/SimpleTest.js:918:23
"FullZoomChange for browser"
PASS Zoom reset button exists in Panel Menu -
console.log: Changing zoom for browser from 0.5 to 1
console.log: set fullZoom@chrome://global/content/elements/browser-custom-element.js:817:19
ZoomManager_setZoomForBrowser@chrome://global/content/viewZoomOverlay.js:60:7
FullZoom__applyPrefToZoom@chrome://browser/content/browser-fullZoom.js:479:19
FullZoom_onLocationChange@chrome://browser/content/browser-fullZoom.js:247:14
XWB_onUpdateCurrentBrowser@chrome://browser/content/browser.js:5419:16
callListeners@chrome://browser/content/tabbrowser.js:820:31
_callProgressListeners@chrome://browser/content/tabbrowser.js:834:22
_callProgressListeners@chrome://browser/content/tabbrowser.js:5776:46
onStateChange@chrome://browser/content/tabbrowser.js:6039:14
_callProgressListeners@resource://gre/modules/RemoteWebProgress.jsm:75:31
onStateChange@resource://gre/modules/RemoteWebProgress.jsm:88:10
Which is pretty broken (the zoom is reset way earlier than clicking the reset
button, by FullZoom.onLocationChange).
This seems to me was mostly passing by chance, but with my Fission changes
which made FullZoomChange events more async (and actually, not notify twice) it
started failing.
Wait to load a page before changing the zoom level so that the browser doesn't
reset it when navigating.
Differential Revision: https://phabricator.services.mozilla.com/D72208
This removes the annotation from the following tests:
browser/base/content/test/general:
- browser_bug735471.js by removing the test
- browser_clipboard.js which seems like it's not using CPOWs anyway
- browser_blockHPKP.js which is disabled and isn't using CPOWs anyway
browser/components/customizableui/test:
- browser_934951_zoom_in_toolbar.js as CPOW usage was removed in bug 962248
toolkit/components/reader/test:
- browser_readerMode_with_anchor.js as CPOW usage was already removed in bug 1492482
toolkit/content/tests/browser:
- browser_datetime_datepicker.js as CPOW usage was removed in bug 1492482
- browser_saveImageURL.js which used deprecated CPOW-only APIs that I removed in an earlier cset
It also removes all the test framework code relying on this annotation.
Depends on D70685
Differential Revision: https://phabricator.services.mozilla.com/D70686
On Mac, ctrl-click will send a context menu event from the widget, so we don't
want to bring up the panel when ctrl key is pressed.
Differential Revision: https://phabricator.services.mozilla.com/D66397
On Mac, ctrl-click will send a context menu event from the widget, so we don't
want to bring up the panel when ctrl key is pressed.
Differential Revision: https://phabricator.services.mozilla.com/D66397
Before this patch, we change aDraggedItemId somewhat late in the _applyDrop method -
significantly, we do this after the aTargetNode == areaCustomizationTarget check. So
we end up bailing out before adjusting aDraggedItemId, and we add the specific dummy
item from the palette into the toolbar, rather than adding a new spring to the
toolbar, and leaving the existing palette item alone.
Simply moving this adjustment to aDraggedItemId earlier into the method is sufficient
to fix the issue at hand.
Differential Revision: https://phabricator.services.mozilla.com/D62948
All usage of `synthesizeDragStart()` is, starting drag, cancel `dragstart`,
and finally compares `dataTransfer` items and given expected data. So,
we can make the users use `synthesizePlainDragAndDrop()` instead. It's
better API because it computes position of mouse operations at runtime and
checks whether the drag start was succeeded with optional logging feature
(i.e., it's easier to debug of intermittent failures).
This patch creates `synthesizePlainDragAndCancel()` for convenience. It
handles `dragstart` instead of the callers.
Differential Revision: https://phabricator.services.mozilla.com/D58214
`synthesizePlainDragAndDrop()` synthesizes drag events with `DataTransfer`
object which is set to `DragEvent.dataTransfer` of `dragstart` after starting
drag session explicitly. However, this causes
`EventStateManager::DoDefaltDragStart()` does not initialize `nsIDragService`
instance. Therefore, synthesized drag events cannot work with editor because
`DragEvent::GetMozSourceNode()` returns `nullptr` due to
`nsIDragSession::GetSourceNode()` returning `nullptr`.
On the other hand, synthesized drag events cannot use
`nsIDragService::InvodeDragSession()` normally because of hitting an assertion.
https://searchfox.org/mozilla-central/rev/690e903ef689a4eca335b96bd903580394864a1c/widget/nsBaseDragService.cpp#230-233
This patch does:
- mark drag events caused by synthesized mouse events as "synthesized for tests"
- make `synthesizePlainDragAndDrop()` stop using
`nsIDragService.startDragSession()`
- make `nsBaseDragService` initialize and start session even for synthesized
`dragstart` event
- make `synthesizePlainDragAndDrop()` stop synthesizing drag events with
`DataTransfer` object since it's normal behavior and it'll be initialized
with `nsIDragService::GetDataTransfer()`
- make `nsBaseDragService` store `effectAllowed` for the session only when
it's synthesized session because it's required at initializing synthesized
default `dropEffect` value of `dragenter`, `dragover`, `dragexit` and `drop`
events' `dataTransfer`
- make all tests which use `nsIDragService.startDragSession()` use new
API, `nsIDragService.startDragSessionForTests()` to initialize session's
`effectAllowed` value
- make `EventStateManager::PostHandleEvent()` set drag end point of the test
session to `eDrop` event's screen point
- make `synthesizePlainDragAndDrop()` set drag end point of the session if
it does not synthesize `drop` event because following `endDragSession()`
use it at dispatching `dragend` event on the source element
Additionally, this adds `dumpFunc` new param to `synthesizePlainDragAndDrop()`
because it's really useful to investigate the reason why requesting DnD isn't
performed as expected.
Differential Revision: https://phabricator.services.mozilla.com/D57425
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
