Closed Bug 755770 Opened 12 years ago Closed 3 years ago

Scroll position seemingly not preserved when font inflation causes relayout

Categories

(Firefox for Android Graveyard :: Toolbar, defect, P5)

ARM
Android
defect

Tracking

(firefox30 affected, firefox31 affected, firefox32 affected, firefox33 affected, firefox34 affected, blocking-fennec1.0 soft)

RESOLVED INCOMPLETE
Tracking Status
firefox30 --- affected
firefox31 --- affected
firefox32 --- affected
firefox33 --- affected
firefox34 --- affected
blocking-fennec1.0 --- soft

People

(Reporter: kumar, Unassigned)

References

(Depends on 1 open bug, )

Details

(Whiteboard: readability)

Fennec Nightly 15.0a1 (2012-05-16)

Steps to reproduce:

- switch the phone to portrait mode
- load a URL with an anchor, like http://infrequently.org/2012/02/misdirection/comment-page-1/#comment-239566
- scroll halfway down
- switch the phone to landscape (as if by accident)
- switch it back to portrait to continue reading where you left off

Actual results:
The scroll position is completely lost. It looks like the page was re-scrolled all the way to the top.

Expected results:
The scroll position should remain exactly where you were when you switched orientation

Is this a regression of bug 715898 ?
This is actually not an anchor problem, but actually a font inflation problem. The same behaviour happens even if you just load the page without the anchor in the URL (i.e. http://infrequently.org/2012/02/misdirection/comment-page-1). What's happening is when you rotate the device we adjust the zoom level so that the full page width still fits in the screen. This means the zoom factor is smaller in portrait than in landscape, so font inflation inflates the font more in portrait than it does in landscape. This affects the layout of the page, so it looks like the scroll position is lost when really we have maintained the scroll position and the page has changed.

You can verify this behaviour by going into the browser settings and setting the "Text size" option to "Tiny", which disables font inflation.

Not sure what we should do here, since it does appear to be an error from the user's point of view. CC'ing :jwir3 to see if he has any ideas. Would it be possible to get a scroll position delta out of the font inflation code that would allow us to reposition based on how the relayout moved content around?
blocking-fennec1.0: --- → ?
Whiteboard: readability
Summary: Scroll position not preserved between orientation changes (anchor URLs?) → Scroll position seemingly not preserved when font inflation causes relayout
Assignee: nobody → bugmail.mozilla
blocking-fennec1.0: ? → soft
(In reply to Kartikaya Gupta (:kats) from comment #1)
> This is actually not an anchor problem, but actually a font inflation
> problem. The same behaviour happens even if you just load the page without
> the anchor in the URL (i.e.
> http://infrequently.org/2012/02/misdirection/comment-page-1). What's
> happening is when you rotate the device we adjust the zoom level so that the
> full page width still fits in the screen. This means the zoom factor is
> smaller in portrait than in landscape, so font inflation inflates the font
> more in portrait than it does in landscape. This affects the layout of the
> page, so it looks like the scroll position is lost when really we have
> maintained the scroll position and the page has changed.

Right, so because the screen size has changed, we may have more (or less) room to inflate fonts, since we're changing the width of the screen. We need to recompute our font inflation data, so it's entirely possible that the scroll position is in fact reset as a result of the fonts being re-laid out.

> Not sure what we should do here, since it does appear to be an error from
> the user's point of view. CC'ing :jwir3 to see if he has any ideas. Would it
> be possible to get a scroll position delta out of the font inflation code
> that would allow us to reposition based on how the relayout moved content
> around?

I think we could do this. I'm not sure if we can get it exact, but I'm pretty sure we can get it close. We'll probably need to check for scroll position whenever we move from portrait to landscape (or vice versa), and cache that temporarily while the reflow happens. Then, once the layout is finished, we will need to compute a transform from one scroll position to a new scroll position, given the new inflation values. 

The only hard part is that since the font inflation values can vary across the page, (some blocks might change inflation and some might not), we might have difficulty coming up with an exact mapping. We could probably cheat, though, and scroll to a given block. Or, perhaps it would be even easier and we could just scroll down the page a given percentage of the entire page...
This will require changes in the font inflation code first, so unassigning from myself. Feel free to send it back to me for fennec front-end integration work.
Assignee: bugmail.mozilla → nobody
(In reply to Kartikaya Gupta (:kats) from comment #3)
> This will require changes in the font inflation code first, so unassigning
> from myself. Feel free to send it back to me for fennec front-end
> integration work.

I'll handle the platform code.
Assignee: nobody → sjohnson
Component: General → Graphics, Panning and Zooming
Another example of the impact of this is http://lwn.net/Articles/508218/. For much of the page rotating from portrait to landscape and back preserves the scroll position; but below a certain point scroll position is lost completely.


On a 480 x 800 screen phone with Text size "Small":

1. Scroll to the article "TCP Fast Open: expediting web service" and further down so that the Figure 1 caption is at the bottom of the page,
2. Rotate from Portrait to Landscape and Back to Portrait.
-> The page is back at Figure 1.

3. Repeat for Figure 2 or 3.
-> The page is slightly above Figure 2

4. With the Figure 3 caption just scrolled off the top of the page,
5. Rotate from Portrait to Landscape.
-> The page is scrolled to the top and slightly zoomed in on the left-hend corner.


With font inflation disabled all these cases work as expected.
Depends on: 43114
Priority: -- → P2
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #1)
> You can verify this behaviour by going into the browser settings and setting
> the "Text size" option to "Tiny", which disables font inflation.

Doing this fixes the bug for the URL given above, but not for http://9gag.com/ or http://m.heise.de/ or various other websites, so I was wondering if there is / should be a bug with a wider scope. (Google Chrome handles orientation changes really well on those websites.)
The bug is easily reproducible on planet.mozilla.org website;
tracking-fennec: --- → ?
Assignee: jaywir3 → nobody
tracking-fennec: ? → +
This bug is old and no more progress for more than 2 years, so I am removing the tracking flag now.
feel free to renominate. 

Thank you !
tracking-fennec: + → ---
Priority: P2 → P5
On a new phone with a a bigger screen than my last one (Sony XZ1) and am surprised to find myself encountering this bug again. Repeating my test of comment #7 I see swapping from portrait to landscape and back loses scroll position when I'm far enough down the page that switching to landscape takes me to the end of the page.

e.g.

0. In portrait, go to http://lwn.net/Articles/508218/ and scroll to the article "TCP Fast Open: expediting web service"

1. Scroll down to the sub-heading "The user-space API"

2. Scroll up a little, e.g. to the paragraph ending "...remains an open question.)"
2a. Rotate to Landscape
-> We are scrolled to near the bottom of the page, with the line "PCI-Express Non-Transparent Bridge Support" near the top of 
the screen.
2b Rotate back to Portrait
-> The view on the screen is back to where it started.

3. Now scroll some way past the sub-heading from (1), e.g. so that the line "The changes required to a client..." is at the top of the screen.
3a. Rotate to Landscape
-> The screen shows the very bottom of the page
3b Rotate back to Portrait
-> The screen is scrolled to a position above where we started in (3), it now has the sub-heading "The user-space API" in the middle of the view.

This is with a recently installed firefox 61.0 on android 8.0.0 on a 1080x1920 display. I didn't think font inflation was enabled (or even available?) any more so don't know what settings to flip to see if it will make a difference.
Re-triaging per https://bugzilla.mozilla.org/show_bug.cgi?id=1473195

Needinfo :susheel if you think this bug should be re-triaged.
(In reply to Oliver Henshaw from comment #17)
> This is with a recently installed firefox 61.0 on android 8.0.0 on a
> 1080x1920 display. I didn't think font inflation was enabled (or even
> available?) any more so don't know what settings to flip to see if it will
> make a difference.

Behind the scenes, enabling "Use system font size" still uses font inflation.

On the other hand, though, a) LWN uses <meta name="viewport" content="width=device-width> and therefore won't be affected by font inflation, and b) in any case I'm seeing this even with "Use system font size" turned off. So best to file a separate bug for this.
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: 3 years 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.