Embedded Macros Now Close The Page

With the latest update, my embedded macros now close the tab they were launched from unless it was the ONLY tab open. You can see this happen in the example macros in the page I linked. This has never happened to me until today’s update.

Was this on purpose? If so, can that please not be the default? I distribute these and it’s going to cause some major, major problems.

As always, thanks for your hard work in continuing to support this awesome extension, but please try to resolve this as soon as possible.

1 Like

I’m also having a weird issue where where the “Type” command doesn’t properly insert line breaks anymore with \n in my embedded macros. It works as normal when they are run from within the macro. They worked just fine before the update.

I’m starting to really wish the current update would just be reverted. Although I’m excited for Array support, especially now that we have forEach available, but considering that my entire setup is broken I can’t really even make use of the new features.

Update on the “Type” problem above: when I do just plain
Type|target=replycontents|Hello\nWorld!

It works just fine. But we have a bunch of conditions that can be met where I’m dynamically building the message based on certain things:

Store|Hello\n\nWorld!|message
if|something is true||
Store|${message}Line\n\nBreaks\nDon’t\nWork\n\nHere|message
end||
type|target=replycontents|message

That used to work perfectly. I know there are probably 1,000 other ways to accomplish this, but I have numerous embedded macros following this convention that are all broken as of today.

Just found that the “Type” issue isn’t just happening when the macros are embedded.

At this point, I’ve found that basically everything I have is broken now thanks to this latest update.

This is happening to me too. It’s really screwing up my workflows! Every time I click on an embedded macro the page just disappears.

1 Like

The change is related to the continueInLastUsedTab flag. With the latest update the default is set to 1 (“true”), because this makes most sense for use with the command line API. I agree that for embedded macros you will probably need to run it in a new tab quite often.

Solution: Please use selectWindow | TAB=OPEN | https://your-url.... command to open a page, instead of the simple OPEN command.

Macro2 on https://ui.vision/demo/runweb uses it, too.

Well, I guess I answered too fast. I confirmed that it does not work this way with V5.5.7… but it should! So this is a bug and will be fixed.

As a quick fix, please visit our version archive to downgrade: https://ui.vision/rpa/archive

1 Like

We are not aware of any bugs other than the “open in same tab” issue and this if_v1 problem. If there is anything else, please open a new forum post for each bug and we will look at it asap.

Hi @admin, thanks for responding. Unfortunately this isn’t exactly a viable solution. The conditions I mentioned above are based on radio buttons/checkboxes that I’m clicking on the page.

If I were to refresh, then everything will disappear and the macro is useless.

I saw the continueInLastTab that you posted before you edited the response, but another massive, massive problem is that my embeds are being handled by a Chrome Extension that I built. With COVID-19, Google is taking ages to review extension updates. It’s going to be at least 2 weeks now for anything to function correctly on my end.

Regardless, at least with any dev-ops team I’ve worked with, it never ever makes sense to suddenly change default behavior in a way that breaks users’ existing implementations. As I’m sure you know, that’s why deprecation exists, and users can update accordingly.

I get that closing the tab kind of makes sense for command line API macros opened from a local HTML file, but it makes no sense at all for embedded macros. It would have been fine if you had launched Kantu with this as the default, but updating this out of the blue with zero warning has got me baffled.

Again, I do want to extend my appreciation for this tool. I don’t want to sound like I’m not grateful for it because you guys have saved me a HUGE amount of work in the past, but I’m just incredibly frustrated with the latest release.

If I were to refresh, then everything will disappear and the macro is useless.

Sorry, I don’t understand. Refresh what??

selectWindow | TAB=OPEN | https://your-url

This would just open the page in a new tab. I use embedded macros because I have some pages where there are checkboxes that control the macro’s behavior. With the current update, if I launch an embedded macro, my tab closes and now there aren’t any checkboxes. That said, I can’t open a new tab because then all of the checkboxes will be empty. It’s akin to a refresh.

I totally agree. This breaking change was not planned and it escaped our beta testing.

For Enterprise Edition users we have custom builds, so the user can control the update cycle.

I totally understand. We will reverse this change (= fix this bug) asap. Unfortunately what you wrote " With COVID-19, Google is taking ages to review extension updates." is true for us as well.

Possible solutions for now:
Can your users use a version from the archive? Or, in Firefox, disable automatic extension updates?

I’ll give it a shot. Fingers crossed!

@admin The downgrade seems OK now at least for me… unfortunately it’s going to cause some bottlenecks as it’s just not feasible to get everyone else (on my end) to do this. What about the below? I confirmed this DOES work after downgrading, but NOT with the new version. Do you want this in a new forum post?

Is there any timeframe you can estimate for how long it might take for a fix to be live? I don’t mean to be pushy, but a lot of things my side depended on embeds and now it’s broken… :slightly_frowning_face:

I’m sure you give guidelines of some sort to your beta testers, right? Were embedded macros not included?

If problem: Please see Deprecated if_v1 may not correctly work on v5.5.6 or later => this can be fixed by upgrading your macro to if_v2.

I’m sure you give guidelines of some sort to your beta testers, right? Were embedded macros not included?

Beta testers are regular (power) users like me :wink: , so you can sign-up too! This way you can review new releases before they hit the main channel and report regression issues early on.

1 Like

Hi @ulrich, thanks for the reply!

It’s not an issue with if_v1; I haven’t used this at all since its deprecation.

It’s an issue with “store.” My conditionals are executing just fine. The macro isn’t rendering line breaks correctly. It prints the \n instead of actually breaking the line.

This doesn’t happen when I use “Type”, but I’m building a message variable dynamically. I know there are several ways to do this, but that’s how my setup is and something with the latest update broke it.

It’s an issue with “store.” My conditionals are executing just fine. The macro isn’t rendering line breaks correctly. It prints the \n instead of actually breaking the line.

Can you please make a new forum post for this? Ideally with a test macro, thanks!

@admin are there no workarounds for this at the moment other than downgrading? I tried using the command line parameters but nothing stops this from happening.

continueInLastUsedTab: 1 still closes out my tabs. I’d be fine for now with adding in some kind of fallback in my Chrome Extension, but if I can’t do anything about this, is there any estimated timetable for when the two bugs I reported can be patched?