Bug 204735 – [PSON] Tooltips from previous page shown on new page

• Component: WebKit2
• Status: RESOLVED FIXED

[Michael Catanzaro]

We're having trouble with tooltips from a previously-loaded webpage being displayed for a new unrelated web page after loading a new page in the web view. It's easy to reproduce using the Epiphany overview. Hover your mouse cursor over any of the overview items to display a tooltip. Then, using the keyboard, Ctrl+L to focus the address bar, type in any web address, e.g. https://www.gnome.org, and hit Enter to load the page.

With 2.26, the tooltip appears on the new page, but only until the mouse is moved. As soon as the mouse is moved, the tooltip disappears and never comes back.

With 2.27.3, the tooltip has developed aggressive zombie tendencies. It just doesn't want to die 🧟. Move the mouse, it will come back again and again. To avoid the bug, you can hover over some element of the new web page that displays a tooltip and our zombie tooltip will finally die. For example, using https://www.gnome.org as our second page load, you can hover over the GNOME foot in the top-left to get rid of the zombie tooltip. I remember this when testing 2.27.2 and maybe also 2.27.1, so it's an earlier regression. I just never managed to figure out how to reproduce it until now.

[Michael Catanzaro]

Well I went to bisect this, but I was able to reproduce the bug in my personal JHBuild environment even when using a pre-2.26 commit of WebKit. So my assumption that the WebKit version difference was to blame for the regression was wrong.

Bug is reproducible with: Epiphany Tech Preview (using 2.27.3), Michael's personal JHBuild environment

Not reproducible with: Fedora 31 system Epiphany

[Michael Catanzaro]

Sorry, I think this in an Epiphany regression.

[Michael Catanzaro]

(In reply to Michael Catanzaro from comment #2)
> Sorry, I think this in an Epiphany regression.

OK, the problem is PSON. I bisected it in Epiphany to the Epiphany commit reenabling PSON.

[Carlos Garcia Campos]

This is not GTK specific. The problem is that WebPage (in the wbe process) is caching the tooltip text to avoid sending IPC messages when the tooltip didn't change. When a new web process is used for the same web view, the tooltip text doesn't really change (it's always null) until a new one is set.

[Carlos Garcia Campos]

Created attachment 384612 [details]
Patch

[youenn fablet]

Can we add a test?

[Carlos Garcia Campos]

Created attachment 384613 [details]
Patch

[Carlos Garcia Campos]

(In reply to youenn fablet from comment #6)
> Can we add a test?

I thought about it, but we don't have public API to get the current tooltip text to make a unit test. And I'm not sure it's possible with a layout test either.

[Chris Dumez]

Comment on attachment 384613 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=384613&action=review

> Source/WebKit/ChangeLog:8
> +        The problem is that WebPage (in the wbe process) is caching the tooltip text to avoid sending IPC messages when

Typo: wbe

[Michael Catanzaro]

Comment on attachment 384613 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=384613&action=review

Thanks.

> Source/WebCore/page/ChromeClient.h:210
> +    virtual void mouseDidMoveOverElement(const HitTestResult&, unsigned modifierFlags, const String&, TextDirection) = 0;

The const String& parameter here should be named ("toolTip") since it's not clear from the type what it's for.

[Chris Dumez]

(In reply to Michael Catanzaro from comment #10)
> Comment on attachment 384613 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=384613&action=review
> 
> Thanks.
> 
> > Source/WebCore/page/ChromeClient.h:210
> > +    virtual void mouseDidMoveOverElement(const HitTestResult&, unsigned modifierFlags, const String&, TextDirection) = 0;
> 
> The const String& parameter here should be named ("toolTip") since it's not
> clear from the type what it's for.

+1, good catch.

[Carlos Garcia Campos]

Committed r253028: <https://trac.webkit.org/changeset/253028>

[Radar WebKit Bug Importer]

<rdar://problem/57585196>