Summary: | 'Show URLs in Tool Tips' preference is ignored | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | mitz | ||||||
Component: | WebKit Misc. | Assignee: | Nobody <webkit-unassigned> | ||||||
Status: | RESOLVED FIXED | ||||||||
Severity: | Normal | CC: | beidson, ddkilzer, sullivan | ||||||
Priority: | P2 | ||||||||
Version: | 420+ | ||||||||
Hardware: | Mac | ||||||||
OS: | OS X 10.4 | ||||||||
Attachments: |
|
Description
mitz
2006-12-07 07:44:13 PST
Created attachment 11761 [details]
Test app
Created attachment 12346 [details]
A fix
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. |