1560587 - status panel doesn't always dismiss when switching tabs

Status: VERIFIED FIXED

(Core :: Layout, defect)

Description

[Andrew Swan [:aswan]]

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)

Comment 1

[Andrew Swan [:aswan]]

mozregression points to
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=af96bd1090b523679af7dc0274b5842b68adfcd6&tochange=b3417a0b019fa428a2edbf79683ed5b2260c14cd

Comment 2

[Andrew Swan [:aswan]]

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?

Comment 3

[Kartikaya Gupta (email:[e-mail])]

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.

Comment 4

[Kartikaya Gupta (email:[e-mail])]

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.

Comment 5

[Kartikaya Gupta (email:[e-mail])]

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.

Comment 6

[Kartikaya Gupta (email:[e-mail])]

Attachment: Bug 1560587 - Remove incorrect event redirection. r?tnikkel

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.

Comment 7

[Kartikaya Gupta (email:[e-mail])]

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

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/92a3a2e17fdb
Remove incorrect event redirection. r=tnikkel

Comment 9

[Andrei Ciure[:aciure]]

https://hg.mozilla.org/mozilla-central/rev/92a3a2e17fdb

Comment 10

[Julien Cristau [:jcristau]]

Comment on attachment 9073638 [details]
Bug 1560587 - Remove incorrect event redirection. r?tnikkel

regression fix for 68.0b14

Comment 11

[Julien Cristau [:jcristau]]

https://hg.mozilla.org/releases/mozilla-beta/rev/a9beb454bd6c

Comment 12

[Alexandru Trif, QA [:atrif]]

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

[:Gijs (he/him)]

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:[e-mail]) 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.

Comment 14

[Kartikaya Gupta (email:[e-mail])]

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

[Alexandru Trif, QA [:atrif]]

This issue is verified fixed using Firefox 68.0b14 (20190627143605) on Windows 10x64, Ubuntu 18.04 and macOS 10.14.