I am testing an Angular application with custom form components.
I have a visible text input that a human user can type into, but Robot Framework Browser fails with Fill Text / Type Text and reports that the element is not enabled.
The locator points to a native input inside a custom Angular component.
What works at the moment is:
Fill Text <locator> <value> force=True
then Press Keys <locator> Tab
Without the Tab, Angular does not seem to process the value fully and dependent fields stay disabled.
My questions:
Why can a visible input still be treated as not enabled by Browser/Playwright?
For Angular custom form controls, is there a recommended interaction pattern?
Is force=True + Tab an acceptable workaround, or is there a better practice?
Not sure if it’s you’re specific issue, but with Angular style apps I’ve seen in the past where the native input is inside a div or even several div’s and one of the parent elements is hidden until the user clicks on the parent locator (or tabs into it), so maybe this is what your encountering?
I usually get the script to click first then use fill text, then click somewhere outside the input (the label is a good place to click after) and then wrap that combination into a keyword called something like fill angular text that takes the argument of a locator that’s common or the label text
If this is what you’ve encountered:
Why can a visible input still be treated as not enabled by Browser/Playwright?
because if the input is in a hidden element it’s not actually enabled
For Angular custom form controls, is there a recommended interaction pattern?
I’m sure you’ll get several opinions / approaches (I gave mine) use which ever one works best for you.
Is force=True + Tab an acceptable workaround, or is there a better practice?
In test automation sometimes you have to do weird stuff to get the test to work reliably, we “shouldn’t need to” but devs also shouldn’t put native html elements in hidden div’s for a field that’s visible to the user, but they do, the best thing you can to is wrap the pattern in a nice keyword so the parent test case remains easy to read and understand
I had a similar issue with a Vite interface, if I remember correctly.
The problem was that a text box was disabled until it was fully visible on the screen. So, I had to add a “Scroll By” action to make the text box completely visible and enabled. Only then could I fill in the text.
Hi, from your description I believe it is what @damies13 mentioned. We often won’t notice obvious actions we are making in manual, and omit them in script later. Lot of input fields though seem visible, need to be enabled by click or double click on parents or higher(like Click .input >> ../..) before Fill Text or Press Keys and then after removed focus from the field.