818802 - sView NPAPI plugin destroyed immediately if URL stream is blocked by returning error code

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[kirill]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20100101 Firefox/17.0
Build ID: 20121128204232

Steps to reproduce:

sView plugin (http://www.sview.ru/en/download on Windows platform) blocks automatically created stream by returning NPERR_INVALID_URL to NPP_NewStream() call (to manage streams manually).


Actual results:

This cause unexpected and undocumented behavior since Firefox 17 - plugin destroyed immediately after initialization.



Expected results:

Plugin shouldn't be destroyed if its initialization performed well.

Comment 1

[neils]

This is a very serious issue for our website (http://www.mtbs3D.com).  The sView plugin lets us show our 3D images in 3D on AMD HD3D, Nvidia 3D Vision, and all remaining 3D solutions.  With one Firefox update, this seriously handicapped our ability to show 3D content the way it's meant to be seen.

I suspect this change has negatively impacted other plugins too.  Please have this fixed ASAP because it's a serious loss for us.

Regards,
Neil

Comment 2

[Matthias Versen [:Matti]]

What are the Steps to reproduce. Installing the plugin and ding what ?
I can't do a regression range search without STR

Comment 3

[neils]

(In reply to Matthias Versen (Matti) from comment #2)
> What are the Steps to reproduce. Installing the plugin and ding what ?
> I can't do a regression range search without STR


The easiest method is to visit http://www.mtbs3D.com with Firefox.

1. Go here:

http://www.mtbs3d.com/index.php?option=com_content&view=article&id=13222:mtbs-reviews-the-asus-g75vw-3d-laptop&catid=35&Itemid=73

2. You should see an anaglyph picture.  Click on "3D Stereo" at the top of the picture.

Normally, it would open the sView program via plugin, or if you don't have sView installed, it would prompt you to download it.  In this case, the window is just blank (black).

Even if you don't own a 3D monitor, the sView program can still be run using anaglyph mode or other 2D options.  Owning 3D equipment is not required to test this out.

The sView plugin and program can be downloaded here:

http://www.sview.ru/en/download

However, if the plugin was working properly, it would have pointed you there anyway if the software wasn't yet installed.

Regards,
Neil

Comment 4

[Benjamin Smedberg]

This is an interesting change in behavior, but I tend to think that Firefox is behaving more correctly now. The job of a plugin is to display embedded content from a particular URL. If the plugin returns an error code handling the URL, then we decide that it is not prepared to handle the embedded content.

Why does the plugin refuse to load the embedded data URL?

This is almost certainly a change resulting from bug 745030 (refactor nsObjectLoadingContent). Can you use this tool: http://mozilla.github.com/mozregression/ and see whether the regression range for nightly builds is between the 7th and 8th of August, which would match bug 745030?

Comment 5

[Matthias Versen [:Matti]]

Last good nightly: 2012-08-07
First bad nightly: 2012-08-08

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1bbc0b65dffb&tochan
ge=e55638d4037a

Comment 6

[John Schoenick [:johns]]

I think I *just* found and fixed this exact issue yesterday in my patches for bug 767633.

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #4)
> This is an interesting change in behavior, but I tend to think that Firefox
> is behaving more correctly now. The job of a plugin is to display embedded
> content from a particular URL. If the plugin returns an error code handling
> the URL, then we decide that it is not prepared to handle the embedded
> content.

I would think so too, but it doesn't match the behavior of other browsers or even other situations in firefox :(

For instance, <embed src="./blah" type="application/x-shockwave-flash"> will instantiate flash and then pass it the ./blah channel as its first streamlistener - leaving flash running if that stream doesn't succeed. However, if we're hooking the channel in nsObjectLoadingContent to sniff its content type prior to spawning the plugin, *then* we take the return of that call into account. (<object data="./blah" type="application/x-shockwave-flash">).

I'm working on an updated set of patches in 767633 that makes both of these codepaths saner

Comment 7

[kirill]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #4)
> This is an interesting change in behavior, but I tend to think that Firefox
> is behaving more correctly now. The job of a plugin is to display embedded
> content from a particular URL. If the plugin returns an error code handling
> the URL, then we decide that it is not prepared to handle the embedded
> content.
> 
> Why does the plugin refuse to load the embedded data URL?
Data attribute pointed to the main image to display. However object may have optional data-prv-url attribute which point to down-scaled image ('preview').
If preview image is available plugin blocks stream for full-sized image and loads preview image to reduce traffic and memory usage. When user switch to full-screen mode plugin load full-sized image.

It could be done with another design (point data to preview image and add attribute to full-sized image) but this will broke compatibility with other plugins, old version of this plugin which have no knowledge about optional attributes and requires update on websites as well.

Comment 8

[neils]

I was just wondering if there have been any updates on this front.  My site has been without 3D for a few days.  I downloaded Firefox Beta 18, but it didn't make a difference to my website's 3D compatibility.

Regards,
Neil

Comment 9

[Benjamin Smedberg]

You'll see any updates in the bug. I believe that johns has decided that we should fix this bug to be compatible with other browsers. And he assigned it to himself, which is a good sign for you! I do not expect that we will fix this in Firefox 18, but it's more likely that we will uplift the fix into Firefox 19.

Comment 10

[John Schoenick [:johns]]

bug 767633 will fix this issue, and I can look into a simpler subset thereof to land in 19, but as bsmedberg noted, it is unlikely to get fixed in 18.

A workaround for this is using the embed tag along with an explicit type, e.g.:
> <embed type="application/x-your-plugin" src="some/file.dat">

If the embed tag matches your plugin by type (or file extension) it will instantiate the plugin prior to opening the channel, meaning you can reject the channel without failing initialization.

Comment 11

[John Schoenick [:johns]]

Neil, can you give the latest nightly build a shot and see if everything seems to be working as expected again now that bug 822040 and bug 767633 are fixed?

Comment 12

[John Schoenick [:johns]]

Ack, didn't mean to resolve this quite yet

Comment 13

[neils]

Hi John!

Thanks for your work on this.  Using the Nightly build, I'm able to get 3D running on our site again which is great to see.

Thanks for your team's hard work, and happy holidays!

Regards,
Neil

Comment 14

[John Schoenick [:johns]]

Thanks for reporting this and helping test, Neil!

Comment 15

[John Schoenick [:johns]]

Thanks to Kirill for reporting this, and Neil for helping test, rather :)