Closed
Bug 74184
Opened 24 years ago
Closed 24 years ago
<input type=image> element is not on it's place
Categories
(Core :: Layout, defect)
Tracking
()
VERIFIED
FIXED
mozilla0.9
People
(Reporter: ezh, Assigned: waterson)
References
()
Details
(Keywords: regression)
Attachments
(4 files)
1. Load the page.
2. Look at the upper left corner of the screen.
3. There's a tab that should be under the list of questions (look in other
browser yourself, my english is to bad to explane it :( ).
A week ago it wasn't so, yesterday also (but i'm not sure!!!). I try it with
older build now.
Reporter | ||
Comment 1•24 years ago
|
||
I forgot to tell I see this with 2000033004.
Build from 2000032704 looks ok.
Reporter | ||
Comment 2•24 years ago
|
||
The same thing at http://www.fileflash.com/index.aspx?action=download&program=637
Reporter | ||
Comment 3•24 years ago
|
||
One more page: www.thecounter.com
Reporter | ||
Updated•24 years ago
|
Keywords: regression
Comment 4•24 years ago
|
||
Yes, I see this. It also affects home.netscape.com. The basic pattern is
an <input type=image>, preceded by another <input> element, with those
enclosed within a <font> tag. Is this a residual style related bug?
Simple test case (from rus.delfi.ee):
<HTML><HEAD><base href="http://rus.delfi.ee/"></HEAD><BODY>
<br><br><br>
Why is the 'input type=image' at position 0,0?
<form>
<font class="colDefault">
<input type="radio">A Radio button<br>
<input type="image"
src="http://rus.delfi.ee/images/buttons/vote.gif"
width="88" height="16" border="0">
</font>
</form>
</body></html>
Somewhat of a mustfix for next release.
Keywords: nsbeta1
Updated•24 years ago
|
Summary: The element is not on it's place → <input type=image> element is not on it's place
When I replaced <font></font> with <bad></bad> or <span></span> or <b></b> it
has the same effect. It would seem that this affect illegal tags only.
Comment 8•24 years ago
|
||
Rods, can you take a look. If it is a block problem, please reassign to
attinasi.
Assignee: karnaze → rods
When I remove the <br> before the <input type="image"> or when I add a
<div></div> around <input type="image"> it no longer display the image at the
upper left hand corner of the document.
tested with build 2001040904 win32talkback
Comment 10•24 years ago
|
||
This looks like a regression in the time frame of pavlov's image lib changes.
reassigning
Assignee: rods → pavlov
Severity: normal → critical
Target Milestone: --- → mozilla0.9
Assignee | ||
Comment 12•24 years ago
|
||
It looks like the <input> frame is getting positioned incorrectly when it's
pushed onto the second linebox by the <br>. Here's an even smaller tests case.
Assignee | ||
Comment 13•24 years ago
|
||
Assignee | ||
Comment 14•24 years ago
|
||
Here's a pared-down frame dump without the <bad> element:
Block(body)(1) (i=0,b=1)<
line: count=1 state=block,clean,NOT Impacted,[0x1002] {0,0,8940,525} <
Block(form)(0) (i=2,b=0)<
line: count=1 state=inline,clean,NOT Impacted,[0x1400] {0,0,1,285} <
Frame(br)(0) {0,0,1,285} [state=00000024]
>
line: count=1 state=inline,clean,NOT Impacted,[0x1000] {0,285,1320,240} <
ImageControl(input)(1) {0,285,1320,240} [state=00002034]
>
>
>
>
Here's the frame dump *with* the <bad> element:
Block(body)(1) (i=0,b=1)<
line: count=1 state=block,clean,NOT Impacted,[0x1002] {0,0,8940,525} <
Block(form)(0) (i=2,b=0)<
line: count=1 state=inline,clean,NOT Impacted,[0x1420] {0,0,1,285} <
Inline(bad)(0) <
Frame(br)(0) {0,0,1,285} [state=00000024]
>
>
line: count=1 state=inline,clean,NOT Impacted,[0x1000] {0,285,1320,240} <
Inline(bad)(0) <
ImageControl(input)(1) {0,-15,1320,240} [state=00002034]
>
>
>
>
>
It looks like the frame thinks it's in the right place with respect to
its parent. Maybe the view positioning is broken. I'll look more tomorrow.
Assignee | ||
Comment 15•24 years ago
|
||
Yep, the problem is that the NS_FRAME_HAS_CHILD_WITH_VIEW is not being pushed to
the continuing frame for the <bad> tag. So we never sync the view's state to the
frame. We need to fix this.
rods: as a tangential issue, why does the nsImageControlFrame need to have a
view at all? (Does a frame need to have a view to participate in the event
system? Are there clipping issues that I don't understand?)
Status: NEW → ASSIGNED
Assignee | ||
Comment 16•24 years ago
|
||
Assignee | ||
Comment 17•24 years ago
|
||
kevin, I think this probably regressed when you checked in the fix for bug
70211. The problem is that we need to propagate the NS_FRAME_CHILD_HAS_VIEW bit
forward into continuing frames. Could you r=? marc, sr=?
Comment 18•24 years ago
|
||
Patch looks good. Yes this looks like my regression as the result of checking in
the fix for bug 70211. Thanks for fixing this Chris :)
r=kmcclusk@netscape.com.
Comment 19•24 years ago
|
||
very nice sr=attinasi
Assignee | ||
Comment 20•24 years ago
|
||
Fix checked in.
Checking in nsContainerFrame.h;
/cvsroot/mozilla/layout/html/base/src/nsContainerFrame.h,v <-- nsContainerFrame.h
new revision: 3.42; previous revision: 3.41
done
Checking in nsContainerFrame.cpp;
/cvsroot/mozilla/layout/html/base/src/nsContainerFrame.cpp,v <--
nsContainerFrame.cpp
new revision: 1.107; previous revision: 1.106
done
Assignee | ||
Comment 21•24 years ago
|
||
Unh!
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•