869603 - Dealing with plugin content for Metro v1

Status: RESOLVED DUPLICATE of bug 738600

(Firefox for Metro Graveyard :: Browser, defect)

Description

[Brian R. Bondy [:bbondy]]

This bug is to discuss how we will deal with flash content in v1, without the web feeling broken to end users of the Metro browser.
 
I think we decided the NPAPI plugin route was not going to happen.

Some suggestions discussed are:
1. Having a click to play like interface that would launch the current page in Desktop.
2. Using Shumway ( https://github.com/mozilla/shumway ).  bsmedberg mentioned this could be ready enough as early as July.
3. Simply don't load Flash content

Comment 1

[Jim Mathies [:jimm]]

I'd say let layout handle it as it does now. I really don't notice missing plugins at all when I surf. We also have the app bar launch on desktop option already so it seems to me we are in good shape as is.

We can experiment with shumway when it's ready but I'd suggest we not mess with it until we get past v1.

Comment 2

[Benjamin Smedberg]

I disagree rather strongly. We know that people routinely run into sites which require Flash (and perhaps other plugins). e.g. restaurant menus, pizza order forms, etc. I'll assert that your browsing pattern is atypical of most users!

When they do hit that situation, we should provide a way for them to get the content they need. Otherwise they're just going to try the same site in IE, discover it works, and not look back.

Comment 3

[Jim Mathies [:jimm]]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #2)
> I disagree rather strongly. We know that people routinely run into sites
> which require Flash (and perhaps other plugins). e.g. restaurant menus,
> pizza order forms, etc. I'll assert that your browsing pattern is atypical
> of most users!

You've described how I use this tablet pretty well actually, when I dog food it sits in the living room / kitchen. I really haven't run into any major issue. The most annoying problem is video on sites like youtube, which is currently hit or miss for html5 content depending on the video.

> When they do hit that situation, we should provide a way for them to get the
> content they need. Otherwise they're just going to try the same site in IE,
> discover it works, and not look back.

We have an option for opening a site on desktop through the app bar so if users want flash they can open a browser that has it. We also plan to do a nice tour start page that can mention this.

We could consider click-to-play style panels in content for this however I'm concerned they would riddle content. Might be worth testing something like that to see how bad the user experience is. Most web sites seem to do a pretty good job of detecting and swapping out flash for non-plugin content. So maybe the panels wouldn't be visible very often.

The other key issue here is to try and avoid adding additional (complex) work for v1.

Comment 4

[Brian R. Bondy [:bbondy]]

I may be wrong but I think if we did a click-to-play type of solution, then we would be sending that we accept flash content via the HTTP Accept header.  And then youtube would send us flash instead of HTML5 (when it has HTML5).

But we want HTML5 video. Is there a way for us to prefer HTML5 video and tell websites like youtube that, but then allow flash content if HTML5 video is not available?

Comment 5

[Benjamin Smedberg]

I don't think we ever send Flash via the accept header.

You're probably thinking about navigator.plugins, but we have control over that API. And in this case the Flash plugin is not available, so it wouldn't show up in about:plugins. This isn't "click to play" it's "click to reload in desktop mode".

Comment 6

[Brian R. Bondy [:bbondy]]

Ya I just verified with fiddler, it was just a guess about advertising flash support via the Accept header. Seems it's only via js, which would still detect no support in Metro.