Stabilize native touch targets in reader browser checks

[abhi1693]

What changes and why?

Reader parity intermittently failed after returning to Latest because the feed replaced the link while the touch helper was scrolling it into view. The failing job reported a detached element in unchanged test support; one repeat passed on the same commit.

The helper now uses Playwright's trial action to wait for a stable, actionable locator before dispatching the existing native CDP touch events. The trial does not send a desktop click. Browser-only support moves into the existing browser-test directory, with both consumers updated. Production behavior and Sonar/CI thresholds are unchanged.

A real browser regression replaces an off-screen target as it scrolls into view, then checks that the replacement receives exactly one native touch and one click. It fails with the previous helper and passes in both Chromium and Microsoft Edge with this fix.

This is a separate CI prerequisite for the remaining ready PR queue after #75; merge it before #76. Auto-merge is disabled.

Validation

• New browser regression: passed in Chromium and Microsoft Edge; previous helper fails the same fixture.
• Formatting, whitespace checks and affected-project commit hooks passed.
• Full production website build and reader journeys passed, followed by all four browser suites in each built Chrome and Edge extension. Hosted CI passed on e6f0298f90f702a2c3ab06817cf8d9c2a671e054, including reader parity on the first attempt, all 2,620 backend unit / 1,132 integration / 801 web / 648 admin tests, security checks and ARM64 images. CI required, all CodeQL analyses and the Sonar quality gate passed; no unresolved review conversations remain. The API performance comparison passed, without a production speed claim.
• No visible UI change; screenshots are not applicable. No new documentation is needed for a test-support fix.

Ready for review

• The description explains the change and validation results, including gaps.
• Regression tests are updated.

[gitar-bot]

Code Review ✅ Approved

🟡 Medium risk · Browser-test touch handling and regression coverage change across reader checks.

Stabilizes native touch targets in reader browser checks by waiting for actionable locators before dispatching CDP touch events, eliminating race conditions when the feed replaces links during scrolling. Test support moves to the browser-test directory with both consumers updated; no issues found.

Review coverage

📋 Rules No rules evaluated

🧪 Functional validation Not enabled · Set up

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Counting what did not apply, without listing it.

Comment with these commands to change the behavior for this request:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}

[github-actions]

PR reader API performance

Result: INCONCLUSIVE

7 inconclusive · 1 within threshold. Zero request failures across all six runs.

Base a85828de8415858e49c015243685cb2bab59b8ad → PR e6f0298f90f702a2c3ab06817cf8d9c2a671e054

Three independent runs per revision, each on a fresh GitHub-hosted ARM64 runner. 16 users, 60 seconds/run, 1,000 synthetic articles, cache off, five PgBouncer slots.

Latency comparison

All latency values are in milliseconds; lower is better. Values are medians of three runs.

Route	Base p95	PR p95	Change	Result
All requests	94	97	+3 (+3.2%)	Within threshold
Latest feed	130	120	-10 (-7.7%)	Within threshold
Feed pagination	97	87	-10 (-10.3%)	Inconclusive
Article detail	59	64	+5 (+8.5%)	Inconclusive
Source feed	110	88	-22 (-20.0%)	Inconclusive
Topic feed	75	94	+19 (+25.3%)	Inconclusive
Feed filters	81	90	+9 (+11.1%)	Inconclusive
Sources	37	39	+2 (+5.4%)	Inconclusive
Topics	41	47	+6 (+14.6%)	Inconclusive

Additional latency and throughput metrics

Each cell shows base → PR. Latencies are in milliseconds.

Endpoint	p50	p99	Requests/s
Aggregated	28 → 31	140 → 140	30.28 → 30.56
/v1/feed [latest]	46 → 43	180 → 160	8.69 → 9.15
/v1/feed [page]	25 → 26	110 → 130	3.80 → 3.72
/v1/articles/[id]	18 → 18	110 → 120	6.15 → 6.05
/v1/feed [source]	28 → 28	140 → 110	1.64 → 1.95
/v1/feed [topic]	27 → 30	130 → 120	1.90 → 1.74
/v1/feed/options	21 → 21	100 → 130	2.61 → 2.57
/v1/sources	11 → 11	89 → 73	2.61 → 2.57
/v1/topics	12 → 12	83 → 95	2.61 → 2.57

Individual runs

Run	Requests	Failures	Exit code
Base 1	1683	0	0
Base 2	1709	0	0
Base 3	1707	0	0
PR 1	1728	0	0
PR 2	1721	0	0
PR 3	1655	0	0

How to interpret this report

Regressed / Improved: a p95 regression needs >20% and >20 ms increase in the medians and at least two head samples versus the base median. Improvements use the inverse threshold. Within threshold means the change did not meet both thresholds.

Inconclusive: a within-revision p95 range >35% of its median and >20 ms is too noisy for a confident latency verdict.

Inconclusive latency comparisons are non-blocking: the check passes without claiming an improvement. Confirmed regressions and test/report errors fail the PR gate. Throughput is descriptive: paced users do not measure maximum capacity. This uncached public API test does not establish production health, browser performance or worker capacity. Separate runners can differ in hardware or host load; repetitions and noise checks reduce but cannot eliminate that uncertainty.

Full HTML/CSV reports and logs · attempt 1

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues
0 New dependency risks

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud