Hey, Katalon 7.8.0 official release is out with new cool features. It's cooler to have your feedback!


Hi guys !

We’re excited to announce that a beta release of 7.8 is available for our Katalon pioneer users. We’re calling out for your use at its beta stage.

EDIT: Version 7.8.0 is now out of beta and officially released.

Download here!

This version includes a few new features that are robust and super helpful in saving your time and effort in designing and debugging your test scripts.

Should you have any feedback or comment, we’d love to hear. <3

Happy Testing!
The Katalon team

Brief note for each feature

I think I should blabber a bit about these features.

Time Capsule

Time Capsule captures the state of your application when the test fails. No not a picture of your application when the test fails but the actual HTML, CSS of the application. Yes, that also includes the visual aspect of your application as well.

This feature was born out of an observation that whenever test fails, to reproduce the state you have either do that manually or re-execute the test again. For simple test cases that’s okay, but for complex test cases manually reproducing is really time-consuming, and re-executing the test again is prone to risk of failing due to other reasons.

Therefore, Time Capsule effectively eliminates the time to reproduce the state of the application when the test fails down to zero. With this, you can capture new objects on the page, or see which HTML components are problematic. Hopefully you will find this feature valuable in helping you troubleshoot execution failures.

Coordinates-based recording

Due to some limitations of WinAppDriver, there are certain elements that Katalon Windows (Native) Recorder cannot interact. For example, the small X inside a tab, which is important if you want to test if the tab is closable. In these situations, previously you have to know how to write code in order to find the coordinates and click on that. But with this feature, all of that is just a few buttons and checkboxes away. Coordinate-based recording allows you to interact with pretty much all elements within a window, regardless of its position.

Browser-based video recording

Don’t you find it annoying when you execute a test in headless mode and an element is not clickable but you don’t know why, even though the same test runs fine in regular browsers ? Well, we feel the same pain too, which is why this browser-based recording also works in headless mode. This is exciting because now you have more reliable clues (read visual clues) as to why headless tests are failing.

Aside from headless tests, the video recording works on the browser-level, which means that you can execute tests in parallel, and the video recordings will be for each parallel execution. Previously, the video recording feature on the windows-level was not able to handle this scenario. Now with this feature you can immediately combine video recordings with parallel executions in order to enable you to see precisely how individual tests were executed.

Final words

Personally, I am thrilled to introduce these features to you, because I think they solve particularly painful problems that some of you may have realized them, while some of you are used to living with them. Either way, I believe these features will provide immediate value to your test automation projects.

Thank you, and have a great day !

PS: Shamelessly calling out to our users @Russ_Thomas @Brandon_Hein @kazurayam @Dave_Evers @Chris_Trevarthen. What do you guys think ?

(Edited by @Russ_Thomas to replace “rc” link with official release.)


These all sound like great additions, @ThanhTo - for me, the video recording is most interesting but I can imagine others will find all these improvements very useful.

Video recording: I wrote my own using ffmpeg. The need I wanted to satisfy was being able to target a specific monitor in a multi-monitor setup. Our customers sometimes use multiple monitors where they launch new browsers to view different parts of the application on multiple screens. Obviously, it’s important I can test these scenarios and (sometimes) record the results.

Here is one of the command lines I use currently:

bin\ffmpeg -y -f gdigrab -framerate 10 -offset_x -1920 -offset_y 0 -video_size 1920x1080 -show_region 1 -i desktop %1

That is from a batch script called 1920x1080-left.bat that targets the leftmost monitor (where -offset_x -1920 is a screenwidth to the left of the primary monitor). I have four batch scripts matching four monitors.

Feature request: I hope at some point the devs can provide APIs/UIs to allow me to do that from within Katalon.

Time capsule : (good name! :slight_smile: ) I’m intrigued to know how that works but it might be a while before I can upgrade :frowning:

  1. Does Katalon write out the current DOM and save it somewhere?
  2. Does Katalon re-download the pages up to the failure point?

I can see problems with both of these… but what do I know, maybe there’s a golden solution I didn’t think of :nerd_face: :astonished:

1 Like


Time Capsule captures the MHTML of the page when a test fails. For test cases, the captured files are stored in the temporary folders (the path is available in the Log Viewer after test execution). For test suites, the files are stored in the report folders.

1 Like

Wow, MHTML - that takes me back! I thought that had died a death a long time ago. Interesting…

Here you go - proposed standard in 1999 :upside_down_face:


Time Capsule and TestOps Visual Testing — are they incorporating or not?

My job wants me to do visual testing for a web site on multiple viewPortSizes — on PC display, iPad, a few Mobile phones — both of horizontal and vertical. My VisualTestingInKatalonStudio project regretfully takes screenshot images of web pages. If I want to test 5 devices, then I need to run long-running process 5 times. But what if it saves MHTML instead of PNG image files? It can compare images of multiple viewPortSizes rendered based on a single set of MHTML. It would be drastically time-saving.

(edit at 20 Nov)
In order to extend my VisualTestingInKatalonStudio with MHTML feature, I would require a pair of new Keywords:

  1. WebUI.savePageSnapshot(Path mhtmlFile), this enables me to save the web page into a MHTML file
  2. WebUI.loadPageSnapshot(Path mhtmlFile), this enables me to load the web page from a MHTML file
1 Like


Please answer to the Russ’ question:

Saying MHTML does not answer to these questions.

If it can save the current DOM which has been manipulated by AJAX JavaScripts, it’s fantastic.

However, as far as I am aware, Chrome browser does NOT write the current DOM when I do Save as > ... *.htm. It saves the html source and other resources initially downloaded, and the saved stuff does not reflect any DOM-manipulation performed by JavaScript after loading. Am I right or wrong?

If you go to this AUT and try to book an appointment, then there will be a date picker that appears to pick the date. If the object which is a particular date within this date picker fails to be located (invalid locator), then Time Capsule still captures the date picker as it appears.

Here’s a snippet of what Time Capsule captures (It’s actually an entire HTML + CSS, not just an image):

Not sure if this date picker is manipulated by AJAX, but since it’s something that wasn’t already visible when the page is loaded, would this answer your question ? I can test a case if you can give me a specific scenario and a public AUT.

1 Like

Sorry, I do not understand what to do to reproduce.

Please try http://demoaut-mimic.kazurayam.com/

The date/time displayed in this page is dynamically generated by a onLoad event handler in JavaScript:


   * display the current timestamp in the format of "07:22:13"
  $(document).ready(function() {
    var m = new Date();
    var dateString = m.getUTCFullYear() +"/"+ (m.getUTCMonth()+1) +"/"+
                     m.getUTCDate() + " " + m.getUTCHours() + ":" +
                    m.getUTCMinutes() + ":" + m.getUTCSeconds();

I tried opening the page in Chrome browser and “Save as …”, and I reopened the saved resource. I noticed that the element selectable by $('#clock') was blank; no date time value 2020/11/1 xx:xx:xx UTC. Why? I do not know yet. It seems that the $(document).ready() function was not fired somehow.

I am interested if KS 7.8 Time Capsule can reproduce the date time value to be displayed as it was.

And I am interested, if the date/time value is displayed, what the time value is. Is it the time an old one when the page was saved into MHTML? Or is it the time a new one when the page was reloaded from MHTML.

IMHO, saving the current DOM is NOT so much useful from the End-to-end test automation point of view. If we need to test DOM status transition, I think that we should employ different approach of testing (rather than high level E2E automation); we should do unit-tests with DOM-inspecting codes in Unit-testing frameworks such as Jasmine or Qunit.

1 Like

It worked here. Opened the site in Chrome, right-click, save-as “demo.mhtml”. Found the file in file explorer, it opened in IE11 (because that’s what is registered as handler for *.mhtml) and the time is as it was when the file was saved.


Just a side note, you can drag and drop the mhtml into chrome browser to view, for those of you who refuse to use (or don’t use) IE.

I am excited about browser-based video recording :slight_smile: !
as said in https://github.com/katalon-studio/katalon-studio/issues/352, I need it in Katalon Runtime.

Will it be accessible trough “Katalon Runtime” ?
What will be the parameters to configure it by command line?

How can I save snapshot of web page into MHTML? See my research report:

1 Like