Doc autoscrolling and fading should be smarter

RESOLVED FIXED in 0.9

Status

Add-on SDK
General
RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: adw, Assigned: adw)

Tracking

unspecified

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Assignee)

Description

7 years ago
Created attachment 481207 [details] [diff] [review]
patch

When I implemented the automatic scrolling mechanism in the docs, I only had in mind the links in the sidebar.  Those links are fairly close to the top of the page, so a constant scroll rate isn't bad.  But when you click a link that's far down within content, like the "troubleshooting" link at the very bottom of the Programs page in the Tutorial, it takes forever to scroll to the top.  The scroll rate should be proportional to the distance from the top of the page.  This patch divides the current scrollY by 10 at each interval, which (I think...) approximates exponential decay.  The effect is that scrolling starts fast and eases in as it approaches the top.

This patch also fixes a related annoyance: if you go back or forward in history, the scroll position jumps to the previous content's scroll position, scrolls to the top, the content fades out, then the previous content fades in.  The initial jump is just wrong, and the fades and loss of previous scroll position are pretty annoying when you're trying to quickly go back to content you just looked at.  I fixed both with the same hack: clicking internal links sets a variable, and when it's set, we scroll and fade, and when it's not, we don't.

(At some point we should just either move to frames or load each piece of content as a real page rather than re-using the same page for everything...)
Attachment #481207 - Flags: review?(warner-bugzilla)
(Assignee)

Comment 1

7 years ago
(In reply to comment #0)
> This patch divides the current scrollY by 10 at each interval, which (I
> think...) approximates exponential decay.

Er, divides scrollY by 10 and subtracts that value from scrollY.
(Assignee)

Comment 2

7 years ago
Created attachment 481211 [details] [diff] [review]
patch 2

Missed a spot.
Attachment #481207 - Attachment is obsolete: true
Attachment #481211 - Flags: review?(warner-bugzilla)
Attachment #481207 - Flags: review?(warner-bugzilla)
Comment on attachment 481211 [details] [diff] [review]
patch 2

I like the new scrolling behavior. I see one problem, though (which might have been there before). If I start from a documentation page that's scrolled down just a little bit (for example the "Package Specification" page, scrolled down enough to put the title off the top of the screen but still leaving the "For a gentle introduction.." sidebar visible), then I follow a link to a new page (such as the Packaging link in that sidebar), the new page does not scroll to the top, but instead remains at the small offset that it started at.

Also, if I scroll a page all the way to the bottom, then follow a link (which scrolls the page up to the top before changing the content), then use the "back" button to return to scrolled-to-the-bottom page, that page winds up scrolled somewhere in the middle: not at the bottom, not at the top, but maybe 100 or 200 pixels below the top.

I'm ok with the patch, but if there's an easy way to improve either of those misbehaviors, that'd be doubly awesome.
Attachment #481211 - Flags: review?(warner-bugzilla) → review+
(Assignee)

Comment 4

7 years ago
(In reply to comment #3)
> I like the new scrolling behavior. I see one problem, though (which might have
> been there before). If I start from a documentation page that's scrolled down
> just a little bit (for example the "Package Specification" page, scrolled down
> enough to put the title off the top of the screen but still leaving the "For a
> gentle introduction.." sidebar visible), then I follow a link to a new page
> (such as the Packaging link in that sidebar), the new page does not scroll to
> the top, but instead remains at the small offset that it started at.

Weird, I'm not able to reproduce this.  If I scroll the Package Specification page so that the title is offscreen and then click Packaging, the page scrolls to the top.  I tried on 3.6 and the 4.0 nightly.  I wonder what could be different?

> Also, if I scroll a page all the way to the bottom, then follow a link (which
> scrolls the page up to the top before changing the content), then use the
> "back" button to return to scrolled-to-the-bottom page, that page winds up
> scrolled somewhere in the middle: not at the bottom, not at the top, but maybe
> 100 or 200 pixels below the top.

Yeah, the problem has to do with how the page is modified when you go back.  You go back, the browser automatically restores the old scroll position, but then the current main content div is removed and replaced with the previous one, changing the size of the page twice and screwing up the scroll position.  (You might even notice that the bottom gray bar with the view source link briefly flickers into view.)  I'm not sure what to do about that.
(Assignee)

Comment 5

7 years ago
http://hg.mozilla.org/labs/jetpack-sdk/rev/e092db491b7e
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Target Milestone: -- → 0.9
(Assignee)

Comment 6

7 years ago
(In reply to comment #3)
> I like the new scrolling behavior. I see one problem, though (which might have
> been there before). If I start from a documentation page that's scrolled down
> just a little bit (for example the "Package Specification" page, scrolled down
> enough to put the title off the top of the screen but still leaving the "For a
> gentle introduction.." sidebar visible), then I follow a link to a new page
> (such as the Packaging link in that sidebar), the new page does not scroll to
> the top, but instead remains at the small offset that it started at.

Aha, I see now.  I didn't read closely enough and thought you were talking about the left sidebar, but it's the right sidebar that's the problem.  I landed a follow-up fix that also makes this code more robust by using jQuery's "live" bindings for all anchors in the page rather than modifying anchors one-by-one, which leads to this kind of problem.

http://hg.mozilla.org/labs/jetpack-sdk/rev/95fedbb2bdbd
The Add-on SDK is no longer a Mozilla Labs experiment and has become a big enough project to warrant its own Bugzilla product, so the "Add-on SDK" product has been created for it, and I am moving its bugs to that product.

To filter bugmail related to this change, filter on the word "looptid".
Component: Jetpack SDK → General
Product: Mozilla Labs → Add-on SDK
QA Contact: jetpack-sdk → general
Version: Trunk → unspecified
You need to log in before you can comment on or make changes to this bug.