RESOLVED DUPLICATE of bug 134822 88339
pointer/hover media queries should update dynamically 
https://bugs.webkit.org/show_bug.cgi?id=88339
Summary pointer/hover media queries should update dynamically
Rick Byers
Reported 2012-06-05 09:41:45 PDT
In theory whether or not a touch screen (or eventually mouse) is being used can change while a page is loaded. Eg. a window can be moved to another monitor. At the moment we assume the associated Setting is static and can't change. See https://bugs.webkit.org/show_bug.cgi?id=88270 for some discussion on this.
Attachments
Add attachment proposed patch, testcase, etc.
Rick Byers
Comment 1 2012-06-05 09:43:45 PDT
Adam/James - sounds like there is still debate over whether dynamic properties like touch/mouse belong in Settings or somewhere else. I'll plan leave them in Settings for now, unless we can come to some conclusion on where they should be instead.
Adam Barth
Comment 2 2012-06-05 11:40:47 PDT
Settings can change over time. Many ports have APIs for manipulating settings that they expose to third parties. The notion that settings are static is just incorrect.
Rick Byers
Comment 3 2012-06-05 18:56:05 PDT
Moving discussion from (mostly unrelated bug http://code.google.com/p/chromium/issues/detail?id=118173). Comment 18 by abarth@chromium.org, Today (57 minutes ago) ... Another interesting question is what to do about media queries when users plug and unplug a mouse from a touch-enabled device. Comment 19 by rbyers@chromium.org, Today (32 minutes ago) I've been assuming that plugging and unplugging a device is essentially the same (on the WK side anyway) as moving a window between a touch and non-touch screen. I was hoping we could just update the setting and trigger style recalc. Comment 20 by jamesr@chromium.org, Today (12 minutes ago) That's one interpretation, but it's not immediately obvious that it's the behavior we want - imagine some sort of bluetooth mouse that periodically gains/loses its connection, do we want to be constantly toggling this setting and perhaps changing the style on the page? --- That's an interesting scenario. I'm not sure how realistic it is that the ONLY mouse/trackpad device is that flaky (seems like the occasional website changing styles is perhaps the least of the user's frustration in this case). But the media query spec is intentionally worded to give the UA some freedom to determine what pointer it expects the user to use ("primary pointing device"). If such a case was an issue in practice, perhaps we need some heuristic so such a mouse isn't considered a primary pointer? At least that way the behavior will be more consistent (eg. opening a link to the same site in a new tab won't show different UI). This comes back to something I've been wondering about in the current implementation: what's the right level of abstraction here in the WebKit API. Do we really want WebCore to have the responsibility of determining the "least capable primary pointer device" based on low-level present/absent bits from the platform. Or is it better to plumb the entire decision up to the platform with a single 'getLeastCapablePrimaryPointer' API.
Adam Barth
Comment 4 2012-06-06 00:12:42 PDT
One way to think about those sorts of questions is to consider how you would approach this problem if you were programming directly to the Mac OS or iOS APIs rather than to a Chromium abstraction of the real OS APIs.
Rick Byers
Comment 5 2014-07-21 18:05:05 PDT
*** This bug has been marked as a duplicate of bug 134822 ***
Note You need to log in before you can comment on or make changes to this bug.