Bug 66564 – WebViews/WKViews without a window or host window use the main screen's backing scale factor, which may be undesirable

• Status: NEW
• Component: Layout and Rendering

[Adam Roben (:aroben)]

WebKit currently falls back to using the main screen's backing scale factor when it has no associated window. But since multiple screens and windows can have different backing scale factor, the main screen's backing scale factor isn't really relevant.

The main options I can think of when we have no window are:
1) Use a backing scale factor of 1
2) Use the highest backing scale factor of any screen
3) Use the lowest backing scale factor of any screen
4) Use the backing scale factor of the main screen if all screens have the same backing scale factor

(1) seems the simplest, so I think I'll go with that for now.

[Radar WebKit Bug Importer]

<rdar://problem/9983546>

[Darin Adler]

It seems clear to me that longer-term we may need to give WebKit clients explicit control over this. Only the client will know what it plans to do with the WebView. I don’t see a way for the view class to predict.

[Adam Roben (:aroben)]

Dave Harrison mentioned that we could also look at the scale factors at which the screens are capable of displaying, rather than just the scale factors they're currently using.

[Adam Roben (:aroben)]

Specifically, WebKit uses -[NSScreen mainScreen]. I previously though that this meant the screen with the menu bar on it. But the documentation says:

The main screen is not necessarily the same screen that contains the menu bar or has its origin at (0, 0). The main screen refers to the screen containing the window that is currently receiving keyboard events. It is the main screen because it is the one with which the user is most likely interacting.

I agree with Darin that we'll probably need a way for client apps to specify the scale factor for windowless WebViews. But it still would be good to have a good default policy in cases where the scale factor isn't specified. It might end up being easiest to match whatever AppKit does (i.e., what's the behavior of -[NSView convertPointToBacking:NSMakePoint(1, 1)] for windowless views?), but I don't know if that behavior is specified anywhere.

[Adam Roben (:aroben)]

I split out the special case of the view having a host window but not being in a window itself into bug 66587.

[Adam Roben (:aroben)]

Retitling to try to make it clearer that this is about WebKit's default behavior.

[Adam Roben (:aroben)]

(In reply to comment #2)
> It seems clear to me that longer-term we may need to give WebKit clients explicit control over this. Only the client will know what it plans to do with the WebView. I don’t see a way for the view class to predict.

This is now covered by bug 67150.