eBay

biblicabeebli · ‎09-08-2019

occasionally, when swiping to delete a watched search, the swipe will be off by one or two rows. The delete action if taken will apply to the wrong item in the list, e.g. not the row under the thumb.

I am on a 6s+ running 12.4.1. this bug has existed for years, since at least the time that ios 10 was out. It also occurs on 6+ and 8+. I do not know if it occurs on other size iphones/ipads.

mobile_feedback · ‎09-10-2019

@biblicabeebli wrote:

occasionally, when swiping to delete a watched search, the swipe will be off by one or two rows. The delete action if taken will apply to the wrong item in the list, e.g. not the row under the thumb.

I am on a 6s+ running 12.4.1. this bug has existed for years, since at least the time that ios 10 was out. It also occurs on 6+ and 8+. I do not know if it occurs on other size iphones/ipads.

Thank you for the report. We will look into this

mobile_feedback · ‎09-18-2019

@biblicabeebli wrote:

occasionally, when swiping to delete a watched search, the swipe will be off by one or two rows. The delete action if taken will apply to the wrong item in the list, e.g. not the row under the thumb.

I am on a 6s+ running 12.4.1. this bug has existed for years, since at least the time that ios 10 was out. It also occurs on 6+ and 8+. I do not know if it occurs on other size iphones/ipads.

We are trying to reproduce this so we can get it fixed but are not having luck. Could you help with some detailed steps to create the issue.

Thanks

biblicabeebli · ‎09-18-2019

I cannot provide detailed instructions because this does not occur with any particular pattern that I have observed. (I am fairly certain this occurred on my old 4s, so I don't think my phone size is relevant.)

Yeah I know, not helpful, I'm a developer too.

I caught the screenshot as proof that it happens and submitted it. The bug has been around for the entire time I have used the ebay app, that means this is some ooooold code or a ui library issue. It certainly predates Swift, so that may give you a hint (if you have converted) that the bug is a detail of parameters are passed into ... something. Don't know ios dev, not familiar with the abstractions and libraries involved.

maybe start with non-user sources of scrolling? Like maybe it is the ui activity of the loading thingy that shows up when you pull to refresh? There are definitely visible glitches with that not operating smoothly. The thought is that the list of items shifts the view but if the user's thumb is on the screen it does some kind of incorrect scrolling pause and so the "current thumb location" as recorded by the app is interpreted as over a different row?

I think it is not an error in identifying what row a user is swiping on under normal ui conditions because _it can jump by multiple rows_, implying that it isn't some kind of minuscule math/floating point error, as that would likely invariably result in off by a single row bugs.

to seed a second/related line of inquiry: how are rows identified and programmatically accessed? what weirdness is going on that means that the row can be off by more than 1?

Obviously I don't know the code so that could be hilariously wrong.

Good luck!

biblicabeebli · ‎09-19-2019

It definitely does occur more/most frequently when deleting multiple items in quick succession. Logically, I think that supports the idea that something is going on with the scroll position being out of sync with the finger-touch-point-thing.

(that's a technical term, obvs.)

(btw, if you track this down would love to know what's going on.)

Q: should I take screenshots and attach them whenever this occurs? would be happy to do so if that is what it takes to keep the bug report alive in lieu of repeatable directions.

mobile_feedback · ‎09-20-2019

@biblicabeebli

I think we are good for now. I will let you know if we need more.

Thanks for your help

biblicabeebli · ‎09-22-2019

Update:

There is a second bug here that night be related.

Even less commonly than the slide action applying to the wrong item the UI appears to totally stop accepting taps on the list of item.

Usually initiating a slide acton a) works correctly, b) resolves the issue and normal functionality returns.

This event, though less common than the swiping issue, frequently coincides with one of these incorrectly applied swipes.

As this is a UI freeze I cannot take useful screenshot of it.

I will attempt to monitor and report more detail on this, for example I can't quite recall if this is a total UI freeze or if I'm just lazy and kill the app to fix it. Please let me know if I should create a new bug report for this issue.

biblicabeebli · ‎10-01-2019

Update!

I have found that I am able to replicate this glitch fairly reliably, and also I he found some other issues.

1) I have a lot of saved searches, maybe that is relevant.

2) if I create a bunch of saved searches and then delete then in rapid succession I can trigger a bunch of glitchy UI issues.

3) the most reliable way to replicate this is to make sure that your finger has vertical movement between swipes, e.g. you will fail to replicate this if the finger remains on the same row the whole time.

So, create a bunch of saved searches, and then delete them using slightly exaggerated swipes in rapid succession, ensuring there is some vertical shifting by a couple rows between swipes.

There is a secondary graphics glitch to report too, and it becomes apparent when deleting a lot of entries: the animation of the swipe-to-delete ui label disappearing is very obviously glitchy and jumps very noticeably. Best guess is that this was developed on the non-plus size phone and the difference in the size hides this visible glitch on the smaller phone.

mobile_feedback · ‎10-01-2019

@biblicabeebli wrote:

Update!

I have found that I am able to replicate this glitch fairly reliably, and also I he found some other issues.

1) I have a lot of saved searches, maybe that is relevant.

2) if I create a bunch of saved searches and then delete then in rapid succession I can trigger a bunch of glitchy UI issues.

3) the most reliable way to replicate this is to make sure that your finger has vertical movement between swipes, e.g. you will fail to replicate this if the finger remains on the same row the whole time.

So, create a bunch of saved searches, and then delete them using slightly exaggerated swipes in rapid succession, ensuring there is some vertical shifting by a couple rows between swipes.

There is a secondary graphics glitch to report too, and it becomes apparent when deleting a lot of entries: the animation of the swipe-to-delete ui label disappearing is very obviously glitchy and jumps very noticeably. Best guess is that this was developed on the non-plus size phone and the difference in the size hides this visible glitch on the smaller phone.

Thank you for the extra steps. This is helpful

handandtool · ‎10-02-2019

I have had a related bug for possibly a year or more. In my case I am not trying to delete a saved search.
Instead I am just clicking each saved search in order.
As I work my way down the list it stops working. Clicking a saved search is suddenly broken.
The work around is always the same.
Pretend to delete a saved search by sliding one to the left - do not click remove.
Always the wrong one slides - usually one or two above slides!
Let go and it snaps back into place.
Clicking a saved search now works again!

Best guess so far is I click more than once in some odd way that triggers the bug.