230390 - Page reload scrolling problem with internal page links & css absolute positioning

Status: RESOLVED DUPLICATE of bug 103279

(Core :: Layout, defect)

Description

[Mark Annand]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20030925
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20030925

Certain pages with 'internal links', to a named anchor within the page,
misbehave when the page is refreshed - the display scrolls down on refresh.
Suspect this is related to pages with absolutely positioned divs. Apologies if
it's my code ...

Reproducible: Always

Steps to Reproduce:
1.Set up site so it uses absolute positioning for 'menu' which is in a div - go
to http://users.bathspa.ac.uk/markhelp/basics_1.html#menu and select 'Menu is
fixed position'. This sets site to use a particular stylesheet that uses
absolute positioning for a menu to be visible at all times, and remembers this
in a cookie
2.Load another page from the site using a URL pointing to an internal anchor
within the page e.g. -
http://users.bathspa.ac.uk/markhelp/emailfaq/email_rules.html#simple
3.Refresh page ...

Actual Results:  
Page scrolls down on reload

Expected Results:  
Document should reload without repositioning.


The problem may be triggered by the absolutely positioned 'div' containing the
menu common to all pages.

This 'div' physically wraps a number of menu items, a small graphic, and a
unfeasably tall invisible graphic, that acts as a target to scroll the menu into
the viewport when it's out of sight in Internet Explorer (which is unhappy with
absolute positioning). 

It might be revealing that when the large graphic is edited out of the site, the
Mozilla bug still shows, but rather than scrolling to the bottom on refresh, the
page scrolls down by an amount that may be equal to the (reduced) height of the
contents of that 'div' on the left. Perhaps the large graphic when present is
causing the page to scroll down as far as it can on reloading. 

It may be that Mozilla thinks on refreshing the page, that it must add the
height of what's in the absolutely positioned div to things, causing the page to
be positioned wrong.

_______________________________________________________

The stylesheet that exposes this behaviour is 

http://users.bathspa.ac.uk/markhelp/faq-col-absolutemenu.css

Alternative stylesheet included for internet explorer, that behaves well with
Mozilla, is

http://users.bathspa.ac.uk/markhelp/faq-col-fixedmenu.css

Apologies. They're both byzantine ...

Comment 1

[Boris Zbarsky [:bzbarsky]]

hmm.. when I reload
http://users.bathspa.ac.uk/markhelp/emailfaq/email_rules.html#simple (with the
menu fixed; I tested that afterward by scrolling and making sure it didn't), the
position in the document does not change -- remains near the top.  Using Linux
trunk nightly 2004-01-04-08 here...

Comment 2

[Mark Annand]

Thanks for investigating. I've just retested this with a recent nightly:

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7a) Gecko/20040108

Loading the example with its internal anchor

http://users.bathspa.ac.uk/markhelp/emailfaq/email_rules.html#simple

and then reloading it, the page still scrolls itself down on a reload, as it did
before. Perhaps this is a Windows-not-Linux thing.

Comment 3

[Mark Annand]

*Updated* steps to reproduce this using Mozilla/5.0 (Windows; U; Windows NT 5.0;
en-US; rv:1.6) Gecko/20040113

1) Load the following reduced case web page:
http://users.bathspa.ac.uk/markhelp/emailfaq/email_rules_moztest2.html

2) Set the style sheet using the link on that page

3) Follow the internal link on that page, (the page scrolls down), and reload.

What happens: The page scrolls down again on reloading

What should happen: the page should reload at the target, without scrolling.

This one seems dependent on several things: 

    * if the 'css-setting javascript' is edited out, the bugginess disappears
    * if the 'Navigation' div is contentless - no bugginess then
    * the browser's window size (this doesn't show at small window sizes)
    * very occasionally, the first 'Reload' doesn't trigger it ...

I'll have a go at exposing it more, by whittling stuff out of that style sheet ...

Comment 4

[Jesiah S]

I see this on LInux 2004011808 using steps from comment 3.  It did take a few
refreshes to get it to show the bug.

Comment 5

[Mark Annand]

Mozilla 1.4 has this behaviour.

The screen resolution may interact with this bug too - using Moz 1.4 I couldn't
reproduce it at less than 800 X 600.

Comment 6

[Jason Barnabe (np)]

Works for me on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a3)
Gecko/20040904 Firefox/0.9.1+

Comment 7

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 8

[davekind70]

(In reply to comment #7)
> This is an automated message, with ID "auto-resolve01".
> This bug has had no comments for a long time. Statistically, we have found that
> bug reports that have not been confirmed by a second user after three months are
> highly unlikely to be the source of a fix to the code.
> While your input is very important to us, our resources are limited and so we
> are asking for your help in focussing our efforts. If you can still reproduce
> this problem in the latest version of the product (see below for how to obtain a
> copy) or, for feature requests, if it's not present in the latest version and
> you still believe we should implement it, please visit the URL of this bug
> (given at the top of this mail) and add a comment to that effect, giving more
> reproduction information if you have it.
> If it is not a problem any longer, you need take no action. If this bug is not
> changed in any way in the next two weeks, it will be automatically resolved.
> Thank you for your help in this matter.
> The latest beta releases can be obtained from:
> Firefox:     http://www.mozilla.org/projects/firefox/
> Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
> Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 9

[Daniel.S]

This really sounds like bug 103279. So due to the missing testcases I'll close this.