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.
<rdar://problem/9983546>
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.
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.
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.
I split out the special case of the view having a host window but not being in a window itself into bug 66587.
Retitling to try to make it clearer that this is about WebKit's default behavior.
(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.