User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 The hidden embedded MP3 (see page source) displays as a rectangular "hole" in the display in which the contents of whatever is behind the mozilla browser window is displayed. I.E. displays the page okay. Reproducible: Always Steps to Reproduce: 1. load page 2. Actual Results: view attached jpg Expected Results: mozilla should not tried to display anything of any size. that is... the embedded MP3 and it's player would have been totally invisible. classic theme (although I doubt it makes a difference) no talkback as no crash
Created attachment 111436 [details] a screen shot of what the bug looks like on the display self explanitory
correction to earlier statement regarding what is displayed in the "hole". rather than displaying what is behind the browser window (which is incorrect), the hole displays either a section of the previously viewed web page OR that of any other window that is overlayed on top of it. for intance this "enter bug" window is currently the top most. if i bring the browser window (with the hole) back to the top it will display (in the hole) the portion of this window that overlaps it. that is, what is displayed in the hole is dynamic depending on what other window last obscured it before it was brought back to the forefront. if i bring another application to the front, and then bring the browser window to the front on top of that, the hole will display that portion of the other application window that obscured it.
netscape 7.01 on windows nt 4.0 exhibits the same behavior
looks like we're painting garbage into the plug-in window....
Created attachment 111533 [details] [diff] [review] patch v.1 I was just about to mark this bug INVALID because the testcase uses invalid HTML. According to the old 4.x spec for EMBED (http://developer.netscape.com/docs/manuals/htmlguid/tags14.htm#1286379) it doesn't look like the HIDDEN attribute should work without a value but in practice it works in 4.x and IE so we should do it. Here's a simple patch to treat empty HIDDEN attributes on the EMBED tag as hidden.
thanks for the info regarding the missing hidden= tag. i was not aware that it required a value (true or false). from a programming/design standpoint i think the patch is necessary as specifying hidden should, by default, mean hidden=true. at least that's what intuition seems to say. i will change the page source and re-test.
adding the ="true" to the hidden attribute does resolve the problem. my apologies for not being as up on my html as i should be. if the patch is put in place (defaulting to true if no value is specified for the hidden attribute) then i would consider this bug closed. thanks again!
Comment on attachment 111533 [details] [diff] [review] patch v.1 r=av
reopening for fix
Created attachment 112204 [details] [diff] [review] patch v.2 adding check for NS_CONTENT_ATTR_NOT_THERE
Comment on attachment 112204 [details] [diff] [review] patch v.2 firstname.lastname@example.org
Comment on attachment 112204 [details] [diff] [review] patch v.2 carry forward r=
request for mozilla 1.3b: this is a trival, low risk fix to allow <EMBED HIDDEN> to function like <EMBED HIDDEN=TRUE> because it works like that in 4.x and IE.
Comment on attachment 112204 [details] [diff] [review] patch v.2 a=asa (on behalf of drivers) for checkin to 1.3beta.
patch in trunk, marking FIXED
Marking Verified Fixed. Compared the attached patch 112204 to CVS Log: http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=nsObjectFrame.cpp&root=/cvsroot&subdir=mozilla/layout/html/base/src&command=DIFF_FRAMESET&rev1=1.376&rev2=1.377
I should add that I was unable to reproduce the described "hole" that represented the hidden mp3 and appeared on the page. testing with: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030420