Mobile Post button fix

Closes #506 (closed)

added 1 commit

• 85b87faf - Make mobile new post button pernament

Compare with previous version

added 1 commit

• 17de84e4 - Make mobile new post button pernament

Compare with previous version

can this be made configurable?

Yup, sure

added 1 commit

• 6b02fd9d - Make floating post button configurable

Compare with previous version

added 1 commit

• 162dae49 - Make floating post button configurable

Compare with previous version

added 1 commit

• 6a4f285f - Make floating post button configurable

Compare with previous version

added 1 commit

• c8bb7be7 - Make floating post button configurable

Compare with previous version

Done (video: https://cl.ly/a247e8c8dfa6)

Do we want it enabled by default?

added 1 commit

• 81be6a21 - Make floating post button configurable

Compare with previous version

i think "Automatically hide New Post button (mobile)" should be a better description. "Scrolled to the bottom" sorta implies it's scrolled to THE bottom, not just scrolled downwards a bit, and explaining how it works takes more time and effort than understanding it in action. There also should be an emphasis that it's affecting the mobile mode only.

Also move it to "Composing" category.

Seeing that tusky doesn't hide it and there's some quirks related to safari, i'd say leave it off by default.

added 1 commit

• caa44471 - Make floating post button configurable

Compare with previous version

Got it, just updated it. Ready for final review

added 1 commit

• 3e26bb4c - Make floating post button configurable

Compare with previous version

added 1 commit

• 8c9c774d - Make floating post button configurable

Compare with previous version

why isn't the entire thing debounced?

In my understanding, the purpose of the throttled function was to keep track of the direction so that it could hide the button when scrolling down (positive scrollAmount) and show it when scrolling up (negative scrollAmount). I'm not sure if the latter is the desired behavior, but if so, I think scrollY needs to be constantly updated, hence throttle. Otherwise, debounce, which is called at the beginning / end of the scroll, doesn't have enough info to know the direction and whether it is the beginning or end of the movement. (this may illustrate this point a bit better: https://cl.ly/846f6e51d4a7).

Are you suggesting to distinguish between the leading and trailing debounce calls and then hide it on leading (the beginning of the movement) and show on trailing? I haven't considered that but I guess it should be possible. Will look into how this and how can this be simplified in general tomorrow morning

Update: the debounce-only approach works overall:

    handleScrollStart: debounce(function () {
      if (window.scrollY > this.oldScrollPos) {
        this.hidden = true
      } else {
        this.hidden = false
      }
      this.oldScrollPos = window.scrollY
    }, 100, {leading: true, trailing: false}),

    handleScrollEnd: debounce(function () {
      this.hidden = false
      this.oldScrollPos = window.scrollY
    }, 100, {leading: false, trailing: true})

However, there is a limitation compared to the previous approach with throttle:

if the user scrolls up a little and then immediately continues to scroll down, it will still consider this as a "scroll-up" event and won't hide the button.

So, with the debounce-only approach, we can either accept this as a limitation or make it hide the button even on scroll-up.

i'd leave it entirely debounced.

changed this line in version 13 of the diff

Done

Right now with autohide enabled it hides button only during scroll-down, when scroll stops button pops back up.

Not very important and could be done in a separate MR.

Other things need to be fixed tho.