Image viewer jumps when zooming in and out

[Outlet2048]

• [X] I have searched open and closed issues for duplicates
• [X] I am submitting a bug report for existing functionality that does not work as intended
• [X] I have read https://github.com/signalapp/Signal-Android/wiki/Submitting-useful-bug-reports
• [X] This isn't a feature request or a discussion topic

---

Bug description

Zooming in and out in the image viewer causes it to jump around like crazy

Steps to reproduce

• send a Screenshot to a friend or note to self
• zoom in and out in granular steps
• see video

Actual result: Viewer jumps as if it was a sport Expected result: Viewer should remain calm as a couch potato

Device info

Device: OnePlus9Pro Android version: 13 Signal version: 6.3.2

Link to debug log

https://debuglogs.org/android/6.3.2/4e65b77ca388a27282472c538d33156050b90f4a3ff718c6ac961e50ce5a0c47

Screen recording of issue available 336 hours from now Don't watch if you're allergic to flashing images or something 🤔

https://transfer.sh/vWNS4V/Record_2022-11-24-16-27-19.mp4

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Outlet2048]

Can still reproduce with ease

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Outlet2048]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

Hi Stale Bot,

I just wanted to take a moment to thank you for your contribution to society by helping to keep GitHub issues organized and up-to-date. Your efforts are greatly appreciated!

Regarding my issue issue, I wanted to let you know that the issue is still reproducible on my end. I've tried several different scenarios and can confirm that the problem still persists. I'm happy to provide any additional information or help with debugging if needed.

Thank you again for all that you do!

Best regards, [Your Name]

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Outlet2048]

[Outlet2048]

Also:

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Outlet2048]

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Outlet2048]

[a1batross]

It would be nice if someone from Signal devs at least responded in this year-old issue, rather than employing a useless stalebot.

@greyson-signal @alex-signal @cody-signal @alan-signal @nicholas-signal @clark-signal @rashad-signal @jim-signal

[iacore]

employing

what has caused this misconception in you

(edit: i'm bad at language. "employ" would imply it has some use)

[foxt]

employing

what has caused this misconception in you

From the Cambridge English Dictionary:

employ verb to use something:

Sophisticated statistical analysis was employed to obtain these results.

[Outlet2048]

As far as I know the devs are aware of the issue and also mentioned that the whole image viewer would need to be refactured in the future

So it's likely to be on their radar although as usual nobody knows in how many years it'll be done

[0x4d6165]

Stale bots are a scourge on open source development and any project that uses them is essentially giving the finger to their entire community. Disgusting behavior, signal.

[filipesmedeiros]

@0x4d6165 pretty strong opinion. I think they can be useful, but maybe should only be activated after a collaborator has interacted with the issue, and have a longer interval?

[0x4d6165]

In this case it's allowing signal to ignore an important issue by constantly burying the issue in closed. Maybe there are some good implementations of stalebots, but this certainly is an example of their problems.

[eli-schwartz]

@0x4d6165 pretty strong opinion. I think they can be useful, but maybe should only be activated after a collaborator has interacted with the issue, and have a longer interval?

No. The inherent nature of a stalebot is to say that after a long enough time has passed issues no longer count, because if it's old enough then perhaps no one cares to fix it. It doesn't and cannot have anything to do with whether the issue still exists.

An issue that is closed for reasons other than a human being manually doing it after evaluating the ticket is most likely still an issue and will always be an issue -- because, well, no one ever tried to fix it, and bugs don't usually fix themselves.

Pull requests could be validly closed after a while, in particular with the rationale that it no longer applies and hasn't been rebased in a long time and therefore the proposed changes aren't useful code anymore. Ideally such a PR should be linked to a bug report that does NOT get closed.

[Visne]

and bugs don't usually fix themselves.

As an open source maintainer I've come accross a ton of issues that stayed open despite the issue being fixed, either because of code being rewritten, someone forgetting to close the issue after fixing it, or because the cause of the issue was not directly related to code in our codebase, but in a library we were using. I think it's completely fair to offload a small amount of the work onto the person who opened the issue (and therefore probably already has the setup required to check if the bug is still reproducible), but I also agree that 2 months for the stale bot to kick in is too short.

Regardless, this is all completely off-topic.

[eli-schwartz]

Regardless, this is all completely off-topic.

Hmm, I wonder what the topic actually is? Given that the repository owners appear to believe the main purpose of this ticket is to regularly have users converse with stale-bot using increasingly memetic humor images.

As an open source maintainer I've come accross a ton of issues that stayed open despite the issue being fixed, either because of code being rewritten, someone forgetting to close the issue after fixing it, or because the cause of the issue was not directly related to code in our codebase, but in a library we were using.

As an open source maintainer my experience is that there's a reason I used the word "usually" rather than the word "always". Because all these things you mention do exist! They're just vanishingly the minority.

But if the cause of the issue is not your codebase, rather a library, then that should be analyzed from the start and handled by marking the bug as an upstream bug and then either using it as a tracking bug or closing it immediately. Stale bots aren't needed in either case to clear out the list.

While duplicates happen, or people fixing an issue and linking it but not using closing keywords, those are usually pretty easy to verify ;) and clear out. Not really a good reason to use technology whose essential purpose is to throw the baby out with the bathwater.

Code being rewritten is a fantastic what-if. "What if it turns out I rewrote my entire codebase from scratch so issues may not be issues anymore". Actual users of stalebots aren't actually doing that. If you do do it then how about you close issues then. No stalebot needed.

...

I find it amazing that across the internet whenever people use a stale bot, issue reporters get really annoyed. And then someone shows up and defends the use of stale bots by describing theoretical situations where it "might be valid" if using settings no one uses and by projects that actually engage with issue reporters in any way shape or form.

Why not just accept that dismissive and demeaning technology used as a wholesale replacement for human interaction should simply not be used? :)

Automation technology isn't inherently bad. It's a fantastic and constructive way to flag issues for manual review. Maybe people should stop using bots that autoclose stale issus, and start using bots that ping the bug triaging team and ask them to triage the bugs that appear to have been forgotten.

You could even double this up with a request for the reporter to "be an awesome contributor and close the bug yourself if you know that it has been fixed in the meantime". Which would be the actual way that you offload a small amount of the work onto the person who opened the issue, while simultaneously avoiding creating bad will amongst those people.

[Visne]

theoretical situations

I said I came across them myself...

[danielittlewood0]

Regardless, this is all completely off-topic.

Hmm, I wonder what the topic actually is?

Hi Eli. I believe the topic is "Image viewer jumps when zooming in and out". Hope that helps!

[x64x2]

[clark-signal]

Was trying to reproduce myself on a Pixel 4a but wasn't able to do so. Anyone have reliable repro steps or a video demo?

I saw there was an attempted fix related to pointers and drag, but delaying and varying the offlift of my fingers didn't really change anything.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Outlet2048]

Sorry Y'all, out of memes for this one Next time I'll be back with new content