Bug 11775 – 'Show URLs in Tool Tips' preference is ignored

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKit Misc.

Summary:
The 'Show URLs in Tool Tips' behavior of a WebView is reset to the value in the standard preferences when a page is loaded, even if the WebView's own preferences specify a different value. Moreover, under certain conditions, it is impossible to change the behavior even after the page loaded by changing the WebView's preferences.

Steps to reproduce:
1) Download the attached archive and build WebViewToolTipBug.
2) Use WebKitTools/Scripts/run-webkit-app to run the WebViewToolTipBug application linked against a debug build of TOT WebKit.
3) In the application's window, select Show URLs in Tool Tips.
4) Press Return to load the first URL (an "A" link).
5) Move the mouse pointer over the "A" link and hold it still for a few seconds.
6) Deselect and reselect the Show URLs in Tool Tips option.
7) Move the mouse pointer over the "A" link and hold it still for a few seconds.
8) Select the second item from the combo box (a "B" link).
9) Move the mouse pointer over the "B" link and hold it still for a few seconds.
10) Click the Back button and immediately click the Forward button.
11) Wait for 5 seconds without moving the mouse or typing anything.
12) Click the Back button.
13) Move the mouse pointer over the "A" link and hold it still for a few seconds.
14) Deselect and reselect the Show URLs in Tool Tips option.
15) Move the mouse pointer over the "A" link and hold it still for a few seconds.

Expected results:
In steps 5, 7, 9, 13 and 15, a tool tip saying "about:blank" to appear after hovering over the link for a second or two.

Actual results:
In steps 5, 9, 13 and 15, a tool tip never appears when hovering over the link.

Regression:
The behavior in step 15 is a regression from shipping WebKit. See bug 11675 and bug 10808.

Notes:
1) setShowsURLsInToolTips is an SPI.
2) See bug 11675 comment #10 regarding the case of "reopened" WebHTMLViews (steps 10-15).
3) WebHTMLView caches the initial value when it's initialized, at which time it still doesn't have a data source and therefore doesn't have a WebView to take preferences from, so it takes the value from the standard preferences.

Created attachment 11761 [details]
Test app

Created attachment 12346 [details]
A fix

[Darin Adler]

Comment on attachment 12346 [details]
A fix

It's important to fix this! Mail.app uses it.

But I don't like the idea that setDataSource: does this as a side effect, even when the data source is not changing. Is there any better place to put this call?

r=me anyway

(In reply to comment #3)
> (From update of attachment 12346 [details] [edit])
> It's important to fix this! Mail.app uses it.
> 
> But I don't like the idea that setDataSource: does this as a side effect, even
> when the data source is not changing. Is there any better place to put this
> call?

I'm afraid not. viewDidMoveToSuperview is called before the data source (which is how the WebHTMLView gets at the WebView and the WebPreferences) is set. There is no explicit call that tells a WebDocumentView that it's been placed in a frame.

Thanks for the review!

Regarding "even when the data source is not changing", this is necessary (in this approach) because if the WebPreferencesChangedNotification is received while the view is not in a frame, it will reset its cached preferences based on the default preferences, making it necessary to reset the cache again in the otherwise no-op -setDataSource:. Again, there's no clear place to stop and resume listening for the notification, hence the need for this.

I don't think that this is a regression. It's possible that Mail.app works because it sets this in the default web preferences. Only per-webview preferences are ignored in this bug.

[Mark Rowe (bdash)]

Landed in r18756.