When first loading a page from a url containing a fragment, page is not centered around the fragment




14 years ago
5 years ago


(Reporter: fahlmanc_ca, Unassigned)


Firefox Tracking Flags

(Not tracked)



User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20060102 SeaMonkey/1.5a
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20060102 SeaMonkey/1.5a

when a fairly long page is loaded from clicking a hyperlink including a fragment url (#), the page doesn't stay anchored at the appropriate place while it is being loaded, and, importantly when the loading is complete the page is not centered at the appropriate anchor.

(after the page has been cached, it works fine though)

affects as well Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051230 Firefox/1.6a1 

Reproducible: Always

Steps to Reproduce:
1.Load, for the first time, a long page from a link containing a fragment.
2.The page loads but doesn't stay centered around the fragment while loading.
3.After the page has finished loading it still is often not centered at the appropriate location specified by the fragment url.

Actual Results:  
Page not properly centered while loading, or after loading.

Expected Results:  
Preferably the page to stay centered around the location specified in the fragment url, if possible, while it is loading, and certainly to be centered at the proper location after the page has been loaded.
dupe of "Images loading above top of window can cause scrolling up (reflow?)"

*** This bug has been marked as a duplicate of 60307 ***
Closed: 14 years ago
Resolution: --- → DUPLICATE
Is this really a dupe? I don't think so. I can see the same for simple pages without images included. After loading the page we do not jump to the target as specified by the anchor.

For example see:
This is a core issue given that SM and Firefox are affected. Lets reopen so we don't loose it.
Component: General → Layout
Ever confirmed: true
OS: Windows 98 → All
Product: SeaMonkey → Core
Hardware: x86 → All
Resolution: DUPLICATE → ---
Um, not sure if layout is correct. I doubt so, means feel free to correct that.
«Assigned To» seems to have been set to the component-watch address for SeaMonkey::General when this bug was reported. If it was intentional, please explain why.
Assignee: general → nobody
What this bug is a duplicate of depends on which comment it's about (though I can't really tell from comment 0, since it's not specific enough).

comment 2 might be an otherwise-unreported bug, though.
When I was reading comment 0 it perfectly matched the issue I have faced. So I'm sure that it's the same problem. So not sure if I really should open a new bug. Also because (at least what I see) the formerly duped against bug is about reflow when new images are loaded at the top of the page. Both bugs might be related.

One thing to add here: after the page has been loaded and you press Cmd+L and return again, Firefox perfectly jumps to the specified anchor.
I am seeing this in the Firefox for Android browser, version 21.0 - but not on Windows or Linux versions.

Sometimes, the target element (we use the id attribute on headings and span elements, but I have also tested with the name attribute on anchor elements) will appear at the top of the screen as expected, sometimes halfway down the screen, and sometimes you have to scroll a fair bit to get there.

I have tried disabling JavaScript - no effect (in fact, there is no dynamic behaviour on most of our pages, anyway). I made sure that all CSS is loaded at the top of the document, and there are no images. Unfortunately, all of our content is proprietary medical information behind a paywall - but I'll see if I can make an example page with links available.
Henrik: can you still reproduce this bug? I know I've seen problems around Firefox not jumping to the anchor position, but I can't reproduce the problem with the STR in comment 0 or comment 2.
Flags: needinfo?(hskupin)
Something seems to have indeed fixed that. I also cannot reproduce it anymore. If someone still can please reopen. Until then I will close it as WFM.
Closed: 14 years ago5 years ago
Flags: needinfo?(hskupin)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.