Closed Bug 234328 Opened 21 years ago Closed 17 years ago

Flash .swf image not correctly displayed according to attribute width=100%

Categories

(Core Graveyard :: Plug-ins, defect)

defect
Not set
major

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: gs06897, Assigned: peterlubczynski-bugs)

References

()

Details

User-Agent:       
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040207 Firefox/0.8

At http://www.seaoftranquility.org, the flash image below the site logo is not
rendered correctly. This worked fine in last version of Firebird.

Firefox 0.8 does not appear to display the Macromedia Flash .swf image according
to the attribute 'width=100%' within table data tags. Flash image is only
rendered part way across the browser window, while <tr> and <td> are set to span
100% of the width (<td> has a colspan of 2 to run entire width, but flash image
doesn't even fill the width of the first column above it).

The remainder of the <td> is filled with grey, and right clicking in the grey
area is completely ignored--like it's not even a part of the browser anymore.
Right-clicking the rendered portion of hte Flash image provides the typical
flash options, and right-clicking anywhere else provides the usual browser menu.

Also, when scrolling down and then up to view the web page, the strange
mis-rendered portion of the Flash .swf image holds some of the graphic rendering
from other parts of the page. It is only re-rendered without the stray graphic
parts (but still not expanding the flash image to 100% width) when another tab
is drawn over the web page.

Both width=100% and width="100%" (with and without quotes) produce the same thing.

Look for the <!-- Insert MM_Flash moving text bar --> in the page source to see
MM Flash code.

Thanks!

Reproducible: Always
Steps to Reproduce:
1. visit http://www.seaoftranquility.org
2.
3.

Actual Results:  
Macromedia Flash .swf image not rendered correctly.

Expected Results:  
Rendered the MM Flash image according to attributes.
I am having a simllar problem.  

I posted this to the mozilla forum and received no solutions:

"I have built a website that incorporates flash
(http://saramago.fiu.edu:8080/flashmap). The site runs correctly under Windows
XP in IE and under RedHat 9.0 with mozilla 1.2.1.

new versions of mozilla 1.5 and firebird 0.6 and 0.7 and firefox 0.8 are unable
to display the flash file correctly in both windows and linux. I have tried
multiple verisions of flash and none corrected the issue, so i am pretty sure
the bug is limited to new versions of mozilla after 1.5 when firebird was
integrated.  

In windows XP a space is displayed above the flash file. On my gentoo linux box,
firefox 0.8 displays part of the flash "stage" that is not set to viewable and
will not respond to user input. (i have emerged mozilla-firebird and netscape-flash)

My flash file communicates with the client and server via javascript. I believe
the user communication problem lies in the LiveConnect cabability of mozilla. As
far as the flash file not displaying correctly, I believe that it has something
to do with how firefox is interpreting the STAGE object in flash"

not specific to Firefox
Assignee: firefox → general
Component: General → Browser-General
Product: Firefox → Browser
QA Contact: general
Version: unspecified → Trunk
(In reply to comment #2)
> not specific to Firefox

Maybe not, but Flash seems to work fine for me in FireBird 0.7:
(Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5)
Gecko/20031007 Firebird/0.7)

I didn't see the problem until I upgraded to FireFox (0.8). I've gone back to
FireBird 0.7, and my MM Flash works fine (at least the Flash on my website,
above, and on those Flash-based websites I actually have a desire to visit).

I haven't been using Mozilla proper since FireBird was released (just a note:
some flash over-burdened site broke my last build of Mozilla in such a way that
I can't revive it--or *any* Mozilla version, for that matter--I've no clue what
went wrong there!)


WFM LInux Mozilla 2004031607
WFM LInux Firefox 20040316
I see it on LInux Firebird w/gtk2/xft 20040315
GTK2 issue?
I received this error about a dozen times when starting FF w/tk2/xft
nsNativeComponentLoader: GetFactory(libnkgnomevfs.so) Load FAILED with error:
libgnomevfs-2.so.0: cannot open shared object file: No such file or directory
I am experiencing the same rendering errors with the latest versions of Mozilla
(1.6) and Firefox (0.8) on both Red Hat and OS X.
A Flash movie published as noscale, width = 100%, height = 100% should take up
the entire client area of the browser, but instead it gets shifted up and
cropped so that only about 20% of the movie is visible (and even then still
incorrectly).  ActionScript Stage object listeners aren't notified when the
browser window is resized.
I also see this on a day old cvs build of Mozilla w/gtk2/xft
Assignee: general → peterlubczynski-bugs
Status: UNCONFIRMED → NEW
Component: Browser-General → Plug-ins
Ever confirmed: true
OS: Linux → All
Hardware: PC → All
I'm having the same problem with the Flash presentation in
http://www.synfuldesires.org/  above.  However, at least Konqueror can present
it correctly.  So, this is a Mozilla problem.
A work-around for this bug - use JavaScript to write the object and embed tags for the swf, where the 
id attribute of the embed tag is 'swf' (in this example at least).  Take advantage of Mozilla's support for 
the window.innerHeight property.  The Stage resize event is fired when the window is resized - not 
while the size is being manipulated.  This solution works for me in Mozilla 1.7 and Firefox 0.8 (and 
Opera 6).

Here's a sample:

// snip
var ua = navigator.userAgent.toLowerCase();
var moz = (ua.indexOf('mozilla') >= 0 && ua.indexOf('safari') < 0) || (ua.indexOf('opera') > 0);
// Opera is retarded as well
if(moz) {
	window.onresize = function()
	{	
		document.getElementById('swf').height = window.innerHeight;
	}
}
</script>

</head>
<body bgcolor="#ffffff" marginwidth="0" marginheight="0" topmargin="0" leftmargin="0">

<script language="JavaScript" type="text/javascript">
document.write('<object classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" codebase="http:/
/fpdownload.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=7,0,0,0" 
width="100%" height="');
document.write(moz ? window.innerHeight : "100%");
document.writeln('" id="foo" align="middle">');
document.writeln('<param name="allowScriptAccess" value="sameDomain" />');
document.writeln('<param name="movie" value="some.swf" />');
document.writeln('<param name="loop" value="false" />');
document.writeln('<param name="menu" value="false" />');
document.writeln('<param name="quality" value="high" />');
document.writeln('<param name="scale" value="noscale" />');
document.writeln('<param name="salign" value="lt" />');
document.writeln('<param name="bgcolor" value="#ffffff" />');
document.write('<embed src="some.swf" loop="false" menu="false" quality="high" scale="noscale" 
salign="lt" bgcolor="#ffffff" width="100%" height="');
document.write(moz ? window.innerHeight : "100%");
document.writeln('" name="foo" align="left" allowScriptAccess="sameDomain" type="application/x-
shockwave-flash" pluginspage="http://www.macromedia.com/go/getflashplayer" id="swf" />');
document.writeln('</object>');
</script>
//snip


(I hope this submits okay)

Good luck!

Andrew
*** Bug 239422 has been marked as a duplicate of this bug. ***
I also get the same results when viewing a .swf file with the width="100%" and
height="100%".  It is smashed up high on the page.  Thanks Andrew for the work
around in javascript.  I haven't tried it yet (I will), but this bug needs to be
fixed for use without the work around.

Here are the exact tags I used:

<p><object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000"
codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,0,0"
width="100%" height="100%" livesrc="../web-data/SmartObjects/Beams.ai">

<embed src="images/Beams.swf" type="application/x-shockwave-flash" width="100%"
height="100%" pluginspage="http://www.macromedia.com/go/getflashplayer"
scale="exactfit">

(In reply to comment #8)
Unfortunately Andrew's work around doesn't solve the problem completely, but
there is a solution!

Using the onresize handler to inform the swf file of the new window size allows
the swf to properly update, but it does not solve the paint problems that gtk
versions of firefox seem to have.

Firefox seems to only paint the region initially set by the swf file or smaller,
but not bigger. So an easy fix is to make the initial size of the swf file very
large. So, setting the dimensions to 1600x1200 for instance will alleviate the
paint issue while the size of the browser window is smaller than 1600x1200.
Making the initial size of the swf file too large will result in additional CPU
usage while resizing.

Cheers,
Wes Carr

is this the same bug as bug 146826, or something different?

bug 146826 was originally noted with Gecko/20020510 and appears to be caused by
embed tags with height/width=100%.  Firefox might be using the SWF height/width
instead of the actual inner size of the window; I haven't been able to verify
this since I can't find a tool to parse compressed SWF files.

User-Agent:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050720
Fedora/1.0.6-1.1.fc4 Firefox/1.0.6

This bug still exists, and the problem is getting stranger.

This page displays fine using height fixed and width 100%:
http://www.plauditdesign.com/index.html

This page displays with the grey-box error with a height fixed and width 100%:
http://www.plauditdesign.com/portfolio/projects/identity/assoc-bnfts-identity.html

No solution has been found, yet.
Is this bug still being considered?

I can e-mail a developer my uncompressed flash file--I just have to figure out which one it was that I used.

Who would I send it to?
Can this bug be marked as a blocking1.8.1? It certainly seems worthy.
Well, it looks like rev 1.5 solved the issue I reported way up top. The swf stage is now rendering correctly on www.seaoftranquility.org with the attribute "width=100%".

Don't know what you did, but whatever it was it worked. 

Hopefully this solved the issue for everyone.
closing WORKSFORME per reporter comment 16.
please reopen with comments if you see otherwise using a current version.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.