This commit implements the actual UI changes. A follow-up commit adds the
tests for the changes. The CSS is a little bit awkard since it uses lots of
ID selectors rather than class selectors. I wanted to be able to write quick
selects, since it's selecting across the entire browser document. I feel
a little conflicted with the approach, as I would prefer to use classes in
general.
The panel.jsm.js file collects all of the UI handling changes rather than
having everything in menu-button.jsm.js, as the latter can get loaded
at startup. I'm not sure if it's completely worth the trouble of having
two files, as most of it should be pretty light.
This commit does not handle localization for the panel, as we should be moving
to Fluent. Rather than solve that here, I will follow-up with it in Bug 1599774.
Differential Revision: https://phabricator.services.mozilla.com/D62914
--HG--
extra : moz-landing-system : lando
Instead of updating the Bookmark This Page / Edit Bookmark menuteitems on popupshowing,
update them when the star button is suppposed to change. This better supports MacOS behavior
where the native menubar can't be updated after being shown, and avoids many callpoints in
favor of just a few.
Differential Revision: https://phabricator.services.mozilla.com/D64399
--HG--
extra : moz-landing-system : lando
This commit implements the actual UI changes. A follow-up commit adds the
tests for the changes. The CSS is a little bit awkard since it uses lots of
ID selectors rather than class selectors. I wanted to be able to write quick
selects, since it's selecting across the entire browser document. I feel
a little conflicted with the approach, as I would prefer to use classes in
general.
The panel.jsm.js file collects all of the UI handling changes rather than
having everything in menu-button.jsm.js, as the latter can get loaded
at startup. I'm not sure if it's completely worth the trouble of having
two files, as most of it should be pretty light.
This commit does not handle localization for the panel, as we should be moving
to Fluent. Rather than solve that here, I will follow-up with it in Bug 1599774.
Differential Revision: https://phabricator.services.mozilla.com/D62914
--HG--
extra : moz-landing-system : lando
This commit implements the actual UI changes. A follow-up commit adds the
tests for the changes. The CSS is a little bit awkard since it uses lots of
ID selectors rather than class selectors. I wanted to be able to write quick
selects, since it's selecting across the entire browser document. I feel
a little conflicted with the approach, as I would prefer to use classes in
general.
The panel.jsm.js file collects all of the UI handling changes rather than
having everything in menu-button.jsm.js, as the latter can get loaded
at startup. I'm not sure if it's completely worth the trouble of having
two files, as most of it should be pretty light.
This commit does not handle localization for the panel, as we should be moving
to Fluent. Rather than solve that here, I will follow-up with it in Bug 1599774.
Differential Revision: https://phabricator.services.mozilla.com/D62914
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
This patch was generated with a script. It doesn't include all files:
- Files that use the preprocessor or fail to parse are skipped
- Files that are loaded as JSMs but don't use the .jsm extension are skipped (those will be renamed in Bug 1609269)
It was generated with the following command using d855222aa2/no-this-property-read.js:
```
hg revert --all &&
cp .gitignore .rgignore &&
rg --files-without-match -g '*.jsm' '^#endif|^#include|^#filter' | jscodeshift --stdin --transform ~/Code/jsm-rewrites/no-this-property-read.js --ignore-pattern ./mobile/android/modules/Sanitizer.jsm --ignore-pattern ./js/xpconnect/tests/unit/syntax_error.jsm &&
./mach eslint `hg st | rg '^M ' | sed 's/^M //'`
```
Differential Revision: https://phabricator.services.mozilla.com/D60187
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
`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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
