Why does Firefox hate my Chrome-tested scripts?

Web Testing
1

Katalon keeps giving me a ClickInterceptedException or sometimes it says it can’t find the element at all. I haven’t changed a single line of code. Is Firefox’s driver different? I even tried to slow it down, but it seems like Firefox renders the page differently, and now my XPaths that worked in Chrome are suddenly “invalid” or “not visible.” Here is a snippet of the error I get in the console:

Plaintext

Build info: version: '3.141.59', revision: 'e82be7d358', time: '2018-11-14T08:25:53'
System info: os.name: 'Windows 10', os.arch: 'amd64', os.version: '10.0', java.version: '1.8.0_181'
Driver info: org.openqa.selenium.firefox.FirefoxDriver
Capabilities: {browserName: firefox, moz:headless: false, ...}
Element <button id="login"> is not clickable at point (415, 620) because another element <div class="overlay"> obscures it.

How can the same script work in one browser but fail in another? Do I have to write separate scripts for every browser?

2

That’s the worst approach. You never need to do so.

3

Do you explictly specify the width of browser window? using

If not, specify the window size and try again.

If you do not specify the window width explicitly, then Chrome and Firefox may open a window with different width. With different width given, your web page would be rendered differently, especially when the web page is styled floating. In such case, your test becomes fragile; it passes in the case A but fails in the case B. You should avoid any undeterministic factors out of your test script.

There could be many other factors that make your Web UI test fagile, but most of all you should determine the window width.

4

Your issue is not a browser-specific bug—it’s a cross-browser rendering and timing difference. The error message clearly shows that an overlay element (<div class="overlay">) is blocking your button from being clicked. Here’s why this happens differently in Firefox vs. Chrome:

Root Causes:

  1. Different rendering speeds - Firefox and Chrome render overlays and animations at different speeds
  2. Timing/synchronization issues - The overlay may take longer to disappear in Firefox than Chrome
  3. Browser-specific DOM handling - Each browser handles DOM mutations and CSS animations differently
  4. Your code hasn’t changed - The issue is environmental, not your XPath or logic

Good news: You do NOT need separate scripts for each browser. The solution is to add proper synchronization.

Solutions (Ranked by Effectiveness)

Solution 1: Use WebUI.waitForElementClickable (Recommended)

This is the official Katalon solution for this exact error. It waits for the element to be both visible AND not obscured by overlays:

import com.kms.katalon.core.webui.keyword.WebUiBuiltInKeywords as WebUI

// Wait for the button to be clickable (waits for overlay to disappear)
WebUI.waitForElementClickable(findTestObject('your/object/path'), 10)

// Now click it
WebUI.click(findTestObject('your/object/path'))

Why this works: This keyword intelligently waits for the element to be in a clickable state, handling overlay timing differences across browsers automatically.

Parameters:

  • to (TestObject): Your target element
  • timeout (int): Maximum seconds to wait (adjust based on your overlay animation duration)
  • Returns: true if clickable, false if timeout occurs

Solution 2: Remove the Overlay Before Clicking

If you know what’s causing the overlay, remove it first:

// Close a modal dialog or popup
WebUI.click(findTestObject('close_button'))

// Wait for overlay to disappear
WebUI.waitForElementNotPresent(findTestObject('overlay_div'), 5)

// Now click your target
WebUI.click(findTestObject('your/object/path'))

Solution 3: Use JavaScript Click (Last Resort)

If the above solutions don’t work, use JavaScript to bypass the overlay:

import com.kms.katalon.core.webui.common.WebUiCommonHelper

WebElement element = WebUiCommonHelper.findWebElement(findTestObject('your/object/path'), 30)
WebUI.executeJavaScript("arguments[0].click()", Arrays.asList(element))

Note: This bypasses Selenium’s safety checks, so use only when necessary.

Key Considerations

Why Firefox behaves differently:

  • Firefox’s rendering engine (Gecko) processes CSS animations and DOM updates differently than Chrome’s (Blink)
  • Overlay animations may complete at different times
  • This is not a Katalon issue—it’s inherent to how browsers work

Best practices to avoid this issue:

  1. Always use waitForElementClickable before clicking elements that might have overlays
  2. Increase timeout values for Firefox if needed (e.g., 15 seconds instead of 10)
  3. Test on both browsers during development to catch timing issues early
  4. Use explicit waits instead of Thread.sleep() for better reliability

Your XPaths are fine - the issue is timing, not element identification.

References

5

No browser-specific scripts needed: Firefox/Chrome differ in rendering, window size, timing—causes overlays (ClickInterceptedException) & XPath fails.

Universal Fixes

WebUI.setViewPortSize(1920, 1080)  // Fixed size EVERY test
WebUI.waitForElementClickable(findTestObject('login_btn'), 20)
WebUI.enhancedClick(findTestObject('login_btn'))  // Handles overlays

XPath tip: Use contains(@class, 'overlay') for dynamic; avoid IDs if JS-generated.

Root: Firefox narrower default viewport → float/overlay shifts. Always standardize viewport first!

6

Why it works in Chrome but fails in Firefox

Chrome and Firefox do not render pages exactly the same way:

  • Firefox may load or animate elements slightly slower

  • Element positions can differ by a few pixels

  • A popup, spinner, sticky header, or overlay may still be sitting on top of the button in Firefox

  • Firefox is often stricter about whether an element is truly clickable

Your error already tells the real cause:

another element <div class="overlay"> obscures it

So Katalon found the button, but Firefox refused to click because an overlay is covering it.

No, you do NOT need separate scripts for every browser
Best Fix: Wait for the overlay to disappear

Before clicking the login button:

WebUI.waitForElementNotVisible(findTestObject('Page_Login/div_overlay'), 20)
WebUI.waitForElementClickable(findTestObject('Page_Login/btn_Login'), 20)
WebUI.click(findTestObject('Page_Login/btn_Login')

If Firefox still blocks the click

As a last resort, you can bypass the normal click and use JavaScript:

TestObject loginBtn = findTestObject('Page_Login/btn_Login')

WebUI.executeJavaScript(
    "arguments[0].click();",
    Arrays.asList(WebUiCommonHelper.findWebElement(loginBtn, 20))
)

This forces the click even if Firefox thinks something is slightly overlapping.

7

What you are experiencing is the reality of Cross-Browser Engine differences. Chrome (Chromium) and Firefox (Gecko) have different rendering speeds, padding calculations, and handling of “element-is-clickable” checks.

In a professional automation framework, we never write browser-specific scripts. Instead, we implement Browser-Agnostic Interaction Layers. The error ClickInterceptedException in Firefox usually means that while Chrome is “forgiving” and clicks the center of the element even if a tiny transparent overlay exists, Firefox strictly adheres to the W3C standard and refuses to click if any pixel of another element is on top.

The Solution: JavaScript Force-Clicks and Robust Waiting

To solve this architecturally, we move away from the standard “Physical Click” (which mimics the hardware mouse) to a “DOM-Level Click” when physical clicks are blocked by rendering differences.

  1. Update Driver Executables: Ensure your GeckoDriver is up to date in Katalon (Tools > Update WebDrivers > Firefox).

  2. Use JavaScript Click: For elements that are technically present but “obscured” by rendering quirks in Firefox.

Custom Keyword: The Universal Clicker

This keyword attempts a standard click first (to maintain realism) but falls back to a JavaScript click if Firefox reports an interception.

Groovy

package com.browser.flex

import com.kms.katalon.core.annotation.Keyword
import com.kms.katalon.core.webui.keyword.WebUiBuiltInKeywords as WebUI
import com.kms.katalon.core.testobject.TestObject
import com.kms.katalon.core.webui.driver.DriverFactory
import org.openqa.selenium.JavascriptExecutor
import org.openqa.selenium.WebElement
import com.kms.katalon.core.webui.common.WebUiCommonHelper

public class BrowserAgnostic {

    @Keyword
    def safeClick(TestObject to, int timeout = 10) {
        try {
            WebUI.waitForElementClickable(to, timeout)
            WebUI.click(to)
            println "Normal click successful."
        } catch (Exception e) {
            println "Normal click failed or intercepted. Attempting JS Click for cross-browser stability..."
            
            // Fetch the underlying Selenium WebElement
            WebElement element = WebUiCommonHelper.findWebElement(to, timeout)
            JavascriptExecutor js = (JavascriptExecutor) DriverFactory.getWebDriver()
            
            // Execute the click via JavaScript (ignores overlays)
            js.executeScript("arguments[0].click();", element)
        }
    }
}

Strategic Advice:

  • Viewport Matters: Firefox often opens in a different default window size than Chrome. Ensure you use WebUI.maximizeWindow() at the start of every test to ensure elements are in the same relative positions.

  • Avoid Absolute XPaths: If you used the recorder, you might have XPaths like /html/body/div[2]/.... Firefox’s DOM rendering can occasionally differ by one index. Always use Relative XPaths (e.g., //button[@id='login']).

  • Scroll to Element: Firefox is stricter about clicking elements that are “off-screen.” Use WebUI.scrollToElement(to, timeout) before clicking.

By using the safeClick keyword, you create a script that is resilient enough to handle the subtle rendering quirks of both Chromium and Gecko engines without needing two sets of code.

Are you running these tests on your local machine, or are you using a headless environment like a CI/CD pipeline?

8

Cross Browser Scripting Issue, Need to test on all browser when writing script/recording.

9

hi @aeffertz

seems like Firefox strictly follows W3C standards and blocks clicks when an overlay is on top; Chrome is more lenient.

Standardize your viewport at test start so both browsers render identically:

WebUI.setViewPortSize(1920, 1080)

Then wait for the overlay to clear before clicking:

WebUI.waitForElementNotVisible(findTestObject('Page/div_overlay'), 10)
WebUI.waitForElementClickable(findTestObject('Page/btn_login'), 10)
WebUI.click(findTestObject('Page/btn_login'))

If Firefox still reports interception, fall back to JavaScript click:

WebElement el = WebUiCommonHelper.findWebElement(findTestObject('Page/btn_login'), 10)
WebUI.executeJavaScript("arguments[0].click()", Arrays.asList(el))
10

Look, if you want this fixed immediately across all browsers, just force the click using JavaScript.

In the real world, Firefox is a stickler for rules. If a transparent loading overlay or a weird CSS margin is even slightly in the way, it’ll refuse to click and throw that “Intercepted” error. Chrome is usually more “chill” and ignores those tiny overlaps.

By using a JavaScript click, you stop acting like a physical mouse and start talking directly to the code. It doesn’t matter if there’s an overlay or if the rendering is slightly off; the click will happen. It’s the industry-standard “silver bullet” for making a single script behave across different browser engines.

11

Yes, Firefox implements w3C standards strictly