Closed Bug 60307 Opened 24 years ago Closed 5 years ago

Images loading above top of window can cause scrolling up (reflow?)

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1519644

People

(Reporter: jruderman, Unassigned)

References

(Depends on 2 open bugs,
URL
)

Details

(Keywords: testcase-wanted)

Attachments

(1 obsolete file)

Steps to reproduce: 1. Go to http://george-w-dance.homepage.com/ 2. Scroll to the bottom after the page loads (but before all of the images have loaded). Result: Each time (?) an image is loaded, the page scrolls up. Eventually the page scrolls up enough so that the rest of the images are loading below the visible portion of the document, at which point the scrolling stops. Expected result: Images loading off-screen generally shouldn't cause the page to appear to scroll.
Please triage.
Assignee: clayton → harishd
Scrolling issue...starting off with Eric.
Assignee: harishd → evaughan
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.8
->moz0.9
Target Milestone: mozilla0.8 → mozilla0.9
I'm not sure if this is already clear from the bug as reported, but of course _nothig_ that happens above or below the current visible area should ever make the window jump around -- not only loading of images. Or is this a non-problem?
->moz1.0
Target Milestone: mozilla0.9 → mozilla1.0
I don't know much about the Mozilla codebase, but here's one method to solve this bug: When an image loads, AND the top of the image lies above the scroll position, AND displaying the image would cause a reflow, don't display the image and don't reflow until the user scrolls the page back up. Because Mozilla's current behavior (as of 2001100503) matches IE's to some extent, this (more correct) behavior may have to be documented in a release note if a patch for this issue lands.
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 (you can query for this string to delete spam or retrieve the list of bugs I've moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
*** Bug 126882 has been marked as a duplicate of this bug. ***
While it's true that bug 126882 is a duplicate, the report in 126882 points out another aspect of the problem, namely that this behavior breaks many HTML hyperlinks. Any links of this variety: http://yoursite.com/yourpage.html#yoursection may break, because "#yoursection" might drift off the screen entirely. This broken link behavior would be unacceptable to most users.
*** Bug 134310 has been marked as a duplicate of this bug. ***
*** Bug 89552 has been marked as a duplicate of this bug. ***
These bugs are related: bug 139832 Improve scroll position after window resize bug 136564 Text Zoom loses scroll position But for those bugs, it might make sense to approximate the correct scroll position using ratios instead of trying to keep the same object near the top of the viewport.
*** Bug 140340 has been marked as a duplicate of this bug. ***
*** Bug 180539 has been marked as a duplicate of this bug. ***
Blocks: 168902
Depends on: 43114
Blocks: 80141
*** Bug 184849 has been marked as a duplicate of this bug. ***
*** Bug 196018 has been marked as a duplicate of this bug. ***
*** Bug 144852 has been marked as a duplicate of this bug. ***
*** Bug 80141 has been marked as a duplicate of this bug. ***
As bug 80141 was marked as a duplicate, I'll just point out that this happens with all dynamic content. See the attachment from that bug, http://bugzilla.mozilla.org/attachment.cgi?id=118314&action=view#50. Just load it and click reload.
I'd like to revive this bug. I find it very annoying, and the Target Milestone is still "1.0.1"! Unfortunately, I'm not a programmer. But I think this is very important to fix.
*** Bug 217767 has been marked as a duplicate of this bug. ***
*** Bug 230282 has been marked as a duplicate of this bug. ***
*** Bug 234848 has been marked as a duplicate of this bug. ***
*** Bug 237615 has been marked as a duplicate of this bug. ***
*** Bug 239002 has been marked as a duplicate of this bug. ***
Also evident using Mozilla-Mac/2004042110. Also, dupe 80141 was All/All, so this should be, too.
No longer blocks: 80141
OS: Windows 98 → All
Hardware: PC → All
Note this testcase doesn’t bother scrolling the page at all, leaving the user at the top of the document.
Keywords: testcase
*** Bug 140455 has been marked as a duplicate of this bug. ***
safari and konqueror seem to handle this the way i want. how are they doing it?
*** Bug 265434 has been marked as a duplicate of this bug. ***
*** Bug 267002 has been marked as a duplicate of this bug. ***
*** Bug 276772 has been marked as a duplicate of this bug. ***
*** Bug 277969 has been marked as a duplicate of this bug. ***
*** Bug 297907 has been marked as a duplicate of this bug. ***
*** Bug 302771 has been marked as a duplicate of this bug. ***
*** Bug 292056 has been marked as a duplicate of this bug. ***
Assignee: eric → nobody
Status: ASSIGNED → NEW
Priority: P3 → --
QA Contact: chrispetersen → layout
Target Milestone: mozilla1.0.1 → ---
Confirmed also with Firefox 1.5! This bug has been added in Nov 2000, why it is still there after 5 years (Nov 2005)? Please note that bug 302642 may be a duplicate of this one. Here is another test link: http://c-jump.com/pagerules02.html#aswitch
(In reply to comment #37) > This bug has been added in Nov 2000, why it is still there after 5 years (Nov > 2005)? Because no one has written a patch. Feel free to do so.
(In reply to comment #38) > (In reply to comment #37) > > This bug has been added in Nov 2000, why it is still there after 5 years (Nov > > 2005)? > > Because no one has written a patch. Feel free to do so. > Good answer, but I meant why, before adding new features, aren't addressed all bugs? Anyway, I never read mozilla source, but if someone could at least list me the relevant source files for this bug, I can try to find a fix!
If we all stopped adding features and fixed (or tried to fix) every single bug, we'd be there for years with nothing to show but almost identical releases. ;) All developers must split their time between bugs and features, and this will be influenced by their area of knowledge, time available, and interest in each particular request. One of the reasons I believe this bug has not really gone anywhere, even in 5 years, is that it is both hard to define the exact behaviour in all the cases that need defining, and could be even harder to implement. Just as an example, what should happen if an image loads that is positioned near the top of the page, meaning all the text visible in the page is below it? The user would almost certainly prefer it to scroll so the bottom of the image is kept near the top - so they can still read the text - but how far down the page must the image be, before this behaviour stops? Half way? Should it depend on the size of the image that's just appeared? A basic implementation may not be so hard (whether an object is off the top of the visible area is pretty simple to determin), however, it still requires a developer to dedicate a reasonable chunk of their time to analyse the bug, find and read the existing code, write some new code and test it (probably repeating the code & test phases a few times). As indicated by the current assginee (nobody@mozilla.org), no-one (that has seen this bug) feels they can or want to commit to this.
*** Bug 302642 has been marked as a duplicate of this bug. ***
*** Bug 322144 has been marked as a duplicate of this bug. ***
Isn't there *anyone* who can work on this? Pleeeeeeeease? This bug is extremely annoying from a user perspective. If someone gives a user a URL, such as this one -- http://www.clubsmartcar.ca/forums/viewtopic.php?p=116641#116641 -- then the user has absolutely no idea which part of the page they were supposed to be looking at (without reloading), because the page scrolls way off into the wrong place, not even close to the intended anchor. It seems logical to assume that this "missing the anchor" violates some sort of standard for how anchor links are supposed to be handled, no?
Is it just me, or does that test case appear to work now? I will confirm that the bug that is referenced by the reporter does still appear in Firfox3b4. http://www.onlisareinsradar.com/archives/daily_show_comedy_clips/index.php#001624 was the only link that still is valid in these bug comments that shows the bug in action. This bug has been around for an awfully long time, can anybody point me to the location of scroll handling in the Mozilla codebase so I can make the appropriate edits? I've never worked on the Firefox project before.
I like the direction bug 43114 comment 9 is going. It would fix the onlisareinsradar case perfectly as long as the user doesn't scroll while the images load. If the user does scroll while the images load, it depends on the "relevant piece of content" heuristic, but I bet we can get that right. (The anchor can even serve as a hint as to which part of the document is "relevant"!) To fix this bug for the steps in comment 0, you'd have to add "user indicated a desire to scroll to the bottom" as as one of the reasons for the current scroll position. But this is tricky: you want "reflow due to image sizes becoming known" to take that reason into account, but you might not want "reflow due to more HTML loading" to do the same.
Attachment #147901 - Attachment description: XHTML testcase → XHTML testcase that no longer shows the bug
Attachment #147901 - Attachment is obsolete: true
Keywords: testcase → testcase-wanted
Any update on this issue ?
(In reply to chris roddy from comment #29) > safari and konqueror seem to handle this the way i want. > how are they doing it? (So does Chrome)
See Also: → 712130
See Also: → 1476049

20 years and this bug still exists.

https://playbloodstained.com/it/#order

How about you download Visual Studio and Mercury Mozilla source and fix it yourself? (Not that that is easy, but maybe you're smarter than me)

I'm a Web Developer. As much as I love coding, I'm not going to learn another language just to fix this bug.

Is this fixed with recent sroll anchoring changes?

Indeed.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: