Closed Bug 1003800 Opened 8 years ago Closed 10 months ago

Wrong scroll position after restoring from previous session

Categories

(Firefox for Android Graveyard :: Toolbar, defect)

29 Branch
All
Android
defect
Not set
minor

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: esawin, Unassigned)

Details

STR
1. Enable tabs restoring (Settings/Customize/Tabs->Always restore).
2. Open a web document, do not scroll or zoom, but make sure the document does not fit into the screen and is therefore scrollable (landscape mode preferred).
3. Close Fennec using the Android task manager.
4. Launch Fennec again.

Expected
The tabs are restored with the scroll position being at top left.

Actual
The tabs are restored but the document view is scrolled down by an indefinite amount.

It's and intermittent bug, so it's not consistently reproducing (about 50% when tested on news.ycombinator.com with Nexus 7 in landscape mode).

Because of bug 810981, I do not think that it's connected to the session storage (bug 697858), this could be completely unrelated.
Reproducing on all tested versions (29 - 31) for me.
(In reply to Eugen Sawin [:esawin] from comment #0)
> ...
> Actual
> The tabs are restored but the document view is scrolled down by an
> indefinite amount.
> 
> It's and intermittent bug, so it's not consistently reproducing (about 50%
> when tested on news.ycombinator.com with Nexus 7 in landscape mode).

As in, the amount we're scrolled down is random and different between multiple runs when the bug reproduces?  It does sound like we either don't store or don't restore the value, or restore without knowing we restored - this last one could be a panning issue.  I don't think the existence of bug 810981 is indicative, as that just reports that we don't record the position, but always go back to top left - in this bug, we actually don't go to top left.

Brian, what do you think?
Flags: needinfo?(bnicholson)
Here is a video running on Nexus 7 (2013) Fennec 29: http://youtu.be/CQ0G3lbUmYA
The scrolled amount seems to be always the same, maybe site specific.
Following these STR, I hit bug 1002426 (broken zoom level), but not this one.

The only APZC-related code in SessionStore.js is the scroll serialization/deserialization at http://mxr.mozilla.org/mozilla-central/source/mobile/android/components/SessionStore.js#663. I tried a build with that code removed, and I still hit the zoom issue. So I don't think this problem is directly related to the session restore code.
Flags: needinfo?(bnicholson)
Here is another manifestation of the bug on Nexus 7 (2013) on latest m-c: http://youtu.be/mjveeGP4CGs
Maybe that's what you are hitting, Brian?
I've disabled zoom level restoring for this one, so it's not related to it.
As I've noted in the the description, I agree that it doesn't seem to be connected to session store at all.

This is reproducing on current release version (29), so it's not connected to bug 1002426, which depends on bug 611556, which has only landed on 31+.
Looking at this bug and reviewing the videos above, makes me believe this is related to what esawin and I discussed on irc earlier. On my GS3 using arstechnica.com as a test ...


Normal Open in portrait: https://www.dropbox.com/s/3nszqdjm2pmue1y/bugS3NormalPort.png

Swipe close and re-open in portrait: https://www.dropbox.com/s/989bovx1d095h5u/bugS3RestorePort.png
   (scrolled ok, but zoomed odd)


Normal open in landscape: https://www.dropbox.com/s/86bfqpngt3r65ai/bugS3NormalLand.png

Swipe close and re-open in landscape: https://www.dropbox.com/s/r0yfhnfoj6vzvuy/bugS3RestoreLand.png
   (zoomed ok, but scrolled odd)
I think the issue looks similar to this, but based on this:
> < capella> esawin: fyi, refreshing my repos and building, I now see the issue in aurora,
> and beta, and last nights builds from nightly.mozilla.org, but not FF from playstore
it looks like it's reproducing on 30+, while the scrolling issue described in this bug is also reproducing on 29.
At the same time, it rules out bug 1002426, since that was a regression on 31+.
This could be unrelated, after all.
Removing keyword, since it's intended for test failures that are seen on Treeherder (and otherwise you'll end up with bugs being marked as worksforme if no occurrences are seen on Treeherder).
We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.
Status: NEW → RESOLVED
Closed: 10 months ago
Resolution: --- → INCOMPLETE
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.