feat: add buy 100 helper for city shops#447
Conversation
|
Hi @Manuito83, one thing I noticed while re-reviewing this PR. The helper is intended to fill a quantity of up to 100 and not submit the purchase, which is exactly the right direction. The only risky part I see is the fallback path in fillBuy100: if no quantity input is found, it calls the original buy button with buyButton.click() and then tries to find the input after a short delay. That is probably fine on shop pages where the first click only opens a quantity dialog, but if any targeted page/shop variant submits directly, tapping the new 100 button could accidentally buy instead of only filling the amount. Would you prefer we remove that fallback and only fill when an input is already discoverable, or do you know these three pages always open a quantity step first? I think this is worth deciding before merge because it touches purchase behavior. |
a978d68 to
8b93d0d
Compare
|
Small update after comparing this with the existing foreign-stock buy max helper. I kept the city-shop specific selectors because the Torn city shop DOM is different from the abroad stock DOM, so the foreign-stock helper cannot be reused as-is. But I aligned the behavior with the safer parts of that existing app helper:
So this is still a city-shop implementation, but it now follows the same safer pattern as the existing abroad helper instead of trying to trigger the real buy flow. |
|
Thanks! |
This is a focused attempt at #132.
What changed:
Why:
For common shop runs, setting the quantity manually is repetitive. This keeps the helper small and similar in spirit to the existing Torn PDA browser helpers that fill values on Torn pages.
Notes:
Torn shop pages are React/DOM driven and class names can change, so I kept the selectors defensive and limited the injection to shop URLs only.
Local verification:
I could not run Flutter analyzer/build locally because flutter is not available on this PATH, so GitHub CI will be the compile check.