Hi there, and thanks for posting in the Katalon community!
Working with recording, we encourage you trying Katalon Web Recorder Plus: Katalon Web Recorder Plus | Katalon Docs. Double-checking the steps and configurations might resolve the issue.
If the doc doesn’t help, feel free to provide more details, and a community member will assist you soon. Thanks for being a part of our community!
seems this is a known issue in newer versions of Katalon Recorder (v7+) where the type command fails on file inputs, often throwing that specific match error.
Here are two fixes to try:
Use sendKeys instead of type:
The type command often conflicts with file input security restrictions. Switching to sendKeys usually bypasses this.
sendKeys | id=kml_file | ${path}
Fix the Path Format:
If you are on Windows, Katalon can be picky about backslashes. Change any backslashes (\) in your path variable to forward slashes (/).
Bad:C:\Users\Name\file.txt
Good:C:/Users/Name/file.txt
give sendKeys a shot first, it resolves most file upload glitches in the Chrome extension.
Check for Flakiness of locator where you attach file, You can always look manually where file get stored and write code in script to perfrom same action. You can share details and will surely help you out. Some modern language build component on the fly and give dynamic ids which causes issue.
I just noticed this error for the first time myself.
I noticed that Chrome initially asked for permission to access local devices etc at the point it went to execute the type command, for the file input.
This command has worked for years with this site, thousands of times, so I am certain the selector is fine, and the command should work. I can only guess that the current version of Chrome has introduced new security measures tripping up Katalon Recorder.
The error confuses Katalon Recorder, as highlighted in the screenshot in the top post, re:
[error] error - If you are using Firefox, please check if Katalon Recorder helper has started.
I am using Chrome Version 147.0.7727.56 on macOS (Sequoia), but haven’t tried older builds of Chrome for comparative purposes, but given the build of KAR hasn’t changed in ages, but the Chrome build has, this to me clearly points to it being a new compatibility issue.
FWIW I double checked that allow local file access is still enabled for the Chrome extension. Also, when keeping the same selector but swapping out type for click, it opened up a file selector successfully, which confirms it’s interacting with the correct element.
Update: This is the only logging surfaced in the console (via devtools) for KAR when executing the commands
I can’t help but wonder if it’s a cascading error in this case. In theory, the error should be unrelated to this failure, but changing the URI of a resource it expects to be able to communicate with might have a knock on effect, too. The timeline between this error appearing and that change also feels like more than just coincidence.
FWIW I have also explored the sendKeys way, but what it solidly confirmed is that there’s no way that will work, as Chrome’s security restrictions prevent an extension programmatically specifying the path for a file to be uploaded this way.
Thus it generated this error:
[error] Failed to set the ‘value’ property on ‘HTMLInputElement’: This input element accepts a filename, which may only be programmatically set to the empty string.
