layout quirk with :hover and positioned elements




Layout: R & A Pos
15 years ago
11 years ago


(Reporter: Daniel Steinberger, Assigned: dbaron)


({regression, testcase})

regression, testcase
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [reflow-refactor], URL)


(1 attachment)



15 years ago
when i fetched 2002100508 i noticed a bug on my homepage that wasn't present
with the lastest nightly i was using (something short after 1.1). when you visit
the URL (or just use the striped down testcase i'll attach) and hover the links
in the upper right from bottom to top, you'll see that the lower two items don't
stick to the right as they should, but float around to far to the left (in 90%
of the cases this 'works' - but sometimes does not. just reload and you'll see
the effect). if you hover from top to bottom, they align as they should have
done. happens in both strict and quirks layout mode.

Comment 1

15 years ago
Created attachment 101885 [details]
stripped-down Bug #172866 demonstration

Comment 2

15 years ago
Bug does NOT occur in 2002-09-23-08 trunk Linux
Bug occurs in 2002-09-24-08 trunk Linux

Possible culprits: checkins for bug 75121 or bug 169620?
Keywords: regression, testcase
OS: Windows XP → All

Comment 3

15 years ago
Taking.  roc, any chance this is fixed by the patch to bug 170688?
Assignee: attinasi → dbaron
Component: Layout → Layout: R & A Pos
Priority: -- → P2
Target Milestone: --- → mozilla1.3alpha
Sadly, the patch in bug 170688 does not fix this bug.

Comment 5

15 years ago
OK, my guess as to what's happening is that we're resizing the block without
reflowing its children, which should happen when we resize a block when the
ResizeReflowOptimization is disabled...

Comment 6

15 years ago
The question is, how do we get the right-alignment correct on the first pass
(since we're shrink-wrapping)?
Perhaps I'm on crack, but it looks to me like when I load the page and then
mouse over the top-most link, the bottom three links move left.

Could it be as simple as, if the block width changes in response to an
incremental reflow, then we need to reflow any non text-align:left lines?

Comment 8

15 years ago
Yes.  But why does it work the first time?  We have to do the same thing for the
non-incremental case, since we don't know the size until after the first reflow.
 (After all, we don't have a |GetPrefSize| separate from |Reflow|, although we
should, so we're crossing the pref-size reflow with the real reflow.)
Whiteboard: [reflow-refactor]
Bug 236080 may be somewhat related, since it is also about some :hover glitch.
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20061208 Minefield/3.0a1 ID:2006120812 [cairo]

seems fixed by reflow branch landing

Comment 11

11 years ago
Not the reflow branch landing; this works in FF 2.0 and trunk.  In any case, WORKSFORME.
Last Resolved: 11 years ago
Flags: in-testsuite?
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.