dragging of window stops if desktop notification gets shown
Categories
(Core :: Widget: Win32, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr91 | --- | unaffected |
firefox98 | --- | wontfix |
firefox99 | --- | wontfix |
firefox100 | --- | fix-optional |
People
(Reporter: aryx, Unassigned)
References
(Regression)
Details
(Keywords: regression)
If the user is dragging a window and a desktop notification starts to get shown, the dragging stops (I am not sure if there is a pattern: there are cases when the dragging operation seems to be cancelled and the window jumps back to its original position, and in other cases the dragging operation ended at the current position).
Steps to reproduce:
- Load a web page in a window which is not maximized.
- Open the browser console (Ctrl+Shift+Q)
- Open a second browser window not in maximized mode.
- Copy and paste the following code into the console (type "allow pasting" on the first attempt, then paste + press Enter again).
Notification.requestPermission().then(function(result) {
setTimeout(() => {
new Notification('To do list', { body: "body" });
}, 5000)
});
- In the next 5 seconds, start to drag the other window to a different position and wait for the desktop notification to be shown.
Actual result: Drag operation ends (window either at position when dragging started or fixed at position when desktop notification got shown).
Expected result: Drag operation continues.
Comment 1•3 years ago
|
||
I don't understand why you needinfo'd me - there doesn't appear to be a question here.
This is a trade-off because the lack of dragend
notifications can otherwise break web or Firefox drag operations (cf. bug 1593586).
It will be fixed if either we finally enable native Windows desktop notifications, or perhaps it might also be fixed if we do what Olli suggested in bug 1753861 comment 11.
I don't think this is worth prioritizing otherwise, and I don't think characterizing this as a regression is reasonable given the previous behaviour was at least as bad (the drag operation would also end, but it would result in broken browser or web app state). If this assessment is incorrect, please provide more details.
Updated•3 years ago
|
![]() |
Reporter | |
Comment 2•3 years ago
|
||
Needinfo you because I had been told authors of regression changes should be needinfoed in general.
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Comment 3•3 years ago
|
||
The severity field is not set for this bug.
:enndeakin, could you have a look please?
For more information, please visit auto_nag documentation.
Comment 4•3 years ago
|
||
There isn't a drag and drop operation occurring when moving a window though, so calling EndDragSession should have no effect.
Looks like the Windows version of EndDragSession calls ::ReleaseCapture without verifying that a drag is actually occurring. We should fix that.
Updated•2 years ago
|
Updated•2 years ago
|
Description
•