9
Post comments swipe back opens sidebar (lemmy.world)
submitted 1 year ago by to c/summit@lemmy.world
14 comments fedilink hide all child comments
 

When on a post comments I used to be able to swipe to the right to go back to the community but now it bugs out and opens the sidebar so I have to use the Android back to return to the community

you are viewing a single comment's thread
view the rest of the comments
[–] 1 point 1 year ago (10 children)

Is this realistically an issue? I can reproduce it but it seems like an issue that users will generally not run into.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 10 child comments
    •
  • [–] 2 points 1 year ago (9 children)

    Maybe. I haven't had it happen yet personally, but I think it's a matter of time.
    As I get more used to the interface I perform the actions I am used to more quickly and eventually blindly.

    I think I only haven't run into it because I don't usually scroll a set distance down to the comments.
    I expect that as soon as I find a series of say a few tens of posts with similar layout I only want the comments from, I'd run right into it, ruining my scroll position in the feeds list instead.

    I have definitely had the sidebar bug happen often enough I recognized it in ops report without op themselved knowing why it happened.

    Something I don't think would happen to me but could happen to others, is that if you tap a different post while one is already opening, or tap a sub, the app breaks badly.

    I think the proper thing would be to at minimum stop all interactions with the posts pane once a post is opening. Canceling ongoing swipes and making it fully non-interactive would ofc be better.

    Btw., does the post open animation respect the system animation speed? That'd also help in my case, making it 3-5x faster.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 9 child comments
    •
  • [–] 2 points 1 year ago (6 children)

    Yeah I will probably need to disable the main screen on transition. Annoying because there isn't a built in way to do this. You sort of just have to do it manually T_T

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] 1 point 1 year ago (5 children)

    going by webdev, can you add a transparent layer in between that catches all inputs?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] 1 point 1 year ago (3 children)

    Ok after using the app with this change for a day ai have to say that I HATE IT. It makes thing so much slower. I have to wait for the stupid close animation to finish before i drag. I'm removing this change immediately lmao.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 2 points 1 year ago (2 children)

    Did you put it on top of everything? I meant between the opening post and the posts list. Such that if it had 50% opacity the post would look identical and the post list would be dimmed, and you wouldn't even have to remove it when the post is done opening (tho ofc you should for when it is swiped away).

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 1 year ago (1 child)

    no its only on top of the post list. However the way i browse is I tap a post, quickly read it then swipe and then while the post is closing I am already trying to scroll the post list. This wont work since interactions with the post list is blocked until the post sheet is closed fully.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 2 points 1 year ago

    Oh yeah that makes sense. And if you fix all the issues when closing the post, opening it wouldn't be very different and should also mostly be fixed.

    Then I'll report back if I ever see other issues related to it or have the accidental postlist scroll happen organically.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 1 point 1 year ago*

    It's technically frowned upon for accessibility reasons (eg. accessibility users can technically select elements under the transparent layer). But yes I'm too lazy to do things properly so I will go this route. Also this is such an edge case.

    Adding this transparent layer doesn't even fix the issue if you double tap really fast because events are handled asynchronously, converted to a serial queue and then set to the UI.

    This means that a double tap can go off even if you show a transparent layer because by the time the UI is notified of the first tap, both taps are already in the touch event queue. So even if you show the transparent layer now, the 2nd tap will go off for sure. it will not block the 2nd tap. The 100% correct way is to have a flag to handle this. However this is extremely tricky because you need to check this flag everywhere and also disable each and every possible interaction with every single view manually.

    As a middle ground, I fixed the issue where tapping two posts will show a black screen so at least in the next version, users who tap too fast will not end up in a weird state.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 1 point 1 year ago (1 child)

    does the post open animation respect the system animation speed

    It's a 1st party Android component so I would hope so.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •