Pages with flash animations not loading

VERIFIED FIXED

Status

()

Core
Plug-ins
--
blocker
VERIFIED FIXED
15 years ago
15 years ago

People

(Reporter: tracy, Assigned: Peter Lubczynski)

Tracking

({regression, smoketest})

Trunk
regression, smoketest
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

15 years ago
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.
(Assignee)

Comment 1

15 years ago
did this happen in yesterday's builds?
Status: NEW → ASSIGNED
(Reporter)

Comment 2

15 years ago
yesterdays early AM builds were fine
(Assignee)

Comment 3

15 years ago
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.
(Assignee)

Comment 4

15 years ago
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/
(Reporter)

Comment 5

15 years ago
no sound.  no animation to the right of the welcome message

yesterdays build had sound and animation of headphones and equalizer
Are any javascript: URL's involved? If so, could be related ot the fix for bug
130265 (checked in yesterday).
Backing out bug 130265 from today's trunk build makes flash work for me.
(Assignee)

Comment 8

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

Comment 9

15 years ago
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?
(Assignee)

Updated

15 years ago
Blocks: 130265
(Assignee)

Comment 10

15 years ago
Created attachment 123431 [details]
stack leading up to StopAll()
(Assignee)

Comment 11

15 years ago
commenting out the call to StopAll seems to do the trick
Created attachment 123433 [details] [diff] [review]
Proposed fix, untested. Don't stop loads for non-document URI's
(Assignee)

Comment 13

15 years ago
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
Attachment #123433 - Flags: review+
Comment on attachment 123433 [details] [diff] [review]
Proposed fix, untested. Don't stop loads for non-document URI's

Darin says sr=darin.
Attachment #123433 - Flags: superreview+
(Assignee)

Comment 15

15 years ago
fix in
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED

Comment 16

15 years ago
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
Attachment #123433 - Flags: approval1.4+
(Reporter)

Comment 17

15 years ago
verified with respins on;
windows 2003-05-15-12-trunk
linux 2003-05-15-12-trunk
Status: RESOLVED → VERIFIED

Comment 18

15 years ago
*** Bug 205841 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.