Closed
Bug 36997
Opened 25 years ago
Closed 23 years ago
nested EMBED tag incorrectly placed if align=top on parent OBJECT
Categories
(Core :: Layout, defect, P2)
Core
Layout
Tracking
()
VERIFIED
FIXED
mozilla0.9.7
People
(Reporter: M.L.Hammond, Assigned: peterlubczynski-bugs)
References
Details
(Keywords: html4, testcase, top100)
Attachments
(5 files, 5 obsolete files)
522 bytes,
text/html
|
Details | |
1.41 KB,
text/html
|
Details | |
5.56 KB,
text/plain
|
Details | |
135 bytes,
text/html
|
Details | |
1.99 KB,
patch
|
peterlubczynski-bugs
:
review+
peterlubczynski-bugs
:
superreview+
brendan
:
approval+
|
Details | Diff | Splinter Review |
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; m15)
BuildID: 2000041805
On http://www.beme.com the flash content plays fine, but on following the link
to "View with Flash 4.0" there's nothing to see, except for some motion in a
very thin band just under the location bar. Perhaps the movie is being displayed
off the screen?
Reproducible: Always
Steps to Reproduce:
1. View URL
Actual Results: Content not properly displayed
Expected Results: Show the movie
Comment 1•25 years ago
|
||
I see the behaviour you mentioned. Seems like the ' align="left" ' tag is not
being understood by the browser properly. Copying the source code locally and
changing the value to 'align=left' works and the movie loads and plays fine.
Comment 2•25 years ago
|
||
oops..the original tag is "align=top". changing it to "align=left" works.
Comment 3•25 years ago
|
||
Even removing the "align=top" tag works, but I am wondering why we have to do
this...in order for the movie to play.
Reporter | ||
Comment 4•25 years ago
|
||
Changing the attribute to align=texttop makes it work.
http://www.w3.org/TR/WD-object-970218 explains somewhat. Seems like it's
(technically) a problem with the page rather than the browser, but this doesn't
explain why it's mucking things up so badly.
setting align=randomgarbage doesn't make it break, so it must be actively
getting it wrong :) (and "other browsers" can handle align=top) oddly,
http://www.w3.org/TR/html4/struct/objects.html#h-13.7.4 suggests that align=top
should be okay...
Comment 5•25 years ago
|
||
Thanks for the info. I believe this is not a plugin problem since the plugin
plays properly. Reassigning to HTML element component.
Assignee: av → rickg
Component: Plug-ins → HTML Element
QA Contact: shrir → petersen
Comment 6•25 years ago
|
||
I can reproduce the problem with the April 21 build. I noticed that the url
contains a object with a nested EMBED. After some research, it looks like the
object element is not able to render the flash animation so I passes to the EMBED
element. If you comment out the EMBED element, the document will not rendered the
flash src. The align="top" attribute is supported in object and is used to
vertically align the top of object with the top current of the text line. I have
a test case that works with align=top at http://mozilla.org/quality/browser/
standards/html/object_align_top.html.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 8•25 years ago
|
||
nsbeta2 6/1-. Marking flash. Shouldn't this be reassigned to whoever's
fixing HTMLElement cmpn bugs? Who is that?
Comment 10•24 years ago
|
||
This bug has been marked "future" because the original netscape engineer working
on this is over-burdened. If you feel this is an error, that you or another
known resource will be working on this bug,or if it blocks your work in some way
-- please attach your concern to the bug for reconsideration.
Target Milestone: M18 → Future
Comment 12•24 years ago
|
||
Raising priority to P2--high profile backward compatibility for Flash content on
the web. Clearing Future to -- and nominating nsbeta3.
Comment 13•24 years ago
|
||
Removing the align=top from the object element (which contains the embed element)
will cause the flash anaimation to be rendered.
Comment 14•24 years ago
|
||
Marking nsbeta3+ and cc-ing attinasi, peterl.
Comment 16•24 years ago
|
||
PDT marking [rtm-] because there are workarounds
Whiteboard: [nsbeta2-] [rtm+] → [nsbeta2-] [rtm-]
Comment 17•24 years ago
|
||
Flash crasher or backward incompatibility bug. Nominating for nsbeta1 as
high-quality plug-in support is a priority for embedded applications.
Keywords: nsbeta1
Comment 18•24 years ago
|
||
REMOVING nsbeta2/3 and replacing with nsbeta1 KW. Also clearing
Status Whiteboard of nsbeta2/3 result. We really should get Flash
working. Not that I like it, but other people do:).
Assignee | ||
Comment 19•24 years ago
|
||
Assignee | ||
Updated•24 years ago
|
Assignee: av → buster
Status: ASSIGNED → NEW
Summary: Flash movie doesn't play properly (wrong position?) → OBJECT tag incorrectly placed if align=top
Target Milestone: --- → mozilla0.8
Assignee | ||
Comment 20•24 years ago
|
||
This is caused by the align=top on the OBJECT tag. It's a floater but a
placeholder isn't generated for it.
Changing summary from: Flash movie doesn't play properly (wrong position?)
Sending it over to buster and nominating...
Comment 21•24 years ago
|
||
Reassigning QA Contact for all open and unverified bugs previously under Lorca's
care to Gerardo as per phone conversation this morning.
QA Contact: lorca → gerardok
Comment 24•24 years ago
|
||
taking
Assignee: buster → waterson
Target Milestone: mozilla0.9 → mozilla1.0
Updated•24 years ago
|
Status: NEW → ASSIGNED
SPAM. HTML Element component deprecated, changing component to Layout. See bug
88132 for details.
Component: HTML Element → Layout
Updated•23 years ago
|
Comment 26•23 years ago
|
||
*** Bug 64645 has been marked as a duplicate of this bug. ***
Comment 27•23 years ago
|
||
Changing platform and OS to reflect the conditions of bug 64645, which has been
deemed a duplicate of this bug.
OS: Windows 98 → All
Hardware: PC → All
Assignee | ||
Comment 28•23 years ago
|
||
*** Bug 105944 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 29•23 years ago
|
||
back to me....still happening....
Assignee: waterson → peterlubczynski
Status: ASSIGNED → NEW
Whiteboard: [rtm-]
Target Milestone: mozilla1.0 → mozilla0.9.6
Assignee | ||
Comment 30•23 years ago
|
||
*** Bug 103438 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 31•23 years ago
|
||
Happens on PBS which I think is top100.
http://www.pbs.org/newshour/video/index.html
Hey Marc or Chris, do you have any tips on what could be causing this? Thanks!
Status: NEW → ASSIGNED
Keywords: top100
Comment 32•23 years ago
|
||
Is the attribute mapping is working correctly (i.e.,
nsIContent::GetMappedAttributeImpact)? Setting |align={left|right}| are supposed
to float the tag (per GetImageAlignAttributeImpact). What is |align=top|
supposed to do?
Assignee | ||
Comment 33•23 years ago
|
||
Well, nsHTMLObjectElement.cpp calls nsGenericHTMLElement::MapAlignAttributeInto
which looks like it only deals with left and right. I don't see where
|align=top| would be even be mapped in for the IMG tag. According to W3C, this
should work for Objects like it does for Images? Does |align=top| work for images?
Assignee | ||
Comment 34•23 years ago
|
||
Assignee | ||
Comment 35•23 years ago
|
||
Well, the orrignal web site, http://www.beme.com, is gone! Can someone attach a
(non)-working testcase?
I don't think the problem is with the mapping anymore. With the last attached
testcase, it seems to work just fine.
I think the problem maybe when the OBJECT tag specified a align=top but NOT the
EMBED tag. Since we render the EMBED tag instead of the OBJECT in the nested case.
Should the EMBED check it's parent OBJECT for allignment?
QA Contact: moied → shrir
Comment 36•23 years ago
|
||
Assignee | ||
Comment 37•23 years ago
|
||
Oh yeah, that's a good testcase. It shows the problem with the OBJECT tag having
align=top and not the EMBED.
Summary: OBJECT tag incorrectly placed if align=top → nested EMBED tag incorrectly placed if align=top on parent OBJECT
Assignee | ||
Comment 38•23 years ago
|
||
This is very strange. How does align=top work? It looks like the "line" above
the BODY is getting a bogus y value of "-3255" which is causing everything else
to be wrong. However, the actual BODY looks like it has the right y value. I'm
attaching a frame dump of the tescase with a normal dump without align=top to
compare.
Assignee | ||
Comment 39•23 years ago
|
||
Comment 40•23 years ago
|
||
Here is a reduced testcase that does not require any plugins:
<object align="top">
<img src="http://www.mozilla.org/images/mozilla-banner.gif">
</object>
Assignee | ||
Comment 41•23 years ago
|
||
Assignee | ||
Comment 42•23 years ago
|
||
Removing the align=top on the OBJECT tag and looking in Viewer with frame
borders on, it looks like the line is the wrong height and cuts through the
middle of the image. In the debugger, I can see the height of the inline being
set to only the font metrics size:
http://lxr.mozilla.org/mozilla/source/layout/html/base/src/nsInlineFrame.cpp#611
There is comment there that says "the height of children do not affect our
height" and that code is pretty old so I'm not even sure I'm looking in the
right place.
cc:ing dbaron for some advice...
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Well, that looks like the correct behavior for 'vertical-align: text-top' and
perhaps also 'vertical-align: top' (although I would argue it isn't) on an
inline element. Maybe we shouldn't be mapping the ALIGN attribute on the OBJECT
element to 'vertical-align' when the element isn't replaced, though that seems
tricky. Ian, any ideas?
Assignee | ||
Comment 44•23 years ago
|
||
Even though it's deprecated, 4.01 spec does mention align=top:
http://www.w3.org/TR/html4/struct/objects.html#h-13.7.4
Should align=top be ignored on the object tag if the contents get rendered?
Comment 45•23 years ago
|
||
I may be dense, but I do not see why align=top is supposed to work the way it
currently is. Section 13.7.4 quoted by Peter says for top: "top: means that the
top of the object should be vertically aligned with the top of the current text
line." I cannot fathom any way in which "top of the object should be vertically
aligned with the top of the current text line" means to push the object way
beyond the top of the page as I see nothing that would say that the top of the
current text line is above the top of the page. If you add some text next to
the image in Marc's example, the text appears fine so it seems that the top of
the current text line is well within the boundaries of the page.
...because the image sticks out of the top of the inline frame for the object.
However, one can argue about what 'vertical-align: top' should do in such a case
-- see my proposal at http://www.people.fas.harvard.edu/~dbaron/css/2000/01/dibm
Comment 47•23 years ago
|
||
this is clearly visible on the shockwave site(hence it's important to be fixed
since a lot of users will notice it )
http://www.shockwave.com/sw/games/
The football image at the bottom right is peeking outside the table border.
Assignee | ||
Comment 48•23 years ago
|
||
After looking at this again this weekend, I think I agree with dbaron. Maybe for
replaced object elements, we should drop the 'vertical-align:' style? IE 6 seems
to ignore it in this situation but we try to support it (try 'sub' or a length).
Could one of the layout guys maybe suggest a strategy? I was thinking of setting
a style rule in nsCSSFrameConstructor::CantRenderReplaceElement(), but I'm not
quite sure how to set it?
Assignee | ||
Comment 49•23 years ago
|
||
We have problems with other "align attributes like "right" on the object frame
when it's replaced as well. This patch removes any align attribute before
calling CantRenderReplaceElement() to match our behavior with IE.
This hack isn't really a "fix" for this bug, but it should make top100 sites
that show this problem look better. I'm wondering if I can get reviews for this
patch and then move this bug to post-1.0 for a better fix?
That seems like a bit too much of a hack. Would it be possible to change the
MapAttributesIntoRule in content/html/content/src/nsHTMLObjectElement.cpp so
that it doesn't call nsGenericHTMLElement::MapAlignAttributeInto if the object
element is replaced? Or does the information about whether the object is
replaced live only on the frame (that would seem bad)?
Assignee | ||
Comment 51•23 years ago
|
||
We don't know we are going to be replaced until the end of reflow, at which time
we post a CantRenderReplaceElement(). I can't think of a way the content knows
that the frame has been replaced. I guess I can try to put in a hook however, I
don't see any call to MapAttributesIntoRule for the TextReset after the point I
know I need to be replaced. Will that be a problem or should re-resolving style
and a reflow fix that?
Assignee | ||
Comment 52•23 years ago
|
||
I tried to change |MapAttributesIntoRule| to block the calling of
|nsGenericHTMLElement::MapAlignAttributeInto| but since this static mapping
function isn't a member of the content class, I didn't have anything to work
with. I need to at least get at the content so I can call |GetPrimaryFrameFor|.
Suggestions?
So anyway, here a patch with a slightly different approach. I just reset the
vertical align style back to the default before we start to replace the object
frame. Please reivew.
There's an API for doing that that won't break things like inherit bits. You
want to call nsIStyleContext::GetUniqueStyleData (and you'll need to extend
nsStyleContext::GetUniqueStyleData for the TextReset struct), and then modify
that struct.
Assignee | ||
Comment 54•23 years ago
|
||
This seems to work. Thanks for the tip David, could you r= this patch?
Attachment #60497 -
Attachment is obsolete: true
Attachment #61057 -
Attachment is obsolete: true
Comment on attachment 61210 [details] [diff] [review]
patch using GetUniqueStyleData
>+ nsStyleTextReset* text =
>+ (nsStyleTextReset*)mStyleContext->GetUniqueStyleData(mPresContext, eStyleStruct_TextReset);
r=dbaron if you change the above to a new-style cast:
nsStyleTextReset* text = NS_STATIC_CAST(nsStyleTextReset*,
mStyleContext->GetUniqueStyleData(mPresContext, eStyleStruct_TextReset));
Attachment #61210 -
Flags: review+
Assignee | ||
Comment 56•23 years ago
|
||
Attachment #61210 -
Attachment is obsolete: true
Assignee | ||
Updated•23 years ago
|
Attachment #61213 -
Flags: review+
Comment 57•23 years ago
|
||
Comment on attachment 61213 [details] [diff] [review]
correct patch
I think that
NS_STYLE_INHERIT_TEXT
should be NS_STYLE_INHERIT_TEXT_RESET
Check that out. sr=attinasi if you do.
Attachment #61213 -
Flags: superreview+
Assignee | ||
Comment 58•23 years ago
|
||
Attachment #61213 -
Attachment is obsolete: true
Assignee | ||
Updated•23 years ago
|
Attachment #61550 -
Flags: superreview+
Attachment #61550 -
Flags: review+
Assignee | ||
Updated•23 years ago
|
Keywords: review → mozilla0.9.7
Comment 59•23 years ago
|
||
Comment on attachment 61550 [details] [diff] [review]
really corrected patch
+ const nsStyleTextReset* reset = (const
nsStyleTextReset*)GetStyleData(aSID);
This could be new-style (NS_STATIC_CAST), too.
a=brendan@mozilla.org for 0.9.7 in any case.
/be
Attachment #61550 -
Flags: approval+
Updated•23 years ago
|
Keywords: mozilla0.9.7+
Assignee | ||
Comment 60•23 years ago
|
||
Patch in trunk, marking FIXED.
Comment 61•23 years ago
|
||
The problem I reported with pbs.org (NewsHour and Washington Week video) is now
fixed with Mozilla trunk 2001-12-14-03 on Win2000.
Assignee | ||
Comment 62•23 years ago
|
||
Embedding may want this because it effects top100 sites, nominating...
Keywords: edt0.9.4
Comment 63•23 years ago
|
||
removing URL that is now dead.
Assignee | ||
Comment 64•23 years ago
|
||
not quite fixed yet....this causes crashing in some other major plugin sites so
I just backed myself out until there can be a better fix... :(
Assignee | ||
Comment 65•23 years ago
|
||
okay, this patch seems to be better, now checking for null....
Attachment #61550 -
Attachment is obsolete: true
Assignee | ||
Updated•23 years ago
|
Attachment #61778 -
Attachment is obsolete: true
Assignee | ||
Comment 66•23 years ago
|
||
Comment on attachment 61550 [details] [diff] [review]
really corrected patch
okay, I'm an idiot....this patch is fine. The crash I was seeing was because I
didn't re-link the content DLL so naturally it didn't pick-up my changes and
returned null. In fact, Stephen in comment #61 says this patch is good so I'll
try to land it again tonight. Sorry for the trouble....
Attachment #61550 -
Attachment is obsolete: false
Comment 67•23 years ago
|
||
a=asa (on behalf of drivers) for checkin to 0.9.7
Keywords: mozilla0.9.7 → mozilla0.9.7+
Assignee | ||
Comment 69•23 years ago
|
||
fixed0.9.7
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Keywords: fixed0.9.7
Resolution: --- → FIXED
Comment 70•23 years ago
|
||
Per shrir comment:
http://bugzilla.mozilla.org/show_bug.cgi?id=36997#c47
I suggest we include for 094. I would like to see it verified fixed on trunk/097.
Comment 71•23 years ago
|
||
Yes, this is fixed on trunk/0.9.7 branch build 1220. I tried all testcases/
duped bugs and the shockwave site as well. Looks good.
Updated•23 years ago
|
Keywords: verified0.9.4
Keywords: fixed0.9.4
You need to log in
before you can comment on or make changes to this bug.
Description
•