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

{inc}[FLOAT]Stacked floating objects within table cells are repositioned vertically when interacted with.

RESOLVED WORKSFORME

Status

()

Core
Layout: Tables
P3
normal
RESOLVED WORKSFORME
16 years ago
13 years ago

People

(Reporter: Dan Ragle, Unassigned)

Tracking

Trunk
Future
x86
Windows NT
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

16 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0rc3) Gecko/20020523
BuildID:    2002052306

This is perhaps similar/related to bug 109532; but I was unable to recreate the
described behavior with that bug so I'm unsure. 

In this page: http://Biblestuph.com/bugs/floattest3.html, the initial layout is
correct; lots of text flowing around two stacked right-aligned floats of
differing widths. Entering text into the input field in the topmost float,
however, immediately causes both floats to be repositioned downward on the page,
evidently they are dropped downward by the same height as the top float itself
(you can verify this by changing the amount of text in the top float and viewing
the resulting displacement). The text then flows around both the top empty space
and the floats themselves. Other events also trigger the drop: removing all of
the text in the input box (for example, if the initial 
input box has a value= attribute) and clicking the link in the lower 
float, which replaces the text of the lower float via an innerHTML assignment,
both cause the two floats to be repositioned downward as described.

Reproducible: Always
Steps to Reproduce:
1. Load http://Biblestuph.com/bugs/floattest3.html
2. type a character in the input box on the top right. Both 
   floats are immediately repositioned downward.
3. Refresh the page. The floats come back to the top.
4. Put your cursor in the input box next to the original character
   you typed. Back up over that character. The floats move down
   again. 
5. Refresh the page. The floats come back to the top.
6. Click the link in the bottom of the lower float. The text of the    
   lower float is replaced and the floats are repositioned downwards. 


Actual Results:  As described above. I'm running Win NT/Moz1.0rc3/800x600 res. 

Expected Results:  Floats should remain in top right position as initially laid out.

Notes:

1.) Remove the outermost table for the page, and the problem goes away.
2.) Remove either of the floating objects and the problem goes away (i.e., I see
the problem only when both floats are used together and stacked on top of one
another).
Sounds like an incremental reflow problem...
Summary: Stacked floating objects within table cells are repositioned vertically when interacted with. → {inc}Stacked floating objects within table cells are repositioned vertically when interacted with.

Comment 2

16 years ago
Confirming in the OS X May 28th build (2002-05-28-05 1.0.0) Changing priority to P3.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3
-> Karnaze
Assignee: attinasi → karnaze
Target Milestone: --- → Future

Updated

16 years ago
Summary: {inc}Stacked floating objects within table cells are repositioned vertically when interacted with. → {inc}[FLOAT]Stacked floating objects within table cells are repositioned vertically when interacted with.

Comment 4

15 years ago
Created attachment 105019 [details]
Another testcase

Another testcase. Initial layout is correct, but repeatedly changing
the text size (Text Zoom) causes the floated images to "jump" out
of the block they're supposed to be in. Really seems to be reflow-related.

Comment 5

15 years ago
mass reassign to default owner
Assignee: karnaze → table
Component: Layout → Layout: Tables
QA Contact: petersen → madhur
Target Milestone: Future → ---

Updated

15 years ago
Target Milestone: --- → Future
I think this bug is fixed somehow.
I did see the problem with both testcases in Mozilla 1.1 (2002-08-26).
But I don't see the problem anymore with: 
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a2) Gecko/20040525
Firefox/0.8.0+
The float stay nice at their place where they belong.
(Reporter)

Comment 7

13 years ago
I agree, I no longer see the problem on either test case with 
Mozilla 1.7 (Windows 2000).
Ok, marking fixed then.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → RESOLVED
Last Resolved: 13 years ago13 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.