Pages with position:fixed banners/headers are all the rage these days. But when I try to read content inside one of these pages and hit Page Down or Spacebar, firefox calculates the page length relative to the whole browser window, not just the part visible underneath the position:fixed header. So it scrolls too much, and the first few lines of the next page end up hidden, and I have to hit up-arrow two or three times after every Page Down. For instance, go to http://www.raspberrypi.org/phpBB3/viewtopic.php?t=12323&p=132085 (or any other page in that forum), note the last line visible, and hit Page Down. Now hit up-arrow a couple of times and noticed that there were several lines that got skipped. I checked chromium and it does the right thing (only scrolls the visible part of the page) so I don't think it's a bug in the page (and I'm seeing this on lots of different sites). But of course I don't want to use chromium, I want to use firefox. :) It might be a regression -- I never used to see this, but maybe it's just that these fixed banners have gotten a lot more common. I'm surprised I couldn't find this bug already filed; it might be related to (but isn't the same as) bug 162369 and bug 414317.
Sorry, make that second bug 354066 -- I don't think 414317 is related.
I don't think it's a regression. I think it's just that these sorts of pages have become more common.
We'll need some heuristics here. There can be fixed-pos header or footer elements that don't actually obscure page content and therefore ideally wouldn't affect scroll distance, but there's probably no foolproof way to distinguish those from the elements that should affect scroll distance. When in doubt, I suppose we should err on the side of scrolling a bit less, although we can't allow the scroll distance to decrease too much.
(In reply to Akkana Peck from comment #0) > I checked chromium and it does the right thing (only scrolls the visible > part of the page) so I don't think it's a bug in the page (and I'm seeing > this on lots of different sites). FWIW I don't see Chrome 22 dev doing anything special. If I make the window small then I can definitely skip lines as I scroll down. Can you come up with a simple testcase that shows Chrome scrolling differently based on whether a fixed-pos element is present or absent?
Assignee: nobody → roc
Attachment #649178 - Flags: review?(tnikkel)
+/** + * Compute the scrollport size excluding any fixed-pos headers and + * footers. A header or footer is an box that spans that entire width + * of the viewport and touches the top (or bottom, respectively) of the + * viewport. Headers and footers that cover more than a quarter of the + * the viewport are ignored since they probably aren't true headers and + * footers and we don't want to restrict scrolling too much in such cases. + * This is a bit conservative --- some pages use elements as headers or + * footers that don't span the entire width of the viewport --- but it + * should be a good start. + */ It works well on many pages. No doubt there are some pages it doesn't work on. It seems like a good idea to start conservatively here. BTW Akkana, thanks for the idea. This had been bothering me subtly for a long time but I never got around to thinking about the problem :-). More ideas for easy-to-implement wins welcome :-).
Comment on attachment 649178 [details] [diff] [review] fix Nice. Sorry for the delay.
Attachment #649178 - Flags: review?(tnikkel) → review+
Backed out for failures in test_page_scroll_with_fixed_pos.html: https://tbpl.mozilla.org/?tree=Mozilla-Inbound&rev=f67014b40e1e https://hg.mozilla.org/integration/mozilla-inbound/rev/1f9d563e8542
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla17
OS: Linux → All
Hardware: x86 → All
Version: 1.9.1 Branch → Trunk
One of the bugs in this push caused bug 782196: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=b753e1dce89f&tochange=94e4dbce3b94
(In reply to Akkana Peck from comment #0) > I checked chromium and it does the right thing (only scrolls the visible > part of the page) so I don't think it's a bug in the page (and I'm seeing > this on lots of different sites). But of course I don't want to use > chromium, I want to use firefox. :) It might be a regression -- I never used > to see this, but maybe it's just that these fixed banners have gotten a lot > more common. The real right thing to do, by the page author, is either to let the banner be scrolled or to put it outside the scrollable area. > so I don't think it's a bug in the page (and I'm seeing > this on lots of different sites). In my not-so-humble opinion, *it is a bug in the page*. The word "bug" can be discussed. But it is *a bad thing* in the page. An irritating trend. Anyway, this kind of adjustment in the browser is a good idea.
Oh, I agree -- it's really annoying that site designers do that and I wish they wouldn't. But since they do, this fix is wonderful and has made it much easier to follow threads on sites like LinkedIn. THANK YOU!
It's been over 1.5 years now, and I do not notice that Firefox 33 would save me from those websites. What happened to the bug?
(In reply to Martin Ueding from comment #15) > It's been over 1.5 years now, and I do not notice that Firefox 33 would save > me from those websites. What happened to the bug? It's unclear what you're asking about. This bug is marked as FIXED; patches landed to fix it, in Firefox 17, over 2 years ago. Are you talking about a something that was broken by the changes here? If there's a bug filed on the issue you're describing, you probably want to comment on that bug. (or if there isn't, you should probably file a new bug with more details.)
(In reply to Daniel Holbert [:dholbert] from comment #16) > It's unclear what you're asking about. This bug is marked as FIXED; patches > landed to fix it, in Firefox 17, over 2 years ago. Are you talking about a > something that was broken by the changes here? When I use the space bar to scroll down on a website which has some fixed elements, it scroll too much, at least on the websites that I used. Then I searched the web for a solution to this and found this bug. Since I use the latest Firefox, but still have this issue on some websites, I thought that this bug might not be fixed fully yet.
Not Firefox-specific, but I still run into this problem frequently, e.g., on this page: http://www.nytimes.com/2015/11/15/travel/denver-airport-kim-day.html?_r=1 Scrolling with space bar is broken on that page in the latest Firefox, Chrome, and Safari on Mac (i.e., it scrolls a bit too far, skipping a couple of lines). FF could differentiate itself by doing "the right thing" here. Let me know if I should open a new bug for this issue.
(In reply to Manu Sridharan from comment #18) > Let me know if I should open a new bug for this issue. Please do. Definitely better than adding comments to a bug that was closed over 3 years ago.
I added a comment on Bug 1081272, which might capture the new issue.
You need to log in before you can comment on or make changes to this bug.