Last Comment Bug 268111 - [FIX]position: fixed elements are positioned relative to the page rather than the viewport
: [FIX]position: fixed elements are positioned relative to the page rather than...
: regression, testcase
Product: Core
Classification: Components
Component: Layout: R & A Pos (show other bugs)
: Trunk
: All All
: P5 minor (vote)
: mozilla1.8beta1
Assigned To: Boris Zbarsky [:bz]
: 273177 276154 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2004-11-06 08:07 PST by James Ross
Modified: 2006-03-25 16:48 PST (History)
8 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Fix (1.90 KB, patch)
2005-01-09 12:05 PST, Boris Zbarsky [:bz]
dbaron: review+
dbaron: superreview+
Details | Diff | Review
testcase (3.88 KB, text/html)
2005-01-15 12:12 PST, Christian :Biesinger (don't email me, ping me on IRC)
no flags Details

Description James Ross 2004-11-06 08:07:11 PST
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041106 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041106 Firefox/1.0

When loading a page with a position: fixed element on it (see the URL), the
element is positioned against the page itself, rather than the viewport - even
though it is anchored to the viewport when you scroll.

Reproducible: Always
Steps to Reproduce:
1. Load the URL.
2. Scroll down.
3. Reload (not shift-reload, as that resets the scorll-position). You can also
just resize the window for this step.

Actual Results:  
The position: fixed header vanishes.

Expected Results:  
The position: fixed header should still be anchored to the top-left of the viewport.

It appears to be positioning the fixed element against the page, so if you only
scroll down 1 line and then resize/reload the position: fixed element is then
locked partially off the top of the viewport.

Each time a reflow occurs (reload or resize window) the element is re-anchored
based on the scroll position of the page.

This bug is currently causing ChatZilla to not have any header boxes, as they
use position: fixed (that's how I found it :) ).
Comment 1 James Ross 2004-11-06 08:10:36 PST
This regression is pretty recent, I believe, as I have only noticed it the past
couple of days - it happens on my 2004110603 build, and CTho's 20041104 build,
but (for reference) not Firefox 1.0 branch. I'm going to try to get some nightly
builds now, but my initial guess is that it's regressed in the past week or two
at most.
Comment 2 James Ross 2004-11-06 09:31:41 PST
2004-11-01-06 is OK.
2004-11-03-07 is OK.
2004-11-04-07 is broken.

(Windows zip builds from

The check-in for bug 266968, at 2004-11-03 08:16, would seem a likely place to
start looking.
Comment 3 James Ross 2004-11-06 09:34:10 PST
CCing bz since his bug looks related.
Comment 4 Boris Zbarsky [:bz] 2004-11-06 18:13:55 PST
The problem is that the CSS specification is somewhat self-contradictory here.

1)  The fixed-position div should not move when we scroll.
2)  Since it has auto top and bottom, its position depends on where it would
    show up if it were statically positioned.
3)  Where it would show up if statically positioned depends on the scroll

Note that before the checkin for bug 266968 we mishandled scrolling when
calculating static positions.  So the testcase in this bug rendered
consistently, but absolutely positioned divs wouldn't render right if things got
scrolled.  Now we account for the scroll position correctly, and this bug results.

I've sent mail to regarding this inconsistancy... let's see
what they say.  Taking, I guess.

As for Chatzilla, I recommend specifying some offsets.  You might want to file a
separate bug on that.
Comment 5 Boris Zbarsky [:bz] 2004-11-06 18:26:29 PST
The mail I sent is at

Note that my proposed changes to the spec to remove the contradiction will
probably leave chatzilla broken if implemented.
Comment 6 Hixie (not reading bugmail) 2004-11-06 20:46:02 PST
Comment 7 James Ross 2004-11-07 04:24:22 PST
Ah, it turns out it was only my custom output window that lacked a top property
for the header in ChatZilla - the built-in one does specify top: 0px and is thus
not affected by this change in behaviour.
Comment 8 Frank Wein [:mcsmurf] 2004-12-05 10:03:46 PST
*** Bug 273177 has been marked as a duplicate of this bug. ***
Comment 9 Boris Zbarsky [:bz] 2005-01-09 12:03:56 PST
*** Bug 276154 has been marked as a duplicate of this bug. ***
Comment 10 Boris Zbarsky [:bz] 2005-01-09 12:05:16 PST
Created attachment 170755 [details] [diff] [review]

This restores the old behavior of using the static position with all scrollable
things scrolled to default position.... I suspect we do want to keep backwards
compat here, unfortunately.  :(
Comment 11 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2005-01-15 11:09:17 PST
Comment on attachment 170755 [details] [diff] [review]

r+sr=dbaron (assuming you're restoring old code, didn't really look)
Comment 12 Christian :Biesinger (don't email me, ping me on IRC) 2005-01-15 12:12:41 PST
Created attachment 171358 [details]

attaching testcase from URL here so it won't get lost
Comment 13 Boris Zbarsky [:bz] 2005-01-15 13:51:41 PST
Yes, this is restoring the old code.  Checked in for 1.8b.
Comment 14 James Ross 2006-03-25 12:22:12 PST
This bug is back again on trunk (not in FF 1.5). Reopen or new bug?

New testcase:
Comment 15 Boris Zbarsky [:bz] 2006-03-25 16:39:47 PST
New bug, and please cc me.  But that URL gives me a 503; please attach a testcase to the bug you file?
Comment 16 James Ross 2006-03-25 16:48:14 PST
Filed bug 331729 and broke the knee-caps of the guy admining the server. ;)

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