Last Comment Bug 90270 - [FIXr][fixed pos]DIV using CSS fixed positioning appears in wrong place and then "jumps" to proper place on mouseover
: [FIXr][fixed pos]DIV using CSS fixed positioning appears in wrong place and t...
: css2, testcase
Product: Core
Classification: Components
Component: Layout: R & A Pos (show other bugs)
: Trunk
: All All
: P1 normal with 1 vote (vote)
: mozilla1.4alpha
Assigned To: Boris Zbarsky [:bz]
: Hixie (not reading bugmail)
: 146303 158398 168771 185119 193266 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2001-07-10 22:01 PDT by Andy Korvemaker
Modified: 2003-02-22 12:16 PST (History)
15 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Positioning error (48.03 KB, image/jpeg)
2002-01-02 19:54 PST, Ho KS
no flags Details
Positioning OK (65.40 KB, image/jpeg)
2002-01-02 19:56 PST, Ho KS
no flags Details
Minimal testcase (557 bytes, text/html)
2002-06-17 20:13 PDT, Boris Zbarsky [:bz]
no flags Details
more evil testcase (more like the site) (717 bytes, text/html)
2002-06-18 00:20 PDT, Boris Zbarsky [:bz]
no flags Details
partial patch (6.97 KB, patch)
2002-06-18 00:26 PDT, Boris Zbarsky [:bz]
no flags Details | Diff | Splinter Review
updated partial patch (8.23 KB, patch)
2003-01-25 12:10 PST, Boris Zbarsky [:bz]
roc: review+
roc: superreview+
Details | Diff | Splinter Review
slightly simpler more evil testcase (849 bytes, text/html)
2003-01-25 12:11 PST, Boris Zbarsky [:bz]
no flags Details
Merged to tip (includes fix for bug 192291) (8.21 KB, patch)
2003-02-13 14:55 PST, Boris Zbarsky [:bz]
roc: review+
roc: superreview+
Details | Diff | Splinter Review

Description Andy Korvemaker 2001-07-10 22:01:24 PDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:0.9.2) Gecko/20010628
BuildID:    2001062815

When this page loads, the navigation box on the top right corner is placed at
the top of the page, rather than down a bit (1.5em) as is specified in the style
sheet (under body:margin-top).

When I move my cursor over one of the links in the navigation box, the whole box
jumps to its proper position.

Other pages on the same site have similar "jumps".

Reproducible: Always
Steps to Reproduce:
1.load the page (
2.move mouse over a link in the navigation box (top right corner)

Actual Results:  navigation box jumps to new (proper) position

Expected Results:  navigation box should have appeared in the "new" position
when it was first loaded.

The navigation box is created using "document.write" statements in an external
javascript file.

Opera 5.12 displays the page properly (without jumping).

The navigation box uses the CSS property "position : fixed".
Comment 1 Boris Zbarsky [:bz] 2001-07-16 11:11:10 PDT
Over to layout.  This is a problem on build 2001-07-15-21 on Linux as well.
Comment 2 anthonyd 2001-12-07 18:57:44 PST
problem still there.
reassigning to core owner as this is not a table specific bug.
Comment 3 Alexey Chernyak 2001-12-20 06:06:04 PST
Andy, take a look at following sections of CSS2 spec:

The offset of the box has to be explicitly specified. Your stylesheet fails to
specify vertical offset of the box. margin-top: property is not inheritable, and
thus doesn't apply to your navigation box. Try applying top: property to your
box and see what happens.

This happens not only on mouseover, but also on window resize. While it is
obviously a result of improper style sheet, the browser behaviour in handling of
this case seems to differ during DOM insertion and during reflow.

Over to Style System.
Comment 4 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2001-12-20 07:42:04 PST
This is a layout bug, not a style system bug, unless you're arguing that both
positions are incorrect.
Comment 5 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2001-12-21 07:52:05 PST
->Layout.  See:
Comment 6 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2001-12-21 07:53:48 PST
er, really
Comment 7 Boris Zbarsky [:bz] 2001-12-21 11:50:46 PST
David, is there a public version of the document you cite?
Comment 8 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2001-12-21 12:21:50 PST
Comment 9 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2001-12-21 12:23:44 PST
Anyway, it was just an email message from me to the WG list asking what should
happen with 'position: fixed' and 'top: auto', since the spec doesn't define it
well, plus a little general mumbling about whether 'top: auto' is really useful
at all given the difficulty of implementation...
Comment 10 Ho KS 2002-01-02 19:54:24 PST
Created attachment 63339 [details]
Positioning error

This site's address is
The first time the page is loaded, some DIVs are rendered too much to the right
hand side.
If you refresh the page, they go back to the intended position.
Comment 11 Ho KS 2002-01-02 19:56:05 PST
Created attachment 63341 [details]
Positioning OK

This is the correct position
Comment 12 Ho KS 2002-03-18 22:56:49 PST
Another DIV wrongly displaced at
The positions are corrected only when the page is refreshed.
Comment 13 Boris Zbarsky [:bz] 2002-03-19 08:07:20 PST
Neither of the sites in comment 10, comment 11, comment 12 uses fixed
positioning, so they have nothing to do with this bug (as a separate note, I
cannot reproduce those problems).  I _can_ reproduce this problem.
Comment 14 Vincent Lefevre 2002-06-16 20:09:41 PDT
I don't know if my CSS code is correct, but is it the same problem I have on

? If I move the mouse pointer quickly over Menu, then the menu is sometimes
displayed for a very short period slightly to the left or to the right. This
problem disappears if I don't use "position: fixed".

Note: don't use Mozilla 1.0 to test that (the menu won't appear), but a more
recent version.
Comment 15 Boris Zbarsky [:bz] 2002-06-17 20:13:57 PDT
Created attachment 88065 [details]
Minimal testcase

Vincent, you're seeing something different (reflow lag of some sort?).

The minimal testcase is for the original bug report (reduced from  The problem there is that the
stylesheet specifies none of top, bottom, height for the fixed-position div. 
These properties do not have a useful initial value, so we can place the thing
where ever we feel like, really....

The only bug is that we don't place it _consistently_.
Comment 16 Boris Zbarsky [:bz] 2002-06-18 00:20:39 PDT
Created attachment 88091 [details]
more evil testcase (more like the site)
Comment 17 Boris Zbarsky [:bz] 2002-06-18 00:26:49 PDT
Created attachment 88094 [details] [diff] [review]
partial patch

So the problem is that if neither of top and bottom is specified then the
fixed-pos element should have its top where it would be if the element were
statically positioned.	So to position it properly we have to reflow the main
content, then position it.  That's what this patch does.  It fixes the minimal
testcase, but not the more evil one (where the <script> referencing an external
file kicks off a reflow that apparently does not flow the main content
correctly but does reflow the fixed-pos elements).  It also does not fix the
original site this is reported against.
Comment 18 Vincent Lefevre 2002-06-18 13:09:25 PDT
I can reproduce the problem with the two new testcases (no patch applied).

Note that the problem isn't only a display problem. If I add submenus, the whole
menu no longer works at all (perhaps because :hover no longer works as expected
because the position is temporarily incorrect). This is solved by either using
"position: absolute" (instead of fixed) or by swapping left and right.
Comment 19 Andy Korvemaker 2002-07-14 14:56:18 PDT
I've moved the original "problem" site (without the fixed css) to in case it's still needed.
Comment 20 Jose Fandos 2002-08-09 17:46:38 PDT
I just came across these two pages

And one of them is wrong. Both share a position:fixed element, in fact both take
the same stylesheet. The second one doesn't look good. "Fixed positioning is
just like absolute positioning, except the containing block of a fixed element
is always the viewport". So according to this, the second link _IS_ doing the
right thing and the first one, is not, though it's the first one that looks right.

On modifying the second page by adding <br /> so as to make the page big enough
for a scroll to appear, the div gets repositioned as in the first link, which
though it looks good again, is not according to spec, I believe.

As to what I am using, 1.1beta build 2002080508 on Windows XP (all patched). I
have no control over the pages mentioned. I just happened to go visit that
particular site.

I did check the code against style checkers (both html and css) and it should be
right. I post this here because it seems relevant and I don't fancy opening a
bug just like that. If anyone with a better grasp thinks it should go on a bug
by itself, might want to go ahead and add that new bug. I might also add this
comment to other bugs if I see it relevant. Just checking now. ;)
Comment 21 Boris Zbarsky [:bz] 2002-08-09 20:06:19 PDT
Of those two, the first link is correct.  Note that "top" is not specified in
that stylesheet...

My "partial patch" fixes the second of those two links to look correct as well.
Comment 22 Jose Fandos 2002-08-10 05:55:54 PDT
"Of those two, the first link is correct.  Note that "top" is not specified in
that stylesheet..."

Reading the specification (
positioning) for fixed positioning "the containing block is stablished by the 
viewport." If that's so, the second link, while not looking good, is correct. 
A top value should have been given in the css file to keep it from getting the 
default top: 0px; In the first page the reason why the #NavBar is not at 
top:0px is because the #NavBar is _NOT_ being "totally removed from the 
documents's flow". It shouldn't have a position relative to any part of the 
document. (From CSS: The Definitive Guide, by E. Meyer).

I guess the reason for this removal of the document flow is because if we 
would keep it in it, and we would have that fixed positioned element coming up 
later in the document, not showing on the first screen, but rather having to 
scroll down to view it, it wouldn't make sense, would it? Would the fixed 
positioned element, once it gets a hold of the viewport get stuck? Would it 
keep scrolling? If so, why did we use the positioned element in the first 

IE6 does show both pages like the first one does in Mozilla. I guess they got 
that part wrong.
Comment 23 Boris Zbarsky [:bz] 2002-08-10 17:38:31 PDT
> A top value should have been given in the css file to keep it from getting the 
> default top: 0px;

The default value of "top" is not 0px.  It's "auto".  See for the rules
that govern layout in this case...  The containing block is the viewport, and
rule #1 says what should be done when "top" is "auto".

IE6 is getting the layout exactly correct here.
Comment 24 Jose Fandos 2002-08-10 19:10:21 PDT
You are right :)

I guess then that a position:fixed element that is not at the top of the html so
as to show in the viewport, as you hit the page, is not going to show at all,
unless the viewport can be resized to encompass the element's original
position... cool, fixed elements allow to have notices for those with screens of
1280x1024 that won't be viewable by those with a smaller screen, for example.

But what behavior is expected when a position:fixed element that is in the
middle of a long document (let's say 10 viewports long) is just preceeded by a
named anchor and the page has been called from a link with that anchor in it?
Does it show then?

Comment 25 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2002-08-14 19:55:39 PDT
I guess I think the meaning of 'top: auto' for fixed-positioned elements should
be changed...
Comment 26 Mats Palmgren (:mats) 2002-09-15 09:31:22 PDT
*** Bug 168771 has been marked as a duplicate of this bug. ***
Comment 27 Todd Kennedy 2002-12-11 15:35:12 PST
This seems to be related to a question I just posted in the
news://netscape.public.mozilla.dom newsgroup.

I have a couple of test pages i'm working on to test out how to build certian
various components of websites i work on (,, into strict XHTML because i'm sick of doing 8-level nested tables
and watching them crash on netscape 4.

So i've been playing with CSS and XHTML and I'm geting the same problem.  my DIV
tag (the only thing on the page, it's the containter the rest of the stuff
appears in) is appearing on the page about 5px south of the top of the browser
viewport, even though my body tag has margin: 0; and padding: 0;.

i've validated my CSS and XHTML as both proper CSS2 and XHTML Strict 1.0, so (i
hope!) it's not my code, AND in IE 5.2 (mac) and IE 6.0 (pc) the pages are
appearing correctly (the top of the div is butted right against the top of the
browser viewport).

the page is:


i can replicate the mozilla bug in:
netscape 7.0 (mac os 9)
mozilla 1.2.1 (mac os 9)
mozilla 1.2.1 (mac os x)
mozilla 1.0.1 (pc)

is this the same bug, and if so, is it planned for fixing soon?

Comment 28 Andy Korvemaker 2002-12-11 22:17:50 PST

I don't think this is the same bug. In the original, the div jumped around on 

One thing that may help (I'm not a css expert) is to place a "top: 0px;" 
statement in your css file for the navigation bar.

Changing site submitted by Todd to
Comment 29 Boris Zbarsky [:bz] 2002-12-12 07:59:35 PST
Todd, your div is not position:fixed, so has _nothing_ to do with this bug.

You want to set the <html> margin to 0.
Comment 30 Boris Zbarsky [:bz] 2002-12-12 19:21:21 PST
Comment 31 Boris Zbarsky [:bz] 2003-01-25 12:10:19 PST
Created attachment 112636 [details] [diff] [review]
updated partial patch

We should get this in; it fixes the common case of this bug...	and it's the
right thing to do no matter what.
Comment 32 Boris Zbarsky [:bz] 2003-01-25 12:11:37 PST
Created attachment 112637 [details]
slightly simpler more evil testcase
Comment 33 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2003-01-25 12:43:31 PST
Comment on attachment 112636 [details] [diff] [review]
updated partial patch


Looks good.
Comment 34 Boris Zbarsky [:bz] 2003-01-25 13:02:16 PST
takins so it stays on my radar....

roc says this is no-go for 1.3, so landing it in 1.4a.
Comment 35 Benjamin Streeck 2003-01-26 10:56:46 PST
The way I see it the problem in this bug is not any mouse-over issue, but a
general redraw upon any event that causes position to be recalculated, such as
resizing the window, the addition of a scrollbar, or a mouse-over action that
redraws the element. If this is the case, then Bug 158398 is a duplicate, and
the current summary is very misleading.

Mark Bug 158398 as duplicate?

Change summary to: "position:fixed elements in wring position until screen
positions re-calculated" ?
Comment 36 Boris Zbarsky [:bz] 2003-01-26 10:59:39 PST
I'd rather keep it dependent as duplicate, because the patch here fixes that bug
but _not_ quite this one.

The summary is the one that describes the most common way to trigger this bug;
it may as well stay.
Comment 37 Boris Zbarsky [:bz] 2003-02-13 14:55:12 PST
Created attachment 114372 [details] [diff] [review]
Merged to tip (includes fix for bug 192291)

In a fit of curiousity, I decided to check out what the value of "wasHandled"
was.  Turns out that the incremental reflow code was not handling the "eviler"

This patch fixes all testcases attached to this bug and all dependent bugs.
Comment 38 Boris Zbarsky [:bz] 2003-02-13 14:58:11 PST
Comment on attachment 114372 [details] [diff] [review]
Merged to tip (includes fix for bug 192291)

roc, how's about a repeat of that review?  The only real change was the slight
logic tweak to do a real reflow if the incremental reflow does not get
Comment 39 Hixie (not reading bugmail) 2003-02-19 12:51:40 PST
I take it your interpretation of 'auto' doesn't involve adjusting for the scroll
position... that could be, erm, fun.
Comment 40 Boris Zbarsky [:bz] 2003-02-19 13:52:53 PST
Er?  "auto" means we position it to line up with the placeholder, unless the page is scrolled.
That's the only interpretation that really makes sense per spec, to me.
Comment 41 Boris Zbarsky [:bz] 2003-02-22 12:14:36 PST
*** Bug 146303 has been marked as a duplicate of this bug. ***
Comment 42 Boris Zbarsky [:bz] 2003-02-22 12:15:21 PST
*** Bug 158398 has been marked as a duplicate of this bug. ***
Comment 43 Boris Zbarsky [:bz] 2003-02-22 12:15:39 PST
*** Bug 185119 has been marked as a duplicate of this bug. ***
Comment 44 Boris Zbarsky [:bz] 2003-02-22 12:16:27 PST
*** Bug 193266 has been marked as a duplicate of this bug. ***
Comment 45 Boris Zbarsky [:bz] 2003-02-22 12:16:52 PST
fixed for 1.4a.

Note You need to log in before you can comment on or make changes to this bug.