951746 - window.scroll() doesn't work when dynamically replacing DOM content with shorter content

Status: RESOLVED INCOMPLETE

(Firefox for Android Graveyard :: Toolbar, defect)

Description

[Ben Bucksch (:BenB)]

Environment:
Firefox Android 25
GeckoView nightly 2013-12-05
Android 4.2.x

Reproduction:
1. Page with very long content
2. User scrolls down, and clicks on a link
3. The link runs JS that
3.1. changes the #-tag in the window.location. URL path etc. stays the same.
3.2. replaces the DOM content with new content, which is much shorter
3.3. does window.scroll(0,0) to make sure the new content is visible

Actual result (in some situations, not all):
* The user sees an entirely white screen with no content whatsoever.
* Viewport size is still the same as before, i.e. the smaller content is not reflected
  in the viewport size and (invisible) scroll bar
* Scroll position is still at the old place for the old page, very far down,
  i.e. the window.scroll() had no effect
* The user can manually scroll up by swiping on the screen. However,
  * That's not discoverable.
    Nothing hits at the user that the blank screen is due to scrolling.
  * He has to scroll a lot (many time), because the old page was so long

Expected result:
* Scroll position is at top of page
* Top of page is visible

Conditions:
This doesn't happen in all cases. For one page type that I have, it works, and for another page type, this bug appears.
I have not found out what is causing this, so I can't make a reduced testcase.

Attempted workarounds:
* FAIL: Changing position of window.scroll(), e.g. before emptying the page, after emptying and before filling, or after filling, doesn't change matters, the bug appears in all cases.
* FAIL: Adding a setTimeout() of 3 seconds around the window.scroll() doesn't work.
* PASS: Adding a setTimeout() and an alert() before the window.scroll() fixes it.
* PASS: Adding a setTimeout() of 0ms and a window.getComputedStyle(changedElement) (to force a reflow) before the window.scroll() fixes it.
* FAIL: Adding only a window.getComputedStyle(changedElement) without setTimeout() before the window.scroll() doesn't work.

Related bugs:
Bug 850659 seems to report the same bug, and also states that the reproduction is elusive, but states it's fixed.

Comment 1

[Ben Bucksch (:BenB)]

Reproduction:
1. To disable the workaround I put in place, set browser pref "general.useragent.override"
   to something that does not include "Mobile" and "Gecko"
2. Go to http://bible.bucksch.org/free/
3. Click on "Jesus"
4. Scroll far down
5. Click on a bible verse

If you instead click on another object (event, person, place), the scroll works. I have no idea why it works in one case and not another.

Comment 2

[Ben Bucksch (:BenB)]

Try the same on Firefox desktop. It works fine there. But not in Fennec.

I think this is a race condition. It seems more and more like that. At first, my workaround 4 above was working, but now it doesn't anymore, with practically the same code. I get consistently reproducible results, but when I change the slightest bit, everything changes. Workaround 5 still works, but it's not practical.

Comment 3

[Vitaly Puzrin]

I confirm this bug still exists in FF for android (tested at Nexus S & Nexus 5). My project heavily relies on history api, and does `$('#content').replaceWith(html); $(window).scrollTop(0);` to emulate page change. Scroll is broken in mobile FF for android and ok everywhere else.

Notes:

1. This bug can be partially solved by `setTimeout` before scroll, but small delays are unsafe on big pages, and large delays add unacceptable interface lags. Code: https://github.com/nodeca/nodeca.core/blob/a0e44a38cfa2b156fff079299ebeac1558a987e8/client/common/system/navigate/navigate.js#L86-L89

2. This bug did not happenned when used jquery animation. Probably, because total delay was quite big (300ms). Code: https://github.com/nodeca/nodeca.core/blob/d7e46327777ea9644ec05df589deef915981e167/client/common/system/navigate/navigate.js#L83-L98

3. If you wish to reproduce/play on live site:
  - go to http://dev.nodeca.com/forum/f2
  - scroll down and click "more topics" button, then again, until you load 7 pages
  - click on any topic link in the end of page -> scroll can become broken (blank screen)
  - (!) that does not happens every time, because code already has 50ms delay after "replaceWith()".
    When no delay, scroll is broken always.

Let me know, if i can help, or if you know safe workarounds (without adding big timeouts)

Comment 4

[Aaron Train [:aaronmt]]

I've cc'ed a developer who might now where in the code a potential fix could be applied and might provide some insight on your findings above.

Comment 5

[Kartikaya Gupta (email:[e-mail])]

It certainly does sound like this is a race condition of some sort in the Fennec code. Unfortunately things like this are pretty hard to track down and we've been more focused on getting Firefox OS up to speed lately. However I plan on reworking a lot of the Fennec code in the near future as we switch the panning/zooming code to a different implementation and once that happens this bug should go away. I'm marking this bug as dependent on the rewrite.

Comment 6

[BMO Automation]

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.