[whatwg] communicating plugin state (primarily for click-to-play)
Ashley Sheridan
ash at ashleysheridan.co.uk
Tue Jun 12 13:26:11 PDT 2012
On Tue, 2012-06-12 at 13:18 -0700, Peter Kasting wrote:
> On Tue, Jun 12, 2012 at 1:07 PM, Glenn Maynard <glenn at zewt.org> wrote:
>
> > On Tue, Jun 12, 2012 at 1:22 PM, Peter Kasting <pkasting at 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
More information about the whatwg
mailing list