Embedded Macros Now Close The Page

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?

We expect to have the next version available at the end of April, so in around 2-3 weeks. This will of course include the patches for this issue.

It is great I have come across this thread. My friend is a developer. And to gain some experience and fresh information, he is giving consultations for free. He is from New York, 323 area code. He is available at any time and will help you immediately after you get in touch with him. But I cannot disclose his details here. So please write to my private message box to get his contacts.

@Anton_Mazur What kind of issue(s) do you have? If they are not reported already, please report them now here in the forum, so that the Kantu team can fix them with the next update.

Meanwhile, you can revert any update with a version from the archive.

@admin Any news on the patch? I worked my own validation into the line breaks issue that just globally replaces the \n with an actual line break, but I haven’t found any good workarounds for the API macro problem unfortunately.

Thanks

The bug is fixed already internally. But some other (unrelated) features are not done yet and are holding up the next update. But it should be ready in 1-2 weeks.

Any chance a patch version can be submitted a la 5.5.8? If it’s already fixed in your dev build, could you fork the current 5.5.7 with some of the bug fixes? That way you wouldn’t be launching an update with whatever new features half built.

If it’s going to be another few weeks, that would give the Google team plenty of time to review before your next version is ready. The update I pushed on my extension “only” took 2 or 3 days to be reviewed. Again, not trying to be a pain, but you mentioned it would be 2-3 weeks last time.

It just sucks because Kantu is MUCH more useful with embedded command line macros than any other method.

Ok, understood. We will upload it today in our beta channel. Then lets see how long it takes the Chrome team to review it…

This issue is finally completely solved with V5.7.3: UI.Vision RPA V5.7.5 available

Technical details: Only when the “Run embedded macros…” option is checked, UI.Vision inserts data-kantu=“1” into the website. This is the way the embedded Javascript macro knows that UI.Vision is installed. Otherwise the embedded Javascript prompts the user to download the extension first.

data-kantu