Closed Bug 37558 Opened 25 years ago Closed 25 years ago

plugin EMBED tag is displayed in browser

Categories

(Core :: Layout, defect, P3)

x86
Windows 2000
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: sean, Assigned: attinasi)

Details

(Keywords: testcase, Whiteboard: [nsbeta2+])

Attachments

(2 files)

The word 'embed' is displayed in the browser where a plugin is embedded if the plugin isn't large enough to write over the text. For example, the following HTML tag sets width and height to 1: <EMBED NAME="foo" SRC="mySource.dat" TYPE="myType" WIDTH=1 HEIGHT=1 PLUGINSPAGE="http://myURL"> The word 'embed' appears in the browser. However, if width and height are sufficiently large, then the word 'embed' does not appear. 'embed' should not appear ever.
I added an example case. I think this is more likely a layout bug rather than plugins.
Reassigning to layout.
Assignee: av → troy
Component: Plug-ins → Layout
QA Contact: shrir → petersen
Target Milestone: --- → M19
Keywords: testcase
Where is the embedd text comming from? Reassigning to attinasi - Triaging Troy's bug list.
Assignee: troy → attinasi
add 4xp keyword
Keywords: 4xp
Status: NEW → ASSIGNED
DUP 17551. When Andrei checks in the default plug-in handler, you will see the puzzle piece for EMBEDs missing plug-ins as you did for 4.x. (It's the exact same binary, in fact.) *** This bug has been marked as a duplicate of 17551 ***
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
Reopening per Eric. The problem here is that the layout is drawing something outside of the plugin window. The plugin draws with the correct height and width, but the word 'embed' shows up if the font height is larger than the height specified for the plugin in the <embed> tag.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
This also occurs for short plugins that are instantiated using the <OBJECT> tag.
The word embed is being output by the nsObjectFrame::Paint method. I am doing some digging to figure out why it is there, or at least when it was added... Removal is simple: just cut a couple lines of code...
Status: REOPENED → ASSIGNED
I could not find any indication of why the tag-name is painted by the ObjectFrame... I am guessing it is old debug code or something. I'm attaching a patch that removes the offending code. Andrew, could you please review it and let me know if I am breaking anything in plugins? Thanks.
Noting that the fix is in hand... If somebody wants to nominate this for dogfood we might be able to get it checked in, otherwise we wait.
Whiteboard: [Fix in hand]
Looks like this is right thing to do. I think we can just remove this code.
The fix is to remove 3 lines of code that are printing out the element-type. I am nominating this for nsbeta2 because it is sooo simple and the bug is really ugly when there are plugin on a page and they are given a very small area to display in (presumably because they are really viewed in another window). This really looks like DEBUG code left in the mainline source (ouch!).
Keywords: nsbeta2
Putting on [nsbeta2+] [will be minus on 6/15] radar.
Whiteboard: [Fix in hand] → [nsbeta2+] [will be minus on 6/15][Fix in hand]
Removing 6/15..go ahead..check in.
Whiteboard: [nsbeta2+] [will be minus on 6/15][Fix in hand] → [nsbeta2+][Fix in hand]
Fix checked in (nsObjectFrame.cpp)
Status: ASSIGNED → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → FIXED
Whiteboard: [nsbeta2+][Fix in hand] → [nsbeta2+]
Fixed in the June 19 build (2000061908).
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: