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

NEW
Unassigned

Status

()

Core
Layout
17 years ago
2 months ago

People

(Reporter: Jesse Ruderman, Unassigned)

Tracking

(Depends on: 2 bugs, {testcase-wanted})

Trunk
testcase-wanted
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 obsolete attachment)

(Reporter)

Description

17 years ago
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

Comment 2

17 years ago
Scrolling issue...starting off with Eric.
Assignee: harishd → evaughan

Updated

17 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.8

Comment 3

17 years ago
->moz0.9
Target Milestone: mozilla0.8 → mozilla0.9

Comment 4

17 years ago
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?

Comment 5

17 years ago
->moz1.0
Target Milestone: mozilla0.9 → mozilla1.0

Comment 6

16 years ago
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.

Comment 7

16 years ago
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. ***

Comment 9

16 years ago
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. ***
(Reporter)

Comment 11

15 years ago
*** Bug 89552 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 12

15 years ago
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.

Comment 13

15 years ago
*** 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. ***

Comment 19

14 years ago
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.

Comment 20

14 years ago
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.
(Reporter)

Updated

14 years ago
*** 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. ***

Comment 25

13 years ago
*** Bug 239002 has been marked as a duplicate of this bug. ***

Comment 26

13 years ago
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

Comment 27

13 years ago
Created attachment 147901 [details]
XHTML testcase that no longer shows the bug

Note this testcase doesn’t bother scrolling the page at all, leaving the user
at the top of the document.

Updated

13 years ago
Keywords: testcase
*** Bug 140455 has been marked as a duplicate of this bug. ***
Depends on: 103279

Comment 29

13 years ago
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. ***

Comment 33

13 years ago
*** Bug 277969 has been marked as a duplicate of this bug. ***
*** Bug 297907 has been marked as a duplicate of this bug. ***

Comment 35

12 years ago
*** Bug 302771 has been marked as a duplicate of this bug. ***
*** Bug 292056 has been marked as a duplicate of this bug. ***
(Reporter)

Updated

12 years ago
Assignee: eric → nobody
Status: ASSIGNED → NEW
Priority: P3 → --
QA Contact: chrispetersen → layout
Target Milestone: mozilla1.0.1 → ---

Comment 37

12 years ago
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

Comment 38

12 years ago
(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.

Comment 39

12 years ago
(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!

Comment 40

12 years ago
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.

Comment 41

12 years ago
*** Bug 302642 has been marked as a duplicate of this bug. ***

Comment 42

12 years ago
*** Bug 322144 has been marked as a duplicate of this bug. ***

Comment 43

10 years ago
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?

Updated

10 years ago
Duplicate of this bug: 388679

Comment 45

9 years ago
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.
(Reporter)

Comment 46

8 years ago
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.
(Reporter)

Updated

7 years ago
Attachment #147901 - Attachment description: XHTML testcase → XHTML testcase that no longer shows the bug
Attachment #147901 - Attachment is obsolete: true
(Reporter)

Updated

7 years ago
Keywords: testcase → testcase-wanted
Duplicate of this bug: 654947

Updated

3 years ago
Duplicate of this bug: 1001274

Comment 49

3 years ago
Any update on this issue ?
Duplicate of this bug: 1060124

Comment 51

3 years ago
(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)

Updated

3 years ago
See Also: → bug 712130

Updated

a year ago
Duplicate of this bug: 1280770
You need to log in before you can comment on or make changes to this bug.