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

VERIFIED FIXED in M17

Status

()

Core
Layout
P1
major
VERIFIED FIXED
18 years ago
18 years ago

People

(Reporter: Troy Evans, Assigned: buster)

Tracking

Trunk
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta2+])

Attachments

(2 attachments)

(Reporter)

Description

18 years ago
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

18 years ago
I see this..changing summary.
Severity: blocker → major
Keywords: beta2
Summary: FLASH PLAYER - BETA 2 → Page blanks out when window with shockwave movie is resized
(Reporter)

Updated

18 years ago
Summary: Page blanks out when window with shockwave movie is resized → Page blanks out when window with Macromedia Flash (SWF) movie is resized
Marking with flash keyword.
Keywords: flash

Updated

18 years ago
Keywords: nsbeta2

Comment 3

18 years ago
os: all. seen on mac also.
Keywords: beta2
OS: Windows 98 → All

Comment 4

18 years ago
Confirming bug (per 16125)
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 5

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

redrawing Flash content to screen.

Comment 6

18 years ago
Putting on [nsbeta2+] radar.  
Whiteboard: [nsbeta2+]

Comment 7

18 years ago
Created attachment 8358 [details]
Stack trace

Comment 8

18 years ago
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.
Assignee: av → troy
Component: Plug-ins → Layout
QA Contact: shrir → petersen

Comment 9

18 years ago
*** Bug 24549 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 10

18 years ago
I'll take a look.
Assignee: troy → buster
Priority: P3 → P1
Target Milestone: --- → M17
(Assignee)

Comment 11

18 years ago
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
Status: NEW → ASSIGNED
(Assignee)

Comment 12

18 years ago
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.
Whiteboard: [nsbeta2+] → [nsbeta2+] fix in hand
(Assignee)

Comment 13

18 years ago
Created attachment 8810 [details] [diff] [review]
patch that fixes the immediate problem
(Assignee)

Comment 14

18 years ago
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

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

Comment 16

18 years ago
fixed and checked in.  submitted bug 40185 to track any ongoing work that might 
be needed with this code.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
Whiteboard: [nsbeta2+] fix in hand → [nsbeta2+]

Comment 17

18 years ago
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.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.