Re: [whatwg] communicating plugin state (primarily for click-to-play)

On Tue, 2012-06-12 at 13:18 -0700, Peter Kasting wrote:

> On Tue, Jun 12, 2012 at 1:07 PM, Glenn Maynard <glenn@zewt.org> wrote:
> 
> > On Tue, Jun 12, 2012 at 1:22 PM, Peter Kasting <pkasting@google.com>wrote:
> >
> >> The "temporary" implementation
> >> should probably be along the lines of "reload the page, this time allowing
> >> all plugins".  As noted already in this thread, simply allowing plugins
> >> after script has already tried to start them and communicate simply won't
> >> work a lot of the time.
> >>
> >
> > Not according to the model Adam suggested: a plugin that hasn't yet
> > received permission to start acts like a plugin that simply hasn't loaded
> > yet.
> >
> 
> It's important to distinguish solutions for authors versus solutions for
> UAs.  Authors should try and code according to Adam's model.  However, for
> pages which don't, UAs may still need to direct users to reload the page.
> 
> I don't support Glenn's suggestion to show a larger prompt when a plugin
> >> instance isn't visible, for two reasons.  One is that determining
> >> visibility it, in the limit, impossible.
> >
> >
> > What matters is if the visibility detection is 1: web-compatible (matches
> > up with what websites are doing with plugins that have in-page UI vs.
> > script-only plugins) and 2: well-defined, not whether you can detect that a
> > plugin is visible in every case.
> >
> > #1 may be impossible, though, especially if it's not known to the browser
> > in advance whether the plugin has UI.  It's probably better to just always
> > show a prompt bar.
> >
> 
> Not only that, but your point 2 again is only accurate when speaking of
> pages where the authors are trying to work with click-to-play and thus are
> ware of the visibility rules and take them into account.  However, the
> feature needs to also work well with other sites which don't take these
> rules into account, meaning that for those pages, you're reduced to the
> non-computable case.
> 
> The second is that the purpose of
> >> this feature is generally to reduce annoyance; showing prompts atop the
> >> window is annoying, especially if it happens frequently.
> >>
> >
> > The entire purpose of those non-modal prompts is to be unintrusive and out
> > of the way.  That style of prompting is designed exactly for this sort of
> > thing.
> >
> 
> As a member of Chrome's UI team I can assure you that getting an infobar on
> every page that has a blocked plugin leads to fury in about ten minutes.
>  This is why our indicators are icons that appear in the "page action" area
> of the Chrome omnibox.  This is unobtrusive enough to not be annoying.
>  Unfortunately it's also unobtrusive enough to leave less-expert users
> baffled.
> 
> Also, pages should not be required to create placeholder areas inside pages
> > to give the browser a place to prompt; it's the browser's job to do that
> > for itself (again with prompt bars, doorhangers, and the like).  That's
> > especially true because the page has no way of knowing whether the browser
> > is actually going to prompt (it may not use confirmations for the plugin
> > being used, or the user may have clicked "yes, always" on a previous
> > session).  This belongs out-of-line.
> >
> 
> It's often easy for a page to give the plugin a temporary visible location
> and hide it once the plugin actually loads, without the user noticing
> anything in the common case where permission has been implicitly or
> explicitly granted.  As I said, this isn't always possible.
> 
> PK


What about doing what popular plugin blockers do and offer the
notification in the area the plugin was intended to be used? I know it
won't work for all plugins (e.g. those too small or ones that don't
offer a visible area) but it would be intuitive in the main.

-- 
Thanks,
Ash
http://www.ashleysheridan.co.uk

Received on Tuesday, 12 June 2012 20:23:16 UTC