Bug 186210
| Summary: | Access to screen properties should go through the ChromeClient | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Sam Weinig <sam> |
| Component: | New Bugs | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | bdakin, darin, simon.fraser, thorton |
| Priority: | P2 | ||
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
Sam Weinig
Right now, we have a hodgepodge of ways to get properties about the screen a view/page is on, mostly going through free functions in PlatfromScreen.h. This is inconsistent with the way we get most other information about the properties of a view (in this case, the property is what screen it is on). We usually ask the LegacyWebKit/WebKit layer to provide that information via the ChromeClient. Converting screen property access to go through the ChromeClient would also have the added benefit of allowing easier testing of these screen properties by adding SPI to override in either layout tests or API tests.
My proposal is to move the functions currently in PlatformScreen.h to ChromeClient, and implement them in the WebKitLegacy/WebKit layer.
For WebKit, this will mean proactively pushing the full set of screen properties for the screen the WKWebView/WKView is currently in and updating it if it moves between screens or the screens properties change (e.g. the resolution is switched). When the view is not in a window, we can continue our strategy of using the main screen.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |