Forum.onlyoffice.com: when attaching a google file, the scrolling of the message trembles up and down

Cloud
1

ONLYOFFICE cloud: Forum website
Action: Report a bug
Browser version: recent Firefox
Affected devices: Xiaomi Redmi 12C

The funny and strange problem I encountered a few months ago. When browsing the OnlyOffice forum, if the message viewed contains a google drive link box (and possibly other), such message begins to tremble if scrolled to specific position range. I’m quite sure this is due to evil ‘scroll helper’ feature introduced in either or both Android 13 (or 12) OS or MIUI 14 (or 13) OS (excluding the variant of Android OS without MIUI), I noticed a subtle tremble during slow-rate scrolling in other apps. The Xiaomi Redmi 5 is unaffected and scrolls smoothly. So this problem may be not on the side of the OnlyOffice app, but maybe the OnlyOffice team should be aware of this thing and could develop some countermeasures. The video of this behavior of the OnlyOffice forum website is applied here, the true rate of the tremble is approximately 12-16 hz:

2

Hello @dimm
Wow, I haven’t seen this before. It seems that it is related to Discourse engine of the forum itself. However we have to figure out the exact reasons. We have started our investigation. Thank you for pointing us to it! I will update this thread when we have something to share.

4

Update:

The issue is unrelated to the presence of the link boxes. The reason for the tremble is the disappearance of the progress gauge at the bottom of the page, the tremble amplitude corresponds to its height. But still, the ‘scroll helper’ feature may be involved as the reason of this mess.

The mechanics of the bug is the following:

When the page is scrolled to the point where the progress gauge should disappear, so it does, shifting the page scroll position upwards, the height of this shift is very close to the height of the gauge. At the shifted position, the progress gauge is forced to appear again, shifting the page scroll position downward with the same amount of the shift distance. And so on.

The easy-to-go fix for this misbehavior is to untie the shifting of the scroll position from the appearance/disappearence of the progress gauge, because that two occasions really should not mutually depend on each other.

5

Maybe the shifts occur because the progress gauge wrongly contributes to the calculated height of the page.

6

Hello @dimm
Thank you for the additional details, we are checking the situation.

8

Hello @dimm
We have implemented necessary changes. It should work smoothly now.

9

Much better! The big bug was eliminated, a few minor bug features appeared instead.

The scrolling is really smooth now, the only mistreat of a really slow scrolling is now only on the OS MIUI 14 side of my Xiaomi Redmi 12C. The Xiaomi Redmi 5 is scrolling very smoothly.

I noticed that the forum engine was severely rewritten (possibly upgraded) in order to improve the behavior of the forum. It was success but also a source of the bug features mentioned. They are the following:

a) The fresh-cache loading speed.

If the page is loaded first time, my bandwidth was underused to the speed of 50-60 kilobytes per second, thus loading the whole page in some 35 seconds. I could treat this as a temporary problem of the network, if not the latter stage of the loading: after the page was displayed, the additional (background) loading was at some 150 kilobytes per second, clearly displaying that the lower speed of the loading is the page loading management problem. Consider the loading speed study and optimization. The possible reason for such a low speed of the loading I guessed the one-after-another loading order of a many files of small sizes instead of loading them at once or as a bunch. The funny thing is that this problem is only reproduced on the Xiaomi Redmi 12C MIUI 14.0.3. The Redmi 5 is unaffected, loading all of the page at stable ~150 kb/s, which I consider a normal behavior.

The estimated size of the initial load of the page is some huge 2Mb, with the browser cache storing only 150kb. The rest is stored in the device’s operative memory, obviously.

The subsequential loading of the page is free from this problem, taking advantage of the page files previously loaded in the device memory, so it’s only a first-time story, but the 40 seconds waiting is thrice more than some 12s of the previous version of the forum, hence this bugreport.

b) The URL blink.

If the user rises his touch during special conditions met, the URL line of a Firefox browser is briefly refreshed, giving the sense of redirect conducted, and thus, of unstability. That special conditions are the following:
– the upper edge of the displayed page must be on a post message text when the touch is released;
– that upper post message must be from another user.

The both problems are displayed in the following video. I made tapping hints at the network speed display.

10

Update

In the video posted via the link, the URL blink occured once when the upper edge of the screen was at the bottom of my own message post, so the conditions to reproduce this blink must exclude the term that the upper message must be from another user. But still, the URL blink is much more often reproduced at another user’s message posts than at the own’s. So the another user’s posts are influentive to the cause of this bug feature. Possibly such post should be on the screen in order for the URL blink to appear.

11

Update

The speed problem resolved through enabling the internet for the ‘android system’ system app. The page just loaded in some 4 seconds with the speed of some 400 kb/s. The disabling of the internet access for the system app was not from my side this time.

The URL blinks persisted though.

13

Hello @dimm
Thank you for the provided video file. We are checking the described URL blink issue. I will update this thread once we have something to share.

14

Correction:

I noticed that the forum engine was seriously rewritten

15

Update

I locked the way to reproduce the URL redirect blinks. The below video shows the method. The URL blink appears whenever the touch is released while the upper edge of the screen had changed to be located at another message post. The lower edge of the screen is not working this way and is not causing the URL blinks. In another words, to reproduce the blink, the touch should be released when the upper edge of the screen intersects a message post that wasn’t intersected by it just before. The both scenarios, the upper screen edge landing (which works the bugfeature) and the lower screen edge landing (which works not), are depicted in this video:

16

Hello @dimm
Thank you for the update, we are still investigating the situation. I will update this thread when we have something to share.