Closed Bug 1560587 Opened 5 months ago Closed 5 months ago

status panel doesn't always dismiss when switching tabs

Categories

(Core :: Layout, defect)

defect
Not set

Tracking

()

VERIFIED FIXED
mozilla69
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)

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)

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?

See Also: → 1550637

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: nobody → kats
Flags: needinfo?(kats)

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.

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.

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 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
Attachment #9073638 - Flags: approval-mozilla-beta?
Pushed by kgupta@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/92a3a2e17fdb
Remove incorrect event redirection. r=tnikkel
Component: General → Layout
Product: Firefox → Core
Status: NEW → RESOLVED
Closed: 5 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla69
QA Whiteboard: [qa-triaged]

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

regression fix for 68.0b14

Attachment #9073638 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

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.

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.

Flags: needinfo?(kats)

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.

Flags: needinfo?(kats)

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

Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.