354124 - Flash plugin no longer works with JavaScript disabled

Status: RESOLVED WORKSFORME

(Core Graveyard :: Plug-ins, defect)

Description

[Ian Collier]

User-Agent:       Mozilla/5.0 (X11; U; SunOS sun4u; en-GB; rv:1.8.0.7) Gecko/20060919 SeaMonkey/1.0.5
Build Identifier: Mozilla/5.0 (X11; U; SunOS sun4u; en-GB; rv:1.8.0.7) Gecko/20060919 SeaMonkey/1.0.5

Since 1.8.0.7 visiting a page with a flash plug-in while JavaScript is disabled results in a blank rectangle where the animation should be.  Right-clicking shows that the plug-in has loaded but the content has not; that is, you get the Flash menu with "About Macromedia Flash 7" but it says "Movie not loaded".

The same profile works (i.e. displays the animation) in 1.8.0.6; it also works if you enable JavaScript and revisit the page in 1.8.0.7.

Reproducible: Always

Steps to Reproduce:
1. Start Mozilla with a new profile (but make sure Flash plug-in is registered)
2. Edit preferences and disable JavaScript in navigator
3. Go to any page with a flash animation - obviously one that doesn't require JavaScript (as a completely random example: http://www.youtube.com/v/pJsDfLndlKU)
Actual Results:  
a blank window

Expected Results:  
a flash animation

Using Flash player 7.0.66 for Sparc Solaris and Flash player 7.0.63 for i386 Linux.

The following browsers did not work:
Mozilla/5.0 (X11; U; SunOS sun4u; en-GB; rv:1.8.0.7) Gecko/20060919 SeaMonkey/1.0.5
Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.8.1b2) Gecko/20060921 SeaMonkey/1.1a
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/2006092404 Minefield/3.0a1

The following browsers *did* show the animation:
Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.8.0.6) Gecko/20060802 SeaMonkey/1.0.4
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.3) Gecko/20060504 Fedora/1.5.0.3-1.1.fc5 Firefox/1.5.0.3 pango-text

Comment 1

[Boris Zbarsky [:bzbarsky]]

Any idea when this regressed on the branch?  There should be nightly builds on ftp.mozilla.org and archive.mozilla.org for the branches...

Comment 2

[Bill Gianopoulos [:WG9s]]

This is either Linux only or is caused by some extension that controls flash execution like adblock or Flashblock.  I can not reproduce this under windows with no such extension installed.

Comment 3

[Bryan]

I can easily reproduce this issue when I disable javascript!  

Classic Menus for Winstripe 2.4
DOM Inspector 1.8.1
Download Manager Tweak 0.7.2 [DISABLED]
Fasterfox 1.0.3
Gmail Notifier 0.5.6.5
Menu Editor 1.2.2
Nightly Tester Tools 1.1
No Squint 0.9.1
OpenBook 1.3.4
Talkback 2.0
TextZoom 1.7.0

Those are my extensions...

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20060925 BonEcho/2.0 ID:2006092514

~B

Comment 4

[Boris Zbarsky [:bzbarsky]]

OK.  Which extension do you have to disable to make it work again?  Or is it also a problem in safe mode?

Comment 5

[Andrew Schultz]

this regressed between linux seamonkey trunk builds 2005091405 and 2005091504
I don't see anything relevant in that range, nor anything in common with what changed between 1.8.0.6 and 1.8.0.7

Comment 6

[Andrew Schultz]

actually, it helps to query the right year.  the common factor was bug 302737

Comment 7

[Boris Zbarsky [:bzbarsky]]

jst, any idea what could be happening here?  :(

Comment 8

[Bryan]

(In reply to comment #4)
> OK.  Which extension do you have to disable to make it work again?  Or is it
> also a problem in safe mode?

Boris,

I don't have to disable any extensions!  I experience the issue in SafeMode as well!!!

BUILD: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20060925 BonEcho/2.0 ID:2006092514

~B 

Comment 9

[Boris Zbarsky [:bzbarsky]]

So from Gecko's point of view here's what happens:

1)  The plugin tries to load a javascript: URI via NPN_GetURLNotify:

#3  0xb33c93c9 in nsPluginHostImpl::GetURL (this=0x896c238, pluginInst=0x899f5c0, 
    url=0xb3292940 "javascript:window.location+\"__flashplugin_unique__\"", target=0x0, 
    streamListener=0x8a13a78, altHost=0x0, referrer=0x0, forceJSEnabled=0)
    at ../../../../../mozilla/modules/plugin/base/src/nsPluginHostImpl.cpp:2845

2)  JS is disabled, so nsJSChannel::AsyncOpen throws.

This is where the patch for bug 302737 matters.  Without that patch, we completely ignore the failure of AsyncOpen and proceed to not clean up the listener until the plugin is torn down.

With the patch, we clean the listener up before returning from MakeNew4xStreamInternal, since all the refs to it are gone.  This calls ~ns4xPluginStreamListener which does:

224         NS_TRY_SAFE_CALL_VOID(CallNPP_URLNotifyProc(callbacks->urlnotify,
225                                                     npp,
226                                                     mNotifyURL,
227                                                     reason,
228                                                     mNotifyData), mInst->fLibrary, mInst);

with a |reason| of NPRES_NETWORK_ERR.  Which is correct in this case, as it happens -- there was an error trying to run the javascript: URI.

Now we go back to loading the main data for the plugin.  We end up in ns4xPluginStreamListener::OnDataAvailable for that data, then which does:

544           PRInt32 writeCount = 0; // bytes consumed by plugin instance
545           NS_TRY_SAFE_CALL_RETURN(writeCount, 
546                                   CallNPP_WriteProc(callbacks->write, npp,
547                                                     &mNPStream, streamPosition,
548                                                     numtowrite,
549                                                     ptrStreamBuffer),

The plugin returns 0 for the writeCount, which leads us to cancel the HTTP channel loading this data, since the plugin doesn't want to consume it.

So it looks like the flash plugin kills off everything if one of the NPN_GetURLNotify calls fails and things only used to work because we never told the plugin that the call failed?  Or am I misunderstanding the api here?  It's quite possible -- none of this stuff is documented that well.  :(

Comment 10

[Daniel Veditz [:dveditz]]

We'll take it in 1.8.0.8 if there's a fix that makes 1.8.1

Comment 11

[Jeff Mott]

This bug is UTR with our internal builds of Flash player 9 for Linux.  It works fine on both Firefox 1.5.0.5 and Mozilla 1.7.3 on a RHEL ES4 installation.

Comment 12

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Sounds like we should back out the leak fix from the branch.  How bad was the leak?

Comment 13

[Johnny Stenback (:jst)]

Yeah, seems like a backout is in order here, unfortunately :(

I never heard that the leak that bug 302737 was particularly bad, and it doesn't seem like it'd be, so backing it out seems like the best way to go here.

Comment 14

[Boris Zbarsky [:bzbarsky]]

(In reply to comment #11)
> This bug is UTR with our internal builds of Flash player 9 for Linux.  It
> works fine on both Firefox 1.5.0.5 and Mozilla 1.7.3 on a RHEL ES4
> installation.

Jeff, you need to use Firefox 1.5.0.7 or Firefox 2 RC1 or a trunk build.  This bug was not present in either Firefox 1.5.0.5 or Mozilla 1.7.3 -- see comment 0.

(In reply to comment #12)
> How bad was the leak?

Not very, I would guess...  At least if we generally clean up the listeners when the plugin gets torn down, which we seem to; not sure why we were not doing that on ESPN.

Comment 15

[Boris Zbarsky [:bzbarsky]]

Attachment: Branch backout

On trunk I'd like to sort out the Flash situation, instead.

Comment 16

[Johnny Stenback (:jst)]

Comment on attachment 240253 [details] [diff] [review]
Branch backout

r+sr=jst

Comment 17

[Mike Schroepfer]

Comment on attachment 240253 [details] [diff] [review]
Branch backout

Approved for RC2.   Let's get this in the branch asap .

Comment 18

[Mike Beltzner [:beltzner, not reading bugmail]]

Can we please get this checked in by EOD? Danke!

Comment 19

[Daniel Veditz [:dveditz]]

I cannot reproduce this in Firefox 1.5.0.7 on Windows with Flash 9. With Javascript turned off I can load the flash link in comment 0 just fine (many others don't work because the site detects the lack of JavaScript, but it's not a flash issue).

Is this bug specific to older versions of Flash, or to Unix builds somehow?

Comment 20

[Boris Zbarsky [:bzbarsky]]

> Is this bug specific to older versions of Flash, or to Unix builds somehow?

The only real way to check is to test an older Flash on Windows.  Given lack of Flash 9 for Unix, we're not really in a position to break older Flash if that's the problem.  :(

Comment 21

[Bryan]

(In reply to comment #19)
> I cannot reproduce this in Firefox 1.5.0.7 on Windows with Flash 9.
> Is this bug specific to older versions of Flash, or to Unix builds somehow?

I can easily reproduce this in Windows builds using the current version of flash (v9).

BUILD: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20060926 BonEcho/2.0 ID:2006092613

~B

Comment 22

[Boris Zbarsky [:bzbarsky]]

Checked in on the 1.8.1 branch.  Changing version to reflect that we still need a trunk fix one way or another.

Comment 23

[Daniel Veditz [:dveditz]]

Comment on attachment 240253 [details] [diff] [review]
Branch backout

approved for 1.8.0 branch, a=dveditz for drivers

Comment 24

[Boris Zbarsky [:bzbarsky]]

Checked in on 1.8.0 branch for 1.8.0.8.

Comment 25

[Marcia Knous [:marcia]]

verified on the 1.8.0 branch using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.8) Gecko/20061025 Firefox/1.5.0.8. I used the STR in the original report and was testing with Shockwave Flash 9.0 r16.

Comment 26

[Boris Zbarsky [:bzbarsky]]

Note that the backout probably causes bug 362603, so we really want to fix this the right way on trunk...

Comment 27

[Damon Sicore (:damons)]

Setting to B1 per conversation with JST.

Comment 28

[Johnny Stenback (:jst)]

Can anyone still reproduce this with the newest versions of flash? I'm not seeing this on Win32 or Linux with Flash 9.

Comment 29

[Wayne Mery (:wsmwk)]

would be better from somone who's seen it fail before, but FWIW, works for me javascript disabled, Shockwave Flash 9.0 r60, Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a5pre) Gecko/20070530 Minefield/3.0a5pre

Comment 30

[Andrew Schultz]

This worksforme with Flash 9.0 r31 on linux with a current trunk build as well as a 2006-09-25-trunk build that failed before.  Flash 7 still fails with current trunk.

Comment 31

[Johnny Stenback (:jst)]

Ok, marking this WORKSFORME then, we won't be chasing down problems that have already been addressed in existing versions of flash.