Closed Bug 1093179 Opened 6 years ago Closed 6 years ago

Page-position on m.diepresse.com not always remembered when navigating back

Categories

(Firefox for Android :: Toolbar, defect)

36 Branch
ARM
Android
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME
Tracking Status
fennec + ---

People

(Reporter: philipp, Assigned: esawin)

References

()

Details

when reading an article on the mobile website of the newspaper diepresse.com, hitting the back button doesn't land you on the prior scroll where you left reading on the prior page but it will load just on top of the page in most cases.

i can reproduce it on a htc one s and current versions of firefox on android up to the latest nightly version (but it was the same since as long as i can remember) like this:
- go to http://m.diepresse.com/home/index.do (if you're not served the mobile version right from the start, tap on "Mobil" on the top left corner of the page)
- scroll down a bit and tap on any article
- hit the back button, which will land you on the top of the prior page and not at the scroll position where you've left
Was this behaviour different on this page prior to landing bug 942736?
(In reply to Aaron Train [:aaronmt] from comment #1)
> Was this behaviour different on this page prior to landing bug 942736?
no, it remained the same before and after the fix for bug 942736 landed. it was requested there that i file a new bug for this particular issue.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Eugen, any ideas?
tracking-fennec: --- → ?
Flags: needinfo?(esawin)
Not yet, but I can have a look at it this week.
Flags: needinfo?(esawin)
Assignee: nobody → esawin
tracking-fennec: ? → +
This one is tricky. I can reproduce it most of the times for the given URL but only when viewing the mobile version of the page. Let me summarize my findings:

* it only reproduces for the mobile page version
* in about 1% of the tries, the scroll position is being restored correctly in GeckoLayerClient::setFirstPaintViewport with the correct offsets
* when restoring a previous session (with tabs restoring enabled) we set an incorrect scrolling position for the active and history pages, but this seems to be a different issue related to zooming constraints
* we never get an "UPDATE" viewport message when restoring
* we do handle "scroll" events in browser.js, but never with the correct scroll position (that's how the scroll position reaches browser.js for other pages to trigger a viewport update)

Are we supposed to load "mobile" pages differently and if so, what would be the correct way to restore scroll position in that case?
Flags: needinfo?(bugmail.mozilla)
No, as far as I know "mobile" pages should be the same as non-mobile pages in this respect. It's not clear to me from what you said why this is happening.
Flags: needinfo?(bugmail.mozilla)
Something on the part of the site has changed since a couple of days and the issue described initially can no longer be reproduced.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.