status panel doesn't always dismiss when switching tabs
Categories
(Core :: Layout, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr60 | --- | unaffected |
firefox67 | --- | unaffected |
firefox67.0.1 | --- | unaffected |
firefox68 | + | verified |
firefox69 | --- | verified |
People
(Reporter: aswan, Assigned: kats)
References
(Regression)
Details
(Keywords: regression)
Attachments
(1 file)
47 bytes,
text/x-phabricator-request
|
jcristau
:
approval-mozilla-beta+
|
Details | Review |
If the status panel (the gray box in the lower left corner of the content area that appears while hovering over a link) is visible and you switch to a new tab, the status panel remains visible displaying the link from the original (no longer visible) tab.
Hovering over a link in the new tab does the right thing (the status panel shows the new link and is then dismissed when the pointer leaves the new link)
Reporter | ||
Comment 1•2 years ago
|
||
mozregression points to
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=af96bd1090b523679af7dc0274b5842b68adfcd6&tochange=b3417a0b019fa428a2edbf79683ed5b2260c14cd
Reporter | ||
Comment 2•2 years ago
|
||
This isn't very high impact, but it could be the same cause as bug 1550637...
:kats, I'm over my head with the low-level event stuff here, do you have any thoughts?
Assignee | ||
Comment 3•2 years ago
|
||
Hm, that seems odd to me. I would have expected my change to only affect the nested browser case. I can do some quick investigation, assigning to myself for now.
Assignee | ||
Comment 4•2 years ago
|
||
Ah, looks like it's a result of the change at https://hg.mozilla.org/integration/autoland/rev/b3417a0b019fa428a2edbf79683ed5b2260c14cd#l1.95 which I didn't expect to impact anything, but apparently we're changing a zero layers id to a nonzero layers id there and so the mouse event ends up getting routed differently.
Assignee | ||
Comment 5•2 years ago
|
||
Yeah I think the mMouseEventTargetGuid we're getting the layers id from is stale after doing a tabswitch, and so the mouse event ends up getting sent to the old content process. If I remove that line everything works as expected, because the event is dispatched via the presShell
's remote browser which is the one we want to send it to. Given that I only added that line for "completness" I'll just take it out. That's a simple fix that should be safe to uplift.
Assignee | ||
Comment 6•2 years ago
|
||
In this codepath, the parent process may be sending an event to a particular
content process. The last-saved mouse target might be stale, and using that
to redirect the event can result in the event getting sent to the wront content
process. Deleting this erroneous change restores correct behaviour.
Assignee | ||
Comment 7•2 years ago
|
||
Comment on attachment 9073638 [details]
Bug 1560587 - Remove incorrect event redirection. r?tnikkel
Beta/Release Uplift Approval Request
- User impact if declined: When switching tabs, the status panel showing a link URL from the old tab may stick around until a new link is hovered.
- Is this code covered by automated tests?: No
- Has the fix been verified in Nightly?: No
- Needs manual test from QE?: Yes
- If yes, steps to reproduce: See comment 0 of the bug
- List of other uplifts needed: none
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): Partial revert of an unnecessary change in the regressing bug.
- String changes made/needed: none
Assignee | ||
Updated•2 years ago
|
Pushed by kgupta@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/92a3a2e17fdb Remove incorrect event redirection. r=tnikkel
Updated•2 years ago
|
Comment 9•2 years ago
|
||
bugherder |
Updated•2 years ago
|
Comment 10•2 years ago
|
||
Comment on attachment 9073638 [details]
Bug 1560587 - Remove incorrect event redirection. r?tnikkel
regression fix for 68.0b14
Updated•2 years ago
|
Comment 11•2 years ago
|
||
bugherderuplift |
Comment 12•2 years ago
|
||
Hello,
Reproduced the issue using Firefox 69.0a1 (20190621214126) on Windows 10 x64.
The issue is verified fixed using Firefox 69.0a1 (20190626215508) on Windows 10x64, Ubuntu 18.04 and macOS 10.14.
Comment 13•2 years ago
|
||
Would this also explain the issues people have been seeing with tooltips (bug 1550637 et al.) which shows/hides based on mouse events and seems to have started not hiding tooltips whose opening "races" with a tabswitch? This:
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #5)
Yeah I think the mMouseEventTargetGuid we're getting the layers id from is stale after doing a tabswitch, and so the mouse event ends up getting sent to the old content process.
makes me think "yes", but I'm not really that familiar with this code.
Assignee | ||
Comment 14•2 years ago
|
||
It's possible, although I'm pretty sure I've encountered bug 1550637 even before my regressing patch landed. But without STR it's hard to say one way or the other, and I don't know enough of the code to answer either. It could be caused by my patch, or maybe my patch just increased the frequency of a pre-existing problem. It might be worth polling the people who reported encountering it in bug 1550637 and checking if they still see it after this fix.
Comment 15•2 years ago
|
||
This issue is verified fixed using Firefox 68.0b14 (20190627143605) on Windows 10x64, Ubuntu 18.04 and macOS 10.14.
Description
•