Browser mode Click backwards compatibility for MV3 vs MV2 extension

[EmmanuelTsitsir]

When running a Click stage in Edge Browser mode  using an element with JavaScript in the "href" attribute, MV3 extension throws error but MV2 extension executes the stage correctly.
A workaround flow for MV3 is:

1.  Read the "href" value of the element and if it includes Javascript:

2. Use "Set Attribute" to set the "href" value in the "onclick" attribute

3. Use "Set Attribute" to set empty value in the "href" attribute

4. Run Click Element via browser mode
Since this code will be required for every browser click to be able to handle this scenario (JavaScript in "href"), I would suggest to incorporate this flow in BluePrism code in order to ensure the backwards compatibility of Click for the MV3 extension.

[sumire]

On this issue, if anyone has tried Blue Prism Browser Automation Agent for Manifest V3 Extensions | Blue Prism Portal , let me know if it works.

[robert.nicklin]

Hi @EmmanuelTsitsir,

Thanks for taking the time to raise an idea.

Your suggestion was actually discussed internally a few years back when we came across the MV2 to MV3 "Click" issue with embedded hrefs, although this happened completely coincidentally rather than as a result of this idea! At the time, we decided to not introduce this as a bespoke set of actions that would take place automatically under a single navigate action function as this was significantly different than how our other actions work today, and there was a lot that could go wrong on each of the individual steps that could make troubleshooting issues difficult.

Instead, we opted to introduce the system setting that flags a specific exception when we detect a "click" interaction that is going to attempt to trigger a href element and flag that to the user pre-emptively (or not) based on how the system was configured. This was system setting was introduced in Blue Prism 7.2 under reference BP-13445.

Based on this update, I'm going to mark this idea as Not Planned.

Regards,

Rob 

[stepher]

Greetings, All,

It looks like Robert was just doing some housekeeping and closing this out.  So, upfront, I completely admit this may be old news, but it caught my attention.

My response, when this occurs, is to spy the same element as an additional UIA element.  This is...inconvenient, and not always exactly possible (depending on the whims of the web developer).  To minimize the performance hit, I still use the original browser element for anything else related to the item, but I use the UIA element for the actual click.

Like I said, old news, but if it may help anyone...

Take care,

Red