188959 - the hidden embedded mp3 manifests as a "hole" in the display that shows the contents of whatever is behind the browser window

Status: VERIFIED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[John Chivian]

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

Comment 1

[John Chivian]

Attachment: a screen shot of what the bug looks like on the display

self explanitory

Comment 2

[John Chivian]

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.

Comment 3

[John Chivian]

netscape 7.01 on windows nt 4.0 exhibits the same behavior

Comment 4

[Boris Zbarsky [:bzbarsky]]

looks like we're painting garbage into the plug-in window....

Comment 5

[Peter Lubczynski]

Attachment: 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.

Comment 6

[John Chivian]

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.  

Comment 7

[Peter Lubczynski]

Attachment: same patch as last w/ -u20

Comment 8

[John Chivian]

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 9

[av (gone)]

Comment on attachment 111533 [details] [diff] [review]
patch v.1

r=av

Comment 10

[Peter Lubczynski]

reopening for fix

Comment 11

[Peter Lubczynski]

Attachment: patch v.2

adding check for NS_CONTENT_ATTR_NOT_THERE

Comment 12

[kinmoz]

Comment on attachment 112204 [details] [diff] [review]
patch v.2

sr=[e-mail]

Comment 13

[Peter Lubczynski]

Comment on attachment 112204 [details] [diff] [review]
patch v.2

carry forward r=

Comment 14

[Peter Lubczynski]

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 15

[Asa Dotzler [:asa]]

Comment on attachment 112204 [details] [diff] [review]
patch v.2

a=asa (on behalf of drivers) for checkin to 1.3beta.

Comment 16

[Peter Lubczynski]

patch in trunk, marking FIXED

Comment 17

[bmartin]

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

Comment 18

[bmartin]

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