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
I see this..changing summary.
Severity: blocker → major
Summary: FLASH PLAYER - BETA 2 → Page blanks out when window with shockwave movie is resized
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.
os: all. seen on mac also.
OS: Windows 98 → All
Confirming bug (per 16125)
Status: UNCONFIRMED → NEW
Ever confirmed: true
This also happens when windowshading (minimizing) the window = problem with redrawing Flash content to screen.
Putting on [nsbeta2+] radar.
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
*** Bug 24549 has been marked as a duplicate of this bug. ***
I'll take a look.
Assignee: troy → buster
Priority: P3 → P1
Target Milestone: --- → M17
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
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
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().
Looks fine to me. As far as I know we do not need to get approval for nsbeta2+ bugs, just a reviewer.
fixed and checked in. submitted bug 40185 to track any ongoing work that might be needed with this code.
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
Whiteboard: [nsbeta2+] fix in hand → [nsbeta2+]
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.