yeah, i noticed that. apologies if i missed a post about it... what do you wish didn't suck about selenium?

Scrolling to an element doesn’t always work because somehow the element might not be ready. You need to add ids to the element and select by that to ensure it works properly.

▲

hugs 5 days ago | parent [-]

thanks! yeah, playwright was a huge improvement there -- waiting until an element was actually ready. the official posture from the selenium project ("figure it out, be explicit") wasn't always the most user friendly messaging.

having to add ids to elements is one of those classic tradeoffs -- the alternative was to use css or xpath selectors, which can be even worse, maintenance-wise. i'm secretly hoping ai code-gen apps pumped out by things like Lovable or Claude Code automagically generate element test-ids and the tests for you and we never have to worry about it again.

▲

moi2388 5 days ago | parent | next [-]

It’s literally the only issue I’ve ever encountered with selenium, and having ids would be good for more reasons than just testing, so for me it wasn’t even an actual issue.

▲

nikisweeting 5 days ago | parent | prev [-]

whats the downside of using frameId/targetId+backendNodeId as the stable element ids?

▲

hugs 5 days ago | parent [-]

i'm at the edge of my chrome internals knowledge here, but i'd answer the question with a question: isn't backendnodeid only stable within a single session?

that might not matter if the agent is re-finding the element between sessions anyway, but then you're paying a lookup cost (time + tokens) each time. compared to just using document.getelementbyid() on an explicit id.

	▲	nikisweeting 5 days ago \| parent [-]
		iirc it's stable across sessions until the tab closes, even though their docs dont guarantee it. we cant modify the dom to add IDs because we'd get detected by block-blockers very quickly. we're gradually trying to get rid of all DOM tampering entirely for that reason.