35777 - Page blanks out when window with Macromedia Flash (SWF) movie is resized

Status: VERIFIED FIXED

(Core :: Layout, defect, P1)

Description

[Troy Evans]

Macromedia Flash (SWF) movie disappears when browser window is resized.
This creates a a re draw problem with the browser and displays the <embed> tag

1. - Open any Macromedia Flash (SWF)movie and view the content
- i.e www.macromedia.com or www.oddcast.com
2. - resize the browser window

Macromedia Flash (SWF) content is scalabel vector information and is designed 
to resized on the fly and demand

Comment 1

[shrirang khanzode]

I see this..changing summary.

Comment 2

[ekrock's old account (dead)]

Marking with flash keyword.

Comment 3

[shrirang khanzode]

os: all. seen on mac also.

Comment 4

[Eli Goldberg]

Confirming bug (per 16125)

Comment 5

[Adam]

This also happens when windowshading (minimizing) the window = problem with 

redrawing Flash content to screen.

Comment 6

[leger]

Putting on [nsbeta2+] radar.  

Comment 7

[av (gone)]

Attachment: Stack trace

Comment 8

[av (gone)]

Does not seem like a plugin bug. Layout gives negative height for window 
dimensions. It stops at the debug assert. Creating attachment with the call 
stack.

Comment 9

[av (gone)]

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

Comment 10

[buster]

I'll take a look.

Comment 11

[buster]

the problem is with the calculated height of the span containing the object.  it 
causes the object to compute a negative height for itself.

see 
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/html/base/src/nsInlin
eFrame.cpp#502

Comment 12

[buster]

I've got this one.  Problem is in nsObjectFrame.cpp.  We are trying to account 
for the margins when calculating the percent height of the plugin.  But we are 
blindly trying to get the margin from the parent, and the parent isn't 
necessarily the right place to get this information from.  In the case of 
www.oddcast.com, the parent is an inline frame, and the y-offset of the parent 
is a large negative number. So the line:

h -= 2*rect.y;

resulted in a negative height, which is illegal.  I changed the code to use the 
object's containing block, which is the nearest parent block that has meaningful 
margin information.

I'm not convinced that this code is doing the right thing, so I've cc'd av.  For 
one thing, it assumes the top and bottom margin are the same (2*rect.y).   
Wouldn't it be better to ask the containingBlock for it's margin, and subtrack 
out top and bottom separately?

I'll attach a patch for av's review. One step at a time:  let's get this fix 
reviewed and checked in, and you can worry about the rest of it.

Something analogous should be done for the horizontal dimension as well.

Comment 13

[buster]

Attachment: patch that fixes the immediate problem

Comment 14

[buster]

the attached patch is not as extensive as it looks.  there were some tab 
characters in the file, a no-no, so I removed them and replaced them with spaces 
as per coding spec.  basically, I just added 
nsPluginInstanceOwner::GetContainingBlock
and a call to it in GetHeight().

Comment 15

[av (gone)]

Looks fine to me. As far as I know we do not need to get approval for nsbeta2+ 
bugs, just a reviewer.

Comment 16

[buster]

fixed and checked in.  submitted bug 40185 to track any ongoing work that might 
be needed with this code.

Comment 17

[Chris Petersen]

This original problem has be fixed in the May 29th build. There is a new issue on 
Mac build that I write up for now.