If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

VERIFIED FIXED

Status

()

Core
Plug-ins
VERIFIED FIXED
15 years ago
15 years ago

People

(Reporter: John Chivian, Assigned: Peter Lubczynski)

Tracking

Trunk
x86
Windows 2000
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments, 2 obsolete attachments)

(Reporter)

Description

15 years ago
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
(Reporter)

Comment 1

15 years ago
Created attachment 111436 [details]
a screen shot of what the bug looks like on the display

self explanitory
(Reporter)

Comment 2

15 years ago
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.
(Reporter)

Comment 3

15 years ago
netscape 7.01 on windows nt 4.0 exhibits the same behavior
looks like we're painting garbage into the plug-in window....
Assignee: other → peterlubczynski
Component: Layout → Plug-ins
QA Contact: ian → shrir
(Assignee)

Comment 5

15 years ago
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.
(Assignee)

Updated

15 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Updated

15 years ago
Attachment #111533 - Flags: superreview?(kin)
Attachment #111533 - Flags: review?(av)
(Reporter)

Comment 6

15 years ago
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.  
(Assignee)

Comment 7

15 years ago
Created attachment 111551 [details] [diff] [review]
same patch as last w/ -u20
(Reporter)

Comment 8

15 years ago
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!
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → WORKSFORME

Comment 9

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

r=av
Attachment #111533 - Flags: review?(av) → review+
(Assignee)

Comment 10

15 years ago
reopening for fix
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
(Assignee)

Comment 11

15 years ago
Created attachment 112204 [details] [diff] [review]
patch v.2

adding check for NS_CONTENT_ATTR_NOT_THERE
(Assignee)

Updated

15 years ago
Attachment #111551 - Attachment is obsolete: true
(Assignee)

Updated

15 years ago
Attachment #111533 - Attachment is obsolete: true

Comment 12

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

sr=kin@netscape.com
Attachment #112204 - Flags: superreview+

Updated

15 years ago
Attachment #111533 - Flags: superreview?(kin) → superreview-
(Assignee)

Comment 13

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

carry forward r=
Attachment #112204 - Flags: review+
(Assignee)

Comment 14

15 years ago
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.
Status: REOPENED → ASSIGNED
Flags: blocking1.3b?

Comment 15

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

a=asa (on behalf of drivers) for checkin to 1.3beta.
Attachment #112204 - Flags: approval1.3b+

Updated

15 years ago
Flags: blocking1.3b?

Updated

15 years ago
Keywords: nsbeta1+
(Assignee)

Comment 16

15 years ago
patch in trunk, marking FIXED
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago15 years ago
Resolution: --- → FIXED

Comment 17

15 years ago
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
Status: RESOLVED → VERIFIED

Comment 18

15 years ago
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
You need to log in before you can comment on or make changes to this bug.