Bug 11775 - 'Show URLs in Tool Tips' preference is ignored
Summary: 'Show URLs in Tool Tips' preference is ignored
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit Misc. (show other bugs)
Version: 420+
Hardware: Macintosh OS X 10.4
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-12-07 07:44 PST by mitz
Modified: 2007-01-10 21:01 PST (History)
3 users (show)

See Also:


Attachments
Test app (17.25 KB, application/octet-stream)
2006-12-07 07:46 PST, mitz
no flags Details
A fix (2.24 KB, patch)
2007-01-10 10:06 PST, mitz
darin: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description mitz 2006-12-07 07:44:13 PST
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.
Comment 1 mitz 2006-12-07 07:46:00 PST
Created attachment 11761 [details]
Test app
Comment 2 mitz 2007-01-10 10:06:15 PST
Created attachment 12346 [details]
A fix
Comment 3 Darin Adler 2007-01-10 10:47:28 PST
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
Comment 4 mitz 2007-01-10 11:06:13 PST
(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!
Comment 5 mitz 2007-01-10 11:11:13 PST
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.
Comment 6 mitz 2007-01-10 11:14:30 PST
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.
Comment 7 Mark Rowe (bdash) 2007-01-10 21:01:34 PST
Landed in r18756.