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)

x86
Windows 98
defect
Not set
critical

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.
I forgot to tell I see this with 2000033004. Build from 2000032704 looks ok.
One more page: www.thecounter.com
Keywords: regression
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
Summary: The element is not on it's place → <input type=image> element is not on it's place
Attached file testcase based on post above (deleted) —
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.
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
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
waterson says he wants this
Assignee: pavlov → waterson
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.
Attached file more smaller n' stuff (deleted) —
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.
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
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=?
Keywords: patch
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.
very nice sr=attinasi
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
Unh!
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Marking verified in the May 21 build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: