"Populate text Field on web page" action failed by error message "'appmask' isn't an appmask"

[Anonymous]

If I run a desktop flow from PAD Console window, an error occurred at "Populate text Field on web page" action.

But if I debug run (F5) the same flow from PAD Flow Designer window, it runs successfully without any problems.

I have found that there is "Actions.log" file under below folder path, and it says "PopulateTextFieldBase" action failed by error message "'appmask' isn't an appmask"
C:\Users\{UserName}\AppData\Local\Microsoft\Power Automate Desktop\Console\Scripts\{GUID}\Runs\{GUID}

I have one input variable which has "Sensitive Text" type.

And if I changed the type of this input variable to plain "Text", above error is disappeared and flow completed successfully.

Also, I found that above error occurs in newer PAD version 2.12.171.21216, but not in older PAD version 2.10.36.21161.

Tried with two different PCs with PAD version 2.12.171.21216, and they have same issue.

IMPORT 'C:\\Users\\{UserName}\\AppData\\Local\\Microsoft\\Power Automate Desktop\\Console\\Workspace\\{GUID}\\A85791E3\\controlRepo.appmask' AS appmask
IMPORT 'C:\\Users\\{UserName}\\AppData\\Local\\Microsoft\\Power Automate Desktop\\Console\\Workspace\\{GUID}\\A85791E3\\imageRepo.imgrepo' AS imgrepo
@INPUT KEYWORD : { 'Description': 'Input search keyword.', 'FriendlyName': 'KEYWORD', 'DefaultValue': P'', 'Type': 'Sensitive' } 
WebAutomation.LaunchEdge Url: $'''https://www.bing.com/''' WindowState: WebAutomation.BrowserWindowState.Normal ClearCache: False ClearCookies: True Timeout: 60 BrowserInstance=> Browser
WebAutomation.FormFilling.PopulateTextField BrowserInstance: Browser Control: appmask['Web Page \'https://www.bing.com/\'']['<input:search> \'sb_form_q\''] Text: KEYWORD EmulateTyping: True UnfocusAfterPopulate: False Mode: WebAutomation.PopulateTextMode.Replace

Is there any known issues or bugs related to above error in PAD version 2.12.171.21216?

Thank you.

[HEATFreight]

I'm getting the following error from "Populate text field on web page":

'appmask' isn't an appmask 

This only occurs when I run the flow from outside the editor, like from the PAD console or from a cloud trigger. If I run from the editor, everything works fine 🤷‍

By the way, we have the same PAD version as @Anonymous 

PAD version 2.12.171.21216

This is not the first time we have seen actions that worked in the editor but failed when running flow from console or cloud. Previously we were able to find robust workarounds, but we had a long screenshare with a Microsoft tech support rep, and even they were not able to find a good workaround in this case.

Well he did make a workaround that tries to click into the login credential fields which are giving us trouble, but he used a "Move mouse to image" action, which is not as robust as a "Populate text field on web page" action. However, even the "Move mouse to image" action fails, but only when running outside of the PAD editor! Works fine in editor. Fails from console or cloud! This action gives the following error:

'imgrepo' isn't an appmask 

Also, we use the latest version of Microsoft Edge browser. The Microsoft rep said to try the flow in Chrome as well, and we will even try it in IE or the automation browser too if Chrome doesn't work.

It could be that this website is goofy, but then why does the flow run perfectly in the editor? Why would it only fail when running from console or cloud? Certain goofy websites are causing a corner case where flow actions only work in the editor. This could possibly be fixed by the developers of the affected goofy websites, but it seems obvious to me that PAD devs could also fix this corner case.

It's worth noting that we are quite experienced at editing element selectors to be simpler and more robust. We have tried both Web-type automations as well as UI-type (window) automations, and we are able to make either type work, but only when running from the editor. For this particular website, neither Web or UI automations work from console!

Please investigate this issue, Microsoft! It's probably less of a corner case than it seems. I would bet that this same issue is causing all kinds of problems, which people are simply finding workarounds for. It's rare for all workarounds to fail in the same way, but this is definitely not the first time we have come across actions which only work in the editor but never in the console. It's just the first time that every workaround we have tried was also subject to the same failure mode.

Thanks for reading!

[PetrosF-MSFT · Accepted solution]

Hi @Anonymous and @HEATFreight thank you for bringing this issue to our attention. It has been acknowledged and will be resolved in the September update.

In the meantime, please note that the Desktop flow runs successfully when it is executed from the PAD Designer or triggered through a Cloud flow.

[HEATFreight]

@PetrosF-MSFT Wait are you telling me that if we trigger the affected Desktop flows from the cloud they will work?

It has been my experience that when something works when running in the PAD Designer but not in the PAD Console, it will also have the same error when running from the Cloud as it does from the Console.

Technically I have not tried running this particular flow from the Cloud due to what I learned from my past negative experiences. After so many frustrating experiences, I have always tried to find a workaround that runs successfully from the Console before I deploy in a Cloud flow. Guess I'll get this built into a Cloud flow proof of concept to test that functionality. Would be really amazing if it just works!

Also, we have a seemingly separate issue in the affected flow. Don't think it's related but...

Oddly enough with this particular website that we're trying to automate, there is another issue with "Populate text field on web page" which is that the fields appear to be filled, but upon clicking LOGIN button, the fields get wiped and login fails. If for instance I but a debug point right after filling the password field, then I can click out of the filled password field and it will wipe itself. If I click the button to reveal the password, the password disappears. If we have the automation click the reveal password button before inputting the password, then pause the flow, yet again clicking out of the password field wipes it, or clicking the hide password button will also clear it out. Something similar is happening with the username/email field, although it does not wipe itself. The website is rejecting the input for both login credential fields, but only when using the Web Page action. When using the Window (UI) action, it works fine every time! (unless we run from console...). To be clear, the Web Page action does appear to fill the fields with the input (text boxes turn yellow and the text appears within), it's just that the input gets wiped upon submit. 

Here is the workaround we devised for this issue: after filling each field with the "Populate text field on web page" action, we click into the text field and backspace the last character, then send that key again. Somehow this causes the website to accept the input. LOGIN button works fine after this little workaround. But if we are going to this extreme, why even use the "Populate text field on web page" action in the first place? Why not use only Mouse and Keyboard actions if these are required to make this field work? Well because either workaround compromises robust functionality. We hate using Mouse and Keyboard actions because they are not as robust as sending inputs directly to a particular element within a web page or window. It's unclear to us why —only on this one particular website— the "Populate text field on web page" action is not accepted. This error happens no matter where we run the flow (Designer or Console, actually haven't tried Cloud yet).

I should probably make a new thread about this as I don't think it's at all related to the other issue...

[Anonymous]

I'm having a similar issue  and I'm using the latest version of PAD.  The error below is only being caused while running from the console or cloud not the designer. 

'appmask' isn't an appmask

Argument 'BrowserInstance' must be 'Web browser instance'. 

[Anonymous]

Hello @HEATFreight @PetrosF-MSFT @Anonymous 

I confirmed this issue is fixed in PAD Version 2.13.138.21255.

I appreciate Microsoft's effort to resolve our problem.

[GhitaFjorback1]

@PetrosF-MSFT  Hi, I am glad the above is fixed, but I am now having the same issue, only the other way around. 

When I populate text in webpage, no sensitive text, it will run smoothly as long as my Desktop flow is either in debug run mode, or run directly from the designer. If I trigger the Desktop flow via Power Automate Flow, the populate text action will simply not work (attended run)! This is getting frustrating. Does anyone have a solution for this issue? I am running the latest version of Desktop Flow 2.13.138.21255

Thanks

[HEATFreight]

@GhitaFjorback1 have you tried "Populate text field in window"?

My understanding is that web-type actions —when they work— are always preferable to UI-type (window) actions, but web-type doesn't always work. Obviously editing the element selectors can help, but it sounds like that's not your problem here because when the element selector is at fault, well I don't think the action works at all in that case. And you say it works fine in designer, so must not be element selector causing the issue.

In my flows, I use web actions and UI actions interchangeably depending on what seems to be working and what seems to be hanging up. I have had trouble with fields on certain websites when using "Populate text field on web page", where basically the field turns yellow and appears to populate correctly, but the input is not accepted. When logging into one particular website for example, the username and password fields visually appear to populate just fine, but the inputs are cleared out upon clicking "LOGIN" (actually I send ENTER key instead of "Press button on web page" / "Click UI element in window" / "Press button in window" because the "LOGIN" button on this particular website was also giving me trouble with all three of those click actions).

If I click the "unhide password" button, my password input disappears. If I have automation click that button before password input, I can see the password populates correctly, but if I then have the flow pause and I click anywhere at all, the password is cleared out. The same thing is happening with the username field except that it never disappears, but the input is not accepted regardless.

Two workarounds I have found in these situations are:

a) After "Populate text field on web page" I "Send a mouse click" to the coordinates of the field and then "Send keys" and type one extra character, then backspace that character. This causes the input to be recognized, but it's a sloppy workaround because you never want to use on-screen coordinates if you can avoid it. I call these "naked mouse clicks" because they are not tied to the web/UI element that they are meant to interact with, hence they are riskier. And if you are using naked clicks, you might as well skip the "Populate text field on web page" and just use all "Mouse and keyboard" actions to click and send keys.

b) Just use "Populate text field in window" instead. Like I said, you would rather use "Populate text field on web page" if you can get it to work, but to the extent that the web element in question has a UI-type counterpart, you should be able to get "Populate text field in window" to work even when the web-type action would otherwise fail, although it may take some experimentation with the element selectors to get it functioning reliably. Also, I only ever have one Edge window open and one tab in that window. I have found the UI-type element selectors to be unreliable when multiple Edge windows are open or when one Edge window has multiple tabs. These situations subtly change the window elements such that element selectors fail, and I have not figured out how to deal with that. So always use a single tab in a single window if you can. To be sure that the automation never opens an Edge window with an existing tab besides my intended one, before I "Launch new Edge" I use "Run PowerShell script" with

taskkill /im msedge.exe /F;

I'm not sure if the PowerShell script is still necessary, because different versions of Edge may or may not have the unwanted tab issue, which is also affected by the "When Edge starts" setting. I use "Open new tab page" for that setting. Another thing I've noticed is that, in terms of the unwanted tab problem, Edge may behave differently upon first launch after reboot as compared to subsequent launches. The PowerShell script puts Edge into the same state at every launch, so behavior is more predictable. And when my flow is done I run that same PowerShell script again to hopefully prep for the next flow run. I'm not sure that force-quitting Edge is the best solution for this, but it has ensured that my flows reliably open only the one desired tab in Edge, which ensures that UI-type actions are able to find the correct window and its elements.

Anyway, so if your "Populate text field on web page" actions are seemingly working up until the moment that you "submit" your inputs to the web page, at which point the inputs disappear or are otherwise not accepted, then you probably have the same problem I was having, and you would probably benefit from using UI-type "Populate text field in window".

Or if your "Populate text field on web page" actions are not turning the text fields yellow at all and you are not seeing any inputs populate those fields, then you are having a different issue, but you may still benefit from experimenting with UI-type "Populate text field in window".

Apologies for long-winded response, but hopefully it helps someone!

[GhitaFjorback1]

@HEATFreight  Thank you so much for your fast and thorough reply!
It actually helped by changing to Populate "UI" instead of "Web" action! Thank you.

I still need to tell Microsoft though that although we can find a workaround, it is really not good that designer and flow trigger is not behaving alike! We test and test, and when we go live, we expect the desktop flow to behave the same no matter how it is triggered. 😞

Thanks again! Highly appreciated!