Re: Updated Presentation API WebIDL - call for review

Hi Mark, All,

On 25 Mar 2014, at 07:47, mark a. foltz <mfoltz@google.com> wrote:

> I have some concerns about giving the site control over the positioning of the screen selection dialog.  Allowing content to manipulate dialogs managed by the UA leads to a number of unfortunate corner cases and consequences:
> 
> - The user begin to expect that the dialog will appear within the page viewport, which then gives the page an opportunity to spoof it.  Not the greatest concern (as a spoofed screen selection dialog would not be able to do much) but I prefer not training users to confuse UA dialogs with page elements when more is at stake (permission requests, security warnings).

I was thinking of the spoofing case too but was unable to come up with an attack that would be harmful. But perhaps I was not thinking hard enough. Anyone?

Traditionally, the viewport has been a "browser chrome free zone” apart from things such as context menus. That is, the user trusts the browser chrome, while whatever represented in the viewport is untrusted. What follows is that web content has been unable to alter the browser chrome other than indirectly (i.e. invoke a permission prompt, indicate in the chrome if the web content e.g. plays sounds or uses a webcam).

That said, looking at the implementation of the dialog for the <input type=“file”> on iPad, browser chrome UI elements do appear inside the viewport already in some implementations. This may not be a concern, as a spoofed “pick a file” or “pick a screen” dialog might actually be harmless, especially if there’s still another step in the flow that requires user’s consent as is the case with the iPad IIUC.

I’d like to note the permissions for Web APIs is a generic issue, although this API serves as a good testbed. Thus I’d suggest we do not rat-hole too deeply into the subject at this time, and instead revisit the issue when we have other parts more ironed out.

For interested folks, there’s a Web and Mobile Interest Group Task Force looking at this:

  https://www.w3.org/wiki/Mobile/Work#TASK_FORCE:_Permissions

To get an idea of the breadth and pervasiveness of the issue, see the first stab at the permission mechanisms matrix at:

  http://dontcallmedom.github.io/web-permissions-req/matrix.html

> - The <button type="screens"> element could be hidden, located offscreen, or near a screen border, the UA would have to handle all these cases.

Yes, you are correct, it is hard to anticipate all the cases, also things such as setting the button opacity close to zero, resizing to fill the screen and the list goes on.

AFAIK <input type=“file”> has some limitations on many implementation what comes to styling for this specific reason, but developers do not seem to like that, as I’ve noticed many sites are trying to working around that using synthetic click()s with custom buttons.

> - Constraints for mobile (small screen, touch friendly) mean that placement and UX for the dialog is highly constrained and the position of the <button type"screens"> element would likely be ignored.  Consistent treatment of the dialog (always handled by the UA) for desktop and mobile would make behavior predicable for developers and users.

This is what I argued initially is a good reason in itself to leave this up to the UA.

> Regarding the context menu proposal, I have some concerns from a discoverability point of view - how would a user know which elements supported the requestSession context menu item?

The issue is generic to context menus. Perhaps the users should be trained that certain elements can have context menus? Trial and error? Long tap / right click here for more awesomeness?

I see your point that regular users do not understand the concept of site customized context menus on the Web, but I think that is due to the fact the feature has not been widely implemented yet in browsers. But when the feature is made available in more browsers and sites take it into use, I’d expect people to learn. Touch wasn’t a perfect fit for the Web either at first (think issues such as the click delay due to double tap compatibility etc.) but nowadays it does work much better on modern implementations.

> Also context menus (as they are typically implemented on desktop) are not the most touch- or mobile-friendly.  Perhaps there are some additional mocks in the HTML 5.1 draft that show a touch friendly version.

I’m not aware of any additional mockups for touch specifically. Doesn’t e.g. Chrome on Android already use context menus for example saving images on the pages? It would be just a matter of extending that to allow custom items in the menu.

[From Wikipedia I learned context menus first appeared in the Smalltalk environment on the Xerox Alto computer released 1973 ;-) I’m not surprised if they do not translate perfectly to our touch-driven mobile world. That said, on desktop they’re prevalent, and they can be made to work on mobile as well. I think we need more data. The best way to do that would be to implement and ship the feature (behind a runtime flag?) and try it out with real people.]

Thanks,

-Anssi

Received on Tuesday, 25 March 2014 08:04:58 UTC