Re: Updated Presentation API WebIDL - call for review

On Tue, Mar 25, 2014 at 1:01 AM, Kostiainen, Anssi <
anssi.kostiainen@intel.com> wrote:

> 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.
>

Thanks for the detailed response and sorry for the late reply -

So it seems the approach that is satisfactory is to leave the placement of
the screen selection dialog up to the user agent.  If the UA wishes to
place the dialog within the viewport (as mobile Safari does with <input
type="file">) it can, but that's not going to be required by any part of
the Presentation API.


>
> > 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.]
>

I'm certainly not opposed to browsers using context menus if they feel
that's the best UX to expose this feature, as long as we're not making it
an implementation requirement.  I think it might make sense in certain
contexts, such as the context menu for a <video> element, but not as a
general mechanism to open up to the Web.  For example, how would the site
be able to create markup to populate the menu without being able to
enumerate all available screens?


>
> Thanks,
>
> -Anssi
>
>