Shadow DOMs and saleforce

HI Team,

I am using katalon for a month now, and i wanted to get 1 end to end scenario automate to prove to the business that it is brilliant tool
However I have iframe<6 shadow doms< final element, or combination of iframe< 7-8 shadow dom<iframe<shadow don<final element
It has become pain in the neck to design test object hierarchy
It would be good if spy tool could automatically record the shadow dom and iframe elements



Sorry for my bad. Can you please explain your situation in more details? What kind of 1 end-to-end scenario automation do you want? As well, the problem you faced


the elements i am trying to click - are under combination of iframes and shadow doms , does that add more context?

1 Like

I will quote an example from the Katalon’s official doc:

In this example,

  1. user must have prepared the Test Object named book_app object, which is a Shadow Root Parent, before he newly creates a Test Object named input for the element he wants.
  2. when a user created multiple Test Objects as Shadow Root Parent, named “book-app”, “boo-app2”, “book-app3” ---- he must remember what each of them are meant for, and he must choose a correct one as the parent of a new Test Object for the element he wants.

I think that these 2 requirements suffers @dipali.gawas.

I guess, @dipali.gawas wants the Recorder and Spy tool to automatically generate all of Test Objects as Shadow Root Parent when he creates a new Test Object for the element he wants to grab. He would agree to operate the tool to create a Test Object for the HTML element he wants to grab. But he does not like to be bothered with the Test Objects as Shadow DOM Root.

I guess, he want to say that the tools are incomplete. “The tools are informed of enough information when I specify the target HTML element. The tools should be aware what sort of Test Object as Shadow DOM Root is required. So it should generate everything at once for me. Why they don’t do so? Please don’t ask me to create Test Objects as ShadowDOM Root”.

Not only Shadow DOM, the same requirement applies to the parent <iframe>.


Am I right?

1 Like

Your target web app seems employing WebComponents technologies. I guess it is too sophisticated (advanced? complexed?) to test using Katalon Studio. I am sure that Katalon Studio is not designed with the WebComponent technogies in mind.

I would recommend you to shelve Katalon for now, and make a broader Google-search to find how others do automated UI testing for WebComponent-based web app. For example, I found the following

I think, if you are going to dive deep into testing WebComponents-based web apps, you should look at some JavaScript-native testing technologies like Cypress and Playwright to work with WebComponents-based web apps.

Or, if you are satisfied with just scratching the surface of your target web app, go-on with KS, while you need to create TestObjects for Shadow DOM Root.

1 Like

@kazurayam bang on! you understood my problem very well

  1. I would appreciate spy tool to do the job for me

  2. Rest of the test team members are going to be part of team for short stint, so I need to use a tool which will have short onboarding time- that’s the reason i went with katalon.

1 Like

Katalon Studio’s Test Object does not support grabbing HTML element under multiple layers of Shadow DOM. See the following discussion years ago

I don’t think the Spy & Recorder tools + Test Objects of Katalon Studio can ever support the nested Shadow DOM. You should not wait for it.

You had better look for alternatives like Cypress and Playwright. Or simply abandon your mission.

Testing a WebComponent-based web app is a difficult task. That is my impression I got from the articles which I quoted above. You should not underestimate it. You would need long enough onboarding time.

I found a tutorial

This tells us how to work with Shadow DOM (even nested Shadow DOM roots) in Java/Groovy using Selenium 4.

However, Katalon Studio runs on Selenum 3. It does not run on Selenium 4. Therefore you can not apply this approach in Katalon Studio.

Posted link is not a solution of question

It seems you haven’t read this discussion from the top.
All I am saying is @dipali.gawas can not solve his problem in Katalon Studio.

Why do I think so?

Let me add an explanation.

The Spy tool enables you to capture HTML elements visually:

You can visually identify HTML elements, hover curson on it, and select “Caputre Object”. OK. This works fine for all visible elements.

However, how can I capture the HTML element as “Shadow DOM Root” using the Spy tool? How can I capture the <iframe> element using the Record tool? — No, I can not. I can not caputure any invisible HTML nodes using the Spy and Record tool. The tools are incomplete in this sense.

In order to build a Test Object for a HTML element inside a Shadow DOM or <iframe>, I have to get out of the tools. I have to create the Test Object manually. I have to use Chrome DevTools to find out the detail of the target HTML node. I have to manually write CSS Selector to identify the Shadow DOM Root. — I suppose this is the reason why the original poster, @dipali.gawas, is unhappy with the tools. He wants the Spy tool to accomplish all he needs.

These tools works good enough for simple web pages without <iframe> and Shadow DOM. So, I suppose that Katalon team would be reluctant to change the current design.

Katalon documentation should clearly state that the Spy and Recorder tools are not enough to test web apps with WebComponents, especially nested Shadow DOM. — though, I know, they would not. Therefore I would write it here on behalf of Katalon.

I found a post by in May 2023, which mentions something about how to work with Shadow DOM in Katalon Studio.

I wanted to know how this sample Katalon project deals with the cases of nested Shadow DOM.

I had a quick look at the sample code in this project, but I could not find any code that deals with nested Shadow DOM.

I have studied a bit how to work with nested Shadow DOM with Selenium in Java/Groovy.

Selenium 4.x added getShadowRoot() method to the org.openqa.selenium.remote.RemoteWebElement class. This getShadowRoot() method is crucial to work with nested Shadow DOM.

On the other hand, org.openqa.selenium.remote.RemoteWebElement class of Selenium 3.x lacks the getShadowRoot() method.

Katalon Studio v8.6.x works on Selenium 3.x. It does not work on top of Selenium 4.x. Your code in Katalon Studio can not use getShadowRoot().

I would conclude that you can not work with nested Shadow DOM in Katalon Studio v8.6.x. Well, this is not a news at all.

1 Like

In the Release note

I found a statement


  • Supported recording multi-level Shadow DOM objects and locating them during runtime.

I was interested in this. I searched for more information about this enhancement. But I could not find any.

Has anyone tried it?

Hi @kazurayam, I’m currently using Katalon Studio ver 9x, which using selenium ver 4x (that’s what I found on GG), but I can’t call the getShadowRoot() method from Selenium. Is there anyway I can check if the tool is using the version of library I want?

Hi there,

Thank you very much for your topic. Please note that it may take a little while before a member of our community or from Katalon team responds to you.



I think that there is no official version of Katalon Studio that works on top of Selenium4.

The following post mentioned that the team will work for Selenium4 this year:

Yup, I think I’ve read a misleading information, but since the tool allows user to add external libs to project, will it provides a method to specify the version of library so the user can decide which version they will use?


In order to tell you why, I need to explain the .classpath file first.

All Katalon project has a file named .classpath in the root directory. The classpath file is auto-generated when you open the project by Eclipse platform on which Katalon Studio runs. Your project will have one as well. Please find a .classpath file of your project and have a look at it.

Here I would show you an example .classpath of my Katalon project created by Katalon Studio v9.0. I intentionally inserted the jar of latest version of Apache POI 5.2.5 into the “Drivers” folder.

.classpath (24.2 KB)

Inside the file, you will find the poi-x.x.x.jar to appear twice:


	<classpathentry kind="lib" path="/Applications/Katalon"/>


	<classpathentry kind="lib" path="/Users/kazurayam/katalon-workspace/test/Drivers/poi-5.2.5.jar"/>

Katalon Studio will look for an individual class binary to load into JVM in all the jar files declared in the .classpath. It will look through the jars from the top to bottom as declared in the .classpath file. In other words the classes contained in poi-3.17.jar will have higher precedence to the classes contained poi-5.2.5.jar because the jar of ver3.17 comes first. What will happen if my Test Case script called the POI API? — Nobody can tell what will happen. We will see a total mess. The POI classes of the old v3.17 and the new v5.2.5 will be refered intermixed runtime.

Katalon Studio is NOT designed to drop the older poi-3.17.jar entirely when I inserted the newer poi-5.2.5. In other words, KS does not offer you to utilize such a “dependecy management” capability that Maven/Gradle provides.

When you put an “external” jar which is not bundled in the Katalon Studio distributable at all, yes, you will have no problem. Your test case script can safely use the classes in your new-comer jar.

When you put a newer version of jar of which older version is bundled in the Katalon Studio distributable (such as the poi-x.x.x.jar), no, you will get a total mess.

Similarly, you can not switch the version of Selenium WebDriver from v3 to v4 very easily.

The following description will be informative for you:

Exclude built-in libraries

  • An active Katalon Studio Enterprise license.
  • Katalon Studio version 7.8.0 onwards.

The Exclude built-in libraries feature allows you to remove built-in libraries stored in the .classpath file of a project folder. This feature applies to all libraries in the .classpath file, excluding the following:

  • com.kms.katalon.*.jar
  • selenium-server-standalone-3.141.59.jar
  • poi-3.17.jar
  • poi-ooxml-3.17.jar
  • poi-ooxml-schemas-3.17.jar
  • java-client-7.0.0.jar
  • io.cucumber.*.jar

Removing the above libraries may cause failure of the relevant features.