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.

17

Hello @dimm

We have recently updated the engine of the community, please check out the issue once again.

19

_ _ _ _.

I did the rechecks. The results are those:

  1. URL blink problem is mostly resolved. I managed to obtain the blinks in rare irregular fashion by randomly scrolling up & down. I suspect that it’s because some files were additionally downloaded on-demand to the browser, because once the whole page was extensively cached the blinks I was unable to produce anymore, even after the page refresh. The total number of the blinks was some 5 on this particular page. I consider this behaviour of the forum site acceptable but not perfect.

  2. There’s a minor problem with the mentioned gauge: when transitioning from item 9 to item 10, the gauge expands and is filled mostly leftward and only tiny bit rightward. This is due to the initial gauge currently isn’t respecting the case of the total number of the posts on the page exceeding 10, so when additional space is needed to accomodate the just-appeared extra digit (the 1), the gauge expands to the left.

  3. There’s a major problem with the downward arrow appearing just above the gauge, the arrow supposedly brings the scroll to the bottom of the thread. The arrow disappears after repeated scrolling of the page.

20

Would it be possible to record a behavior with gauge on video for reference?

21

_ _ _ _.

Yep, I will.

22

_ _ _ _.

Here’s the video. Two problems are shown there: the unexpected gauge change in the wrong place, and the mentioned leftward gauge expand. The URL blink I have seen in the previous attempt to record the video but in this one it wasn’t spotted.

The downward arrow seems to be pointing at the new / just added item, and is disappearing after the item pops into the view, so the arrow disappearance seems to be a correct behaviour in this case.

1 Like
23

Thank you for the video. Do I understand correctly that “gauge” represent reading progress bar? If so, this bar calculates the indication depending on the point below the site header and total length of each post. Also, it dynamically expands when amount of read posts becomes double digit (from 9 to 10, for instance).
So, scrolling down may indeed cause some visual misunderstanding, I reckon.

As for the arrow: it works similarly, depending on the starting point, it disappears once the last post is reached, but with that calculation peculiarity it may not be very intuitive, indeed.

Unfortunately, this is how engine calculates the viewport. I’m afraid there is nothing we can do in that regard. Only hide the progress bar, but the arrow would still remain.

24

_ _ _ _.

Yes, this your assumption is correct. This is a ‘gauge’ because it is ‘filled’ as the scroll position moves down to the bottom of the thread.

The main unexpected kink here was a sudden left jump when the second digit is introduced to indicate the 10th position. It is corrected easily through pre-calculation of the total number of the posts and arranging the corresponding width of the progress bar at the very start of the scrolling instead of changing the width dynamically. Really, the sudden jump wouldn’t be the problem if there’s only a digit position indicator, without the color fill. But the presence of the color-filled progress bar makes the sudden left expansion a display interpretation error.

Also, the little decrease of the progress bar while the position is out of scope is indicating the mismatch in the calculation of the posts’ heights somewhere in the code of the page. All of that are not a big trouble but are visually disturbing somewhat.

Usually the ‘Arrow Down’ icon depicts a fast-scrolling to the bottom, so the smantic shift to the ‘New Entry There’ was something I didn’t expect from it.

No-no, hiding the progress bar is a way too harsh decision. The progress bar is visually appealing but currently acts kinky in few circumstances. It’s better to keep it displayed as it is than to hide it. The arrow is misleading though, I would redraw the icon to something more appropriate for a unread reply.