Bug 25525 – [Gtk] Tooltips should be fully keyboard accessible

• Status: RESOLVED
• Resolution: FIXED
• Component: Accessibility

[Joanmarie Diggs]

Steps to reproduce:

1. Load the test case (https://bugs.webkit.org/attachment.cgi?id=29966&action=view)

2. Hover the mouse over the "Phone number" link. This will cause the tooltip associated with that link to appear. Leave the mouse pointer there.

3. Press Tab until focus is on the Submit button.

4. Press Ctrl+F1 (the traditional Gtk app command to show/hide the tooltip associated with the focused item).

Expected results: The tooltip associated with the Submit button would be displayed -- and ideally displayed near the Submit button.

Actual results: The tooltip associated with the "Phone number" link is displayed -- and, at least on my system, displayed at the bottom of the window.

Comments: The reason for wanting Ctrl+F1 to toggle the visibility of the tooltip associated with the focused object is so that users who prefer to (or need to) use the keyboard instead of the mouse can access the title attribute information.

The reason for wanting it displayed in the vicinity of the focused object is for users with low vision who currently have to do additional visual work to locate the desired information.

[Alejandro G. Castro]

This bug depends on bug 32819. After applying that patch we would have to do a small workaround to solve the fact that the tooltips in GTK when opened with Ctrl+F1 are rendered outside and under the widget area (makes sense when the widget is a line of text for instance).

The best option would be probably to allow users to redefine the x and y properties in the query-tooltip, but it seems the API does not allow it; and anyway we need the position of the focused element of the webpage and we do not have it. We would have to wait for the DOM bindings, bug 16401, and check how to change the position of the tooltip if possible at all.

[Joanmarie Diggs]

Alex, since the bugs you mention seem to be fixed, is this something that can be tackled now?

[Alejandro G. Castro]

(In reply to comment #2)
> Alex, since the bugs you mention seem to be fixed, is this something that can
> be tackled now?

I'm afraid we have to check how we could do fix a couple of things before because I think gtk+ positions the tooltip under the widget when you use Ctrl+F1 (in this case the widget is the webview) and there is not API to change it. And in webkit the tooltip is not associated with the focused element but with the mouse position, but I did not check it in detail. We still need to check those things in order to fix the bug, I'll try to check them.

[Joanmarie Diggs]

(In reply to comment #3)
> (In reply to comment #2)
> > Alex, since the bugs you mention seem to be fixed, is this something that can
> > be tackled now?
> 
> I'm afraid we have to check how we could do fix a couple of things before
> because I think gtk+ positions the tooltip under the widget when you use
> Ctrl+F1 (in this case the widget is the webview) and there is not API to change
> it. And in webkit the tooltip is not associated with the focused element but
> with the mouse position, but I did not check it in detail. We still need to
> check those things in order to fix the bug, I'll try to check them.

Thanks!!

Depending on what you find.... I wonder if this could (should?) be broken into two separate bugs:

1. Ctrl+F1 should cause the tooltip to appear.... somewhere :-)

2. The tooltip should appear next to the focused element to be consistent with Gtk+

If item #1 is solved, users who are blind could then cause the tooltip to appear (which a screen reader could then speak and display in braille). This is the important thing IMHO.

[Carlos Garcia Campos]

Created attachment 72925 [details]
Patch to fix tooltip location and text when using the keyboard

Attached patch fixed the text and position of the tooltip when using the keyboard. It uses the current focused element to get its location and title. I'm not sure the title is enough, but it fixes the test case attached to this report. There are two issues blocking this though:

 - GTK+ bug: https://bugzilla.gnome.org/show_bug.cgi?id=633974
 - https://bugs.webkit.org/show_bug.cgi?id=48986

[Carlos Garcia Campos]

Comment on attachment 72925 [details]
Patch to fix tooltip location and text when using the keyboard

Now that bug #48986 is fixed this patch can be committed, it still won't work because of the gtk+ issue, but it's not more broken than current code, at least now it will show the right tooltip although wrongly positioned.

[Xan Lopez]

Comment on attachment 72925 [details]
Patch to fix tooltip location and text when using the keyboard

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

r- for always using main frame, which I think is wrong.

> WebKit/gtk/webkit/webkitwebview.cpp:1634
> +

I think you want to use focusedOrMainFrame()from FocusController here?

[Carlos Garcia Campos]

Created attachment 74836 [details]
Updated patch using focusedOrMainFrame()

[Xan Lopez]

Comment on attachment 74836 [details]
Updated patch using focusedOrMainFrame()

r=me

[Carlos Garcia Campos]

Created attachment 75013 [details]
New patch that converts tooltip area to window coords

[WebKit Commit Bot]

Comment on attachment 75013 [details]
New patch that converts tooltip area to window coords

Clearing flags on attachment: 75013

Committed r72789: <http://trac.webkit.org/changeset/72789>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.