Closed
Bug 780345
Opened 13 years ago
Closed 13 years ago
Page down scrolls too far on pages with fixed header elements (page size is miscalculated)
Categories
(Core :: Layout, defect)
Core
Layout
Tracking
()
RESOLVED
FIXED
mozilla17
People
(Reporter: akkzilla, Assigned: roc)
References
(Depends on 2 open bugs)
Details
Attachments
(1 file)
7.26 KB,
patch
|
tnikkel
:
review+
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Comment 1•13 years ago
|
||
Sorry, make that second bug 354066 -- I don't think 414317 is related.
Assignee | ||
Comment 2•13 years ago
|
||
I don't think it's a regression. I think it's just that these sorts of pages have become more common.
Assignee | ||
Comment 3•13 years ago
|
||
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.
Assignee | ||
Comment 4•13 years ago
|
||
(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 | ||
Comment 5•13 years ago
|
||
Assignee: nobody → roc
Attachment #649178 -
Flags: review?(tnikkel)
Assignee | ||
Comment 6•13 years ago
|
||
+/**
+ * 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 7•13 years ago
|
||
Comment on attachment 649178 [details] [diff] [review]
fix
Nice. Sorry for the delay.
Attachment #649178 -
Flags: review?(tnikkel) → review+
Assignee | ||
Comment 8•13 years ago
|
||
Comment 9•13 years ago
|
||
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
Assignee | ||
Comment 10•13 years ago
|
||
Comment 11•13 years ago
|
||
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla17
Updated•13 years ago
|
OS: Linux → All
Hardware: x86 → All
Version: 1.9.1 Branch → Trunk
Comment 12•13 years ago
|
||
One of the bugs in this push caused bug 782196:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=b753e1dce89f&tochange=94e4dbce3b94
Comment 13•12 years ago
|
||
(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.
Reporter | ||
Comment 14•12 years ago
|
||
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!
Comment 15•10 years ago
|
||
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?
Comment 16•10 years ago
|
||
(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.)
Comment 17•10 years ago
|
||
(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.
Comment 18•9 years ago
|
||
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.
Comment 19•9 years ago
|
||
(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.
Comment 20•9 years ago
|
||
I added a comment on Bug 1081272, which might capture the new issue.
Comment 21•9 years ago
|
||
(Thanks! That bug is likely what comment 15 / comment 17 here were really about, too.)
You need to log in
before you can comment on or make changes to this bug.
Description
•