Closed Bug 1062859 Opened 10 years ago Closed 7 years ago

Inconsistent scroll position when navigating through bookmark folders

Categories

(Firefox for Android Graveyard :: Awesomescreen, defect)

Product:
Firefox for Android Graveyard
Component:
Awesomescreen
Version:
31 Branch
Platform:
All
Android
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(firefox54 fixed)

Status:
RESOLVED FIXED
Milestone:
Firefox 54
Tracking Flags:
Tracking Status
firefox54 --- fixed

People

(Reporter: JanH, Assigned: JanH)

References

Details

Attachments

(2 files)

Bug 1062859 - Part 0 - Bookmarks panel cleanups.
59 bytes, text/x-review-board-request
ahunt
: review+
Details
Bug 1062859 - Part 1 - Restore scroll position when going back through bookmark folders.
59 bytes, text/x-review-board-request
ahunt
: review+
Details 
Steps through to reproduce:
1. Sync your mobile device with a desktop with a sufficient number of bookmarks and folders, so you have to scroll around a bit when navigating through the bookmarks on mobile.
2. On mobile, go to your desktop bookmarks, and scroll down a bit and then open a sub-folder with a large-ish number of bookmarks/folders within (you might need to rearrange your bookmarks on desktop for testing).
3. In the sub-folder, scroll back to the top, then press the back button.
4. Scroll down again, and this time open a sub-folder with only a few bookmarks within it.
5. Go back again.

What happens:
The scroll position gets remembered while navigating across folders, unless the folder being navigated to is so small that the scroll position gets truncated at the bottom of the screen.
So, after step 2, because you previously were somewhere in the middle of your desktop bookmarks, the sub-folder opens with the scroll position being somewhere in the middle of the folder, too. If e.g. you want to open another sub-folder (a sub-sub-folder) which is located at the top of the sub-folder, you first have to scroll back to the top.
If you've scrolled to the top of the sub-folder, and then decide to go back to the parent folder (step 3), you'll find yourself at the top of the parent folder instead of where you originally started.
If the sub-folder is small enough that it requires no scrolling, this means that the scroll position automatically gets reset to the top of the page, whether you want it or not (step 4 and 5).

If you simply open a sub-folder and then immediately go back, this leads to some inconsistent behaviour, becomes sometime your original scroll position is remembered, and sometimes it isn't (depending on how far you scrolled down in the parent folder, and how large the sub-folder is).

What should happen:
When opening a sub-folder, the current scroll position should be saved. Then the sub-folder should be opened with the scroll position at the top of the folder. When going back to the parent folder, the previously saved scroll position should be restored.

Further Infos:
Device: Samsung Galaxy S3 Mini, Android 4.1.2
Tested with FF31 and a yesterday's Nightly
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
Bug 1060544 changed its scope and consequently never resolved this issue.

(In reply to Jan Henning [:JanH] from comment #0)
> What should happen:
> When opening a sub-folder, the current scroll position should be saved. Then
> the sub-folder should be opened with the scroll position at the top of the
> folder. When going back to the parent folder, the previously saved scroll
> position should be restored.

A possible simplification, so we don't have to remember the scroll positions of all parent folders: When going up a folder level, just scroll the list so that the folder we just exited is at the top of screen.
Blocks: bookmark-folders
Status: RESOLVED → REOPENED
Ever confirmed: true
Hardware: ARM → All
Resolution: DUPLICATE → ---
Summary: Inconsistent scroll position when navigating through bookmarks → Inconsistent scroll position when navigating through bookmark folders
Actually it does seem easier after all to just store the scroll position of the list view when going down and then restore that when coming back up the folder chain.
Assignee: nobody → jh+bugzilla
If you've got any feedback on this proposed behaviour, here's a try build:
https://queue.taskcluster.net/v1/task/SBchtkFBSka9K3nEaZbnCw/runs/0/artifacts/public/build/target.apk
Flags: needinfo?(alam)
Comment on attachment 8829276 [details]
Bug 1062859 - Part 0 - Bookmarks panel cleanups.

https://reviewboard.mozilla.org/r/106380/#review109266
Attachment #8829276 - Flags: review?(ahunt) → review+
Comment on attachment 8829277 [details]
Bug 1062859 - Part 1 - Restore scroll position when going back through bookmark folders.

https://reviewboard.mozilla.org/r/106382/#review109272

Yay, this is cool!

::: mobile/android/base/java/org/mozilla/gecko/home/BookmarksPanel.java:298
(Diff revision 2)
>              if (args == null) {
>                  return new BookmarksLoader(getActivity());
>              } else {
>                  FolderInfo folderInfo = (FolderInfo) args.getParcelable(BOOKMARKS_FOLDER_INFO);
>                  RefreshType refreshType = (RefreshType) args.getParcelable(BOOKMARKS_REFRESH_TYPE);
> -                return new BookmarksLoader(getActivity(), folderInfo, refreshType);
> +                int targetPosition = args.getInt(BOOKMARKS_SCROLL_POSITION);

nit: final : )
Attachment #8829277 - Flags: review?(ahunt) → review+
Pushed by ryanvm@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/6545d3df6dcf
Part 0 - Bookmarks panel cleanups. r=ahunt
https://hg.mozilla.org/integration/autoland/rev/185b45c00b7b
Part 1 - Restore scroll position when going back through bookmark folders. r=ahunt
Keywords: checkin-needed
Flags: needinfo?(alam)
^oops! I cleared the NI by accident.

Some context while I'm here:

It might help to know that the current design is not by accident. Nor was it done on a whim. :)

Right now, it's a part of our larger "Save, Share, and Revisit" story and all three panels are designed to help support this User Research work. As we work towards improving this experience in the big picture, I think we need to carefully consider our options here.

Let's hold off on this suggestion for now. Also going to NI Product here to make sure they're included in the conversation.
Flags: needinfo?(bbermes)
(In reply to Anthony Lam (:antlam) from comment #15)
> It might help to know that the current design is not by accident. Nor was it
> done on a whim. :)

Not doubting this for the bookmarks panel as a whole, but including this particular behaviour? That would seem somewhat... strange.

If I'm in a large bookmarks folder with several screen heights worth of subfolders and bookmarks, have scrolled down some amount and then open another large subfolder, it doesn't really make sense from a user facing perspective that this subfolder should then be opened scrolled down as well. Imagine if website navigation worked that way - I click on some link halfway down the page, so the new page opens scrolled halfway down as well.
This feels more like something that was either never really noticed during the original development or else was categorised as "We can always fix this later".
https://hg.mozilla.org/mozilla-central/rev/6545d3df6dcf
https://hg.mozilla.org/mozilla-central/rev/185b45c00b7b
Status: REOPENED → RESOLVED
Closed: 10 years ago → 7 years ago
status-firefox54: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 54
Definitely unpleasant scenario, but won't happen that often, i.e. only for bookmark power users how have synced their Desktop bookmarks and use them on mobile.

Unfortunately, we don't know how many folders users normally maintain, but we know that only ~50% of our users manage bookmarks in folders: https://mail.mozilla.org/pipermail/fhr-dev/2016-March/000865.html

We are working on improving bookmarks, including adding the capability to add/remove folders on mobile, and eventually, this issue will become more apparent then.

Let's look at this again once we've added the folder management feature to mobile (NIing Joe/Rachelle).
Flags: needinfo?(ryang)
Flags: needinfo?(jcheng)
Flags: needinfo?(bbermes)
needinfo Wesley as well for status sync and update of bookmark management.
Flags: needinfo?(ryang) → needinfo?(whuang)
yup. agree with Barbara that we take a look at this as we implement folder management features
Flags: needinfo?(jcheng)
Flags: needinfo?(whuang)
Depends on: 1339737
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: