feat(elementhandle): add timeout and signal to inputValue#41548
Conversation
ElementHandle.inputValue advertised a `timeout` option since v1.13, but the protocol entry in handles.yml declared no parameters, so the value was silently dropped at the wire validator and never applied. This wires it through properly and adds `signal` alongside it. Note this is a behaviour change: inputValue now honours the default timeout where before it effectively had none. Refs: microsoft#40578
|
I think we should mark |
Test results for "MCP"5 failed 7456 passed, 1132 skipped Merge workflow run. |
Test results for "tests 1"6 flaky49215 passed, 1163 skipped Merge workflow run. |
|
discussed, let's deprecate |
2 participants
Adds
timeoutandsignaltoElementHandle.inputValue, following on from #41141.inputValuewill start timing out again.The history is worth spelling out, because I got it wrong at first.
inputValuehas advertised atimeoutoption since v1.13, and until v1.53 it was honoured: the server ran it through the usual path and applied the context's default action timeout (30s). Then #35988 ("move timeout handling to the client") pinned all the ElementHandle getters -inputValue,textContent,getAttribute,isCheckedand friends - to{ timeout: 0 }, and the clientinputValue()was never taught to send a timeout. So since v1.53 it's had no timeout at all, and the documented option has been a silent no-op.This PR wires
timeoutback through the protocol properly and addssignalnext to it. Because the client sends the default timeout again,inputValuewill once more time out (30s by default) where for the last several releases it would wait forever. That restores the pre-1.53 behaviour, but it's a real change for anyone who came to rely on it never timing out - hence the loud warning.The alternative would be to go the other way: accept that
inputValuedoesn't really need a timeout (it runs against an already-resolved element) and just deprecate thetimeoutoption instead of reviving it. That keeps today's behaviour and quietly retires a dead option. I've gone with reviving it here because it linesinputValueback up with how it worked pre-1.53 and lets us addsignalalongside, but I'm happy to flip to the deprecation route if you'd prefer it.Why just
inputValue? The same v1.53 regression hit every ElementHandle getter - they're all still pinned totimeout: 0- butinputValueis the only one that ever advertised atimeoutoption in the docs and types, so it's the only one where the public API and the runtime actually disagree. The other getters (textContent,getAttribute,isChecked, ...) never promised a timeout, so I've left them alone.Refs #40578