`dragleave` isn't triggered when canceling a drag and drop with the escape key on Linux
Categories
(Core :: Widget: Gtk, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr78 | --- | unaffected |
firefox-esr91 | --- | unaffected |
firefox93 | --- | unaffected |
firefox94 | --- | fixed |
firefox95 | --- | verified |
People
(Reporter: julienw, Assigned: stransky)
References
(Blocks 1 open bug, Regression)
Details
(Keywords: regression)
Attachments
(2 files)
(deleted),
text/html
|
Details | |
(deleted),
text/x-phabricator-request
|
RyanVM
:
approval-mozilla-beta+
|
Details |
STR:
- Open the testcase.
- Drag a file on top of the orange block, notice it turns red.
- Press escape before dropping.
=> it's still red, but it should be orange.
The problem is that we don't get a "dragleave" event in this case.
Chrome works fine with this testcase.
I believe this is specific to Linux.
Reporter | ||
Comment 1•3 years ago
|
||
Reporter | ||
Updated•3 years ago
|
Reporter | ||
Comment 2•3 years ago
|
||
So this works in v93 but not v94, so this looks like a regression.
mozregression seems to point to bug 1731737.
Martin, does that ring a bell?
Updated•3 years ago
|
Comment 3•3 years ago
|
||
Gnome Xwayland, Debian Testing, Intel Macbook Pro
mozregression --repo try --launch 43d967728f9298aa9e0e9531677e500c8642c49d -a https://bugzilla.mozilla.org/attachment.cgi?id=9245502
try build from bug 1730533 comment 13:
- It seems to fix bug 1733283, but would bug 1730533 be uplifted to beta, the regressing bug be backed out or something else be done?
- This bug is still reproducible.
Reporter | ||
Comment 4•3 years ago
|
||
(In reply to Darkspirit from comment #3)
Gnome Xwayland, Debian Testing, Intel Macbook Pro
mozregression --repo try --launch 43d967728f9298aa9e0e9531677e500c8642c49d -a https://bugzilla.mozilla.org/attachment.cgi?id=9245502
yeah, I confirm that this build doesn't fix this issue for me.
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Updated•3 years ago
|
Reporter | ||
Updated•3 years ago
|
Comment 5•3 years ago
|
||
Set release status flags based on info from the regressing bug 1731737
Assignee | ||
Comment 6•3 years ago
|
||
mScheduledTask means scheduled task. When there's nothing sheduled we look inactive but that's not correct.
Let's remove that check as it was before.
Updated•3 years ago
|
Assignee | ||
Comment 7•3 years ago
|
||
We should back port that to beta - it juts reverts the scheduled task check and reverts the code to state in FF93.
Assignee | ||
Comment 9•3 years ago
|
||
try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=70c7e9ef6a6e6e8c46f5f6dc224a0445433d67b0
Comment 10•3 years ago
|
||
Pushed by stransky@redhat.com: https://hg.mozilla.org/integration/autoland/rev/cde05c7f07d6 [Linux] Don't check D&D status by mScheduledTask as it's misleading, r=emilio
Comment 14•3 years ago
|
||
bugherder |
Comment 15•3 years ago
|
||
The patch landed in nightly and beta is affected.
:stransky, is this bug important enough to require an uplift?
If not please set status_beta
to wontfix
.
For more information, please visit auto_nag documentation.
Assignee | ||
Comment 16•3 years ago
|
||
Comment on attachment 9245943 [details]
Bug 1735348 [Linux] Don't check D&D status by mScheduledTask as it's misleading, r?emilio
Beta/Release Uplift Approval Request
- User impact if declined: Broken D&D operations on Linux.
- Is this code covered by automated tests?: No
- Has the fix been verified in Nightly?: No
- Needs manual test from QE?: No
- If yes, steps to reproduce:
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): Reverts D&D leave handler to state of Firefox 93.
- String changes made/needed:
Updated•3 years ago
|
Comment 17•3 years ago
|
||
Comment on attachment 9245943 [details]
Bug 1735348 [Linux] Don't check D&D status by mScheduledTask as it's misleading, r?emilio
Approved for 94.0b8.
Comment 18•3 years ago
|
||
bugherder uplift |
Updated•3 years ago
|
Updated•3 years ago
|
Comment 19•3 years ago
|
||
Managed to reproduce the issue using an older version of Nightly from 2021-10-12 on Ubuntu 18.04 x64.
Verified the fix on latest Nightly 95.0a1 and Firefox 94.0b8 using the same platform. The bug is fixed on beta.
However on Nightly the square doesn't turn red.
Comment 20•3 years ago
|
||
Bug was reintroduced 3 days after comment 14: bug 1736523
Comment 21•3 years ago
|
||
I will take out the qe-verify + tag from this issue considering that is nothing we can do here at the moment.
Description
•