205817 - Pages with flash animations not loading

Status: VERIFIED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Tracy Walker [:tracy]]

seen with commercial trunk builds:

windows 2003-05-15-04-trunk
linux 2003-05-15-05-trunk
mac 2003-05-15-03-trunk

-load any page with a flash animation
notice that in many cases the entire page doesn't load. The flash animation also
doesn't load.  some pages have flash animations that are displayed in pop up
windows. Those windows just remain blank.

Comment 1

[Peter Lubczynski]

did this happen in yesterday's builds?

Comment 2

[Tracy Walker [:tracy]]

yesterdays early AM builds were fine

Comment 3

[Peter Lubczynski]

ok, I'm updating now.....possible suspects from bonsai to try backing out
include the change to nsObjectFrame.cpp and the fix to bug 130265.

Comment 4

[Peter Lubczynski]

hm...the changes to nsObjectFrame.cpp have to do with visibility. 

Tracy, do you "hear" Flash if going to a site like http://www.flashsound.com/

Comment 5

[Tracy Walker [:tracy]]

no sound.  no animation to the right of the welcome message

yesterdays build had sound and animation of headphones and equalizer

Comment 6

[Johnny Stenback (:jst)]

Are any javascript: URL's involved? If so, could be related ot the fix for bug
130265 (checked in yesterday).

Comment 7

[Simon Montagu :smontagu]

Backing out bug 130265 from today's trunk build makes flash work for me.

Comment 8

[Peter Lubczynski]

yup, I see a NPP_GetURLNotify("javascript:window.location[....] in the log. 
my build is almost done

Comment 9

[Peter Lubczynski]

ok, I see what's going on in the debugger. When plugin specifies a target of
NULL in NPP_GetURL[Notify], the browser gives the response directly to the
plugin rather than displaying in a window. 

In this case, the plugin request a javascript: URL during initilization, while
we are still loading it's SRC url. In nsJSChannel::AsyncOpen, EvaluateScript
succeededs and the new code in StopAll is called, canceling the other data
stream to the plugin.

Any ideas on how to fix this or should we back out bug 130265 to get the tree open?

Comment 10

[Peter Lubczynski]

Attachment: stack leading up to StopAll()

Comment 11

[Peter Lubczynski]

commenting out the call to StopAll seems to do the trick

Comment 12

[Johnny Stenback (:jst)]

Attachment: Proposed fix, untested. Don't stop loads for non-document URI's

Comment 13

[Peter Lubczynski]

Comment on attachment 123433 [details] [diff] [review]
Proposed fix, untested. Don't stop loads for non-document URI's

tested, Flash works great! r=peterl

Comment 14

[Johnny Stenback (:jst)]

Comment on attachment 123433 [details] [diff] [review]
Proposed fix, untested. Don't stop loads for non-document URI's

Darin says sr=darin.

Comment 15

[Peter Lubczynski]

fix in

Comment 16

[Asa Dotzler [:asa]]

Comment on attachment 123433 [details] [diff] [review]
Proposed fix, untested. Don't stop loads for non-document URI's

a=asa (on behalf of drivers) for checkin to 1.4

Comment 17

[Tracy Walker [:tracy]]

verified with respins on;
windows 2003-05-15-12-trunk
linux 2003-05-15-12-trunk

Comment 18

[Darin Fisher]

*** Bug 205841 has been marked as a duplicate of this bug. ***