TimedPromise timed out after 500 ms: stacktrace: from click in selenium

[jtnord]

I'm having an issue with clicking on a button in some very narrow circumstance from Selenium.

The button is a form save button (it's submits a form but via javascript so is not a submit button) so we use WebElement.click()
Everything pretty works as expected. However there is a case where if one element in the form currently has focus then when it looses focus it does some client side javascript validation to show / clear an inline warning.

The problem we have is that in this case the click on the "save" never appears to happen. If we sleep after the button.click and perform another click on the same WebElement (object reference) then things work.

This issue only occurs in Firefox, not Chrome.
enabling debug logs in selenium/geckodriver shows the following

1756225604628   webdriver::server       DEBUG   <- 200 OK {"value":true}
1756225604630   webdriver::server       DEBUG   -> POST /session/c6803ae7-2a49-45f8-8b52-08de41f8ed82/element/b78fc7c6-28c0-424e-8942-13cfbd4ff548/click {
  "id": "b78fc7c6-28c0-424e-8942-13cfbd4ff548"
}
1756225604630   Marionette      DEBUG   0 -> [0,443,"WebDriver:ElementClick",{"id":"b78fc7c6-28c0-424e-8942-13cfbd4ff548"}]
1756225605134   RemoteAgent     WARN    TimedPromise timed out after 500 ms: stacktrace:
TimedPromise/<@chrome://remote/content/shared/Sync.sys.mjs:448:24
TimedPromise@chrome://remote/content/shared/Sync.sys.mjs:432:10
interaction.flushEventLoop@chrome://remote/content/marionette/interaction.sys.mjs:465:10
webdriverClickElement@chrome://remote/content/marionette/interaction.sys.mjs:218:33
1756225605185   Marionette      DEBUG   0 <- [1,443,null,{"value":null}]

firefox: 142.0.1 (64-bit) (windows 11)
geckodriver: 0.36.0 (a3d508507022 2025-02-24 15:57 +0000)

Steps to reproduce.

• Install Java 17 (or 21) and Maven (3.9)
• clone https://github.com/jenkinsci/acceptance-test-harness/
• fetch Selenium bump jenkinsci/acceptance-test-harness#2137 (and use commit sha 7bd27723e17c75178ad784ef8bc4660c80a3e8ab)
• ensure you have a docker deamon (configured to use linux containers).
• download Jenkins https://get.jenkins.io/war-stable/2.516.2/jenkins.war
• export BROWSER=firefox
• export JENKINS_JAVA_OPTS=-Xmx1280m
• export JENKINS_WAR=jenkins.war (use the path to Jenkins downloaded earlier)
• run maven with the specific test mvn test -Dtest=GitPluginTest#calculate_changelog
• with enabling debuggin on the geckodriver you can observe the stack above.

[whimboo]

The setup seems to be quite complex. Lets see if we can get it investigated via logs, and maybe you could create a screenshot as well which shows the UI while the code is waiting for the click to happen? Also more context for the trace log would be good.

In general do I understand it right that the changes based on jenkinsci/acceptance-test-harness#2137 are triggering this failure? So it's related to scrolling? Or does the opened warning cause a move of an element. Further is the click maybe aborted due to a call to preventDefault()?

[jtnord]

The setup seems to be quite complex.

Lets see if we can get it investigated via logs, and maybe you could create a screenshot as well which shows the UI while the code is waiting for the click to happen?

there is a video (see ~23-255s in, then there is scroll and we wait 30s wating for something to happen)) and screenshot from our CI

screenshot:

screenshot showing validation area: (~23s)

this is a screenshot of the validation that gets cleared when a user enters something and the element looses focus (in here the name of repository has focus)

Alas the recording framerate is too slow to capture the entry of the "name of the branch" which can be seen in the final screenshot as "testBranch" which is right at the top of the screen (

Also more context for the trace log would be good.

Sure, I will upload this as a gist.

In general do I understand it right that the changes based on jenkinsci/acceptance-test-harness#2137 are triggering this failure?

the failure is triggered by a specific change that removes our custom scrolling implementation. (jenkinsci/acceptance-test-harness@c8ca75e)
Given Selenium (webdriver) spec is performs a scroll into visible there should be no need for our implementation that adds unescessary round commands (and slows things down enough that this issue was not visible before).

So it's related to scrolling?

I do not think so you can see in the final screenshot (and video) that the save button is in view and not obscured. (Its just that we previously did some "manual" scrolling in our framework that should not be needed that introduced some delays).

Or does the opened warning cause a move of an element.

it removes an element (I think it hides it, which will cause things to move)

Further is the click maybe aborted due to a call to preventDefault()?

not sure I am following. if we introduce a delay (e.g. Thread.sleep() and click the the button again, or tab out of the current element with focus then this issue does not occur).

[jtnord]

gist containing more context.
logs with the entry of the branch and the following click on the save button

[jtnord]

The setup seems to be quite complex.

@whimboo would removing the docker requirement help? I'm not entirely sure what's wrong to know if I could pare this down to a simpler reproduction (but it would still require Maven and Java if I where to attempt it)

[jtnord]

maybe(?) related I managed to catch the following in the devtools console. (but then the element is scrolled into view)

This site appears to use a scroll-linked positioning effect. This may not work well with asynchronous panning; see https://firefox-source-docs.mozilla.org/performance/scroll-linked_effects.html for further details and to join the discussion on related tools and features! [configure](http://192.168.176.1:64510/job/hilarious_suspicion/configure)
Scroll anchoring was disabled in a scroll container because of too many consecutive adjustments (10) with too little total distance (-1.11000003814697 px average, -11.1 px total). [configure](http://192.168.176.1:64510/job/hilarious_suspicion/configure)

we have code that disables our "Sticky positioning" when running under test so that we do not obscure (hide / render over and intercept any clicks) any elements.

I am also unable to reproduce this in the following javascript in the console after performing the same disabling of sticky elements (which is why I believe this not to be obviously related to our code). (ie the following code always submits the form)

function doIt() {
  compareTarget = document.getElementById("git.compareTarget")
  submitButtons = document.getElementsByName("Submit")
  submitButton = submitButtons[0]

  compareTarget.value = "anyThing"
  // it appears to make no difference if we call scrollIntoView()
  submitButton.scrollIntoView()
  submitButton.click()
}

doIt()

[whimboo]

Hm, does the above code example fail for you when you comment out the scrollIntoView() call? I wonder if this could be related to w3c/webdriver#1924 which I fixed today. In Firefox we still use auto as scroll behavior, which probably defaults to smooth and needs to be reverted to instant via https://bugzilla.mozilla.org/show_bug.cgi?id=1986238. That means that the submit button that you are trying to click might not be immediately in the viewport and as such the click (even though at the correct position) will not receive the button.

To verify I've created a try build with the required change in Firefox. Please take a look at:
https://treeherder.mozilla.org/jobs?repo=try&revision=6c31bcb3a8cffd6cf23862b217d43fa90f1102f6

There will be Ba jobs soon available. Click the one for your platform and in the opening pane at the bottom find the artifacts section. In there you can find the binary as eg. target.zip for Windows. Just unpack and run Firefox with that test - does it work?

[jtnord]

Hm, does the above code example fail for you when you comment out the scrollIntoView() call?

The js code works with and without the scrollIntoView

I wonder if this could be related to w3c/webdriver#1924 which I fixed today. In Firefox we still use auto as scroll behavior, which probably defaults to smooth and needs to be reverted to instant via https://bugzilla.mozilla.org/show_bug.cgi?id=1986238.

🤔 https://github.com/jenkinsci/acceptance-test-harness/blob/a09fcf8f8f5002188c1bcbd424749b94ad31da30/src/main/resources/org/jenkinsci/test/acceptance/selenium/disable-sticky-elements.js#L2

Which we call after loging every page. I guess that should be instant not initial? (And potentially removed altogether if the changes below work)

That means that the submit button that you are trying to click might not be immediately in the viewport and as such the click (even though at the correct position) will not receive the button.

To verify I've created a try build with the required change in Firefox. Please take a look at: https://treeherder.mozilla.org/jobs?repo=try&revision=6c31bcb3a8cffd6cf23862b217d43fa90f1102f6

There will be Ba jobs soon available. Click the one for your platform and in the opening pane at the bottom find the artifacts section. In there you can find the binary as eg. target.zip for Windows. Just unpack and run Firefox with that test - does it work?

Will test and update here. Thanks

[jtnord]

To verify I've created a try build with the required change in Firefox. Please take a look at: https://treeherder.mozilla.org/jobs?repo=try&revision=6c31bcb3a8cffd6cf23862b217d43fa90f1102f6

Alas there was no difference.

  "id": "8e0d493f-0013-48c1-9114-97a546e318e0"
}
1756804675337   Marionette      DEBUG   0 -> [0,444,"WebDriver:ElementSendKeys",{"id":"8e0d493f-0013-48c1-9114-97a546e318e0","text":"testBranch","value":["t","e","s","t","B","r","a","n","c","h"]}]
1756804675345   Marionette      DEBUG   0 <- [1,444,null,{"value":null}]
1756804675345   webdriver::server       DEBUG   <- 200 OK {"value":null}
1756804675347   webdriver::server       DEBUG   -> POST /session/21e90390-973c-4d17-9391-5dde18ed91a0/elements {
  "value": "\u002f\u002fdiv[contains(@class, 'bottom-sticker ... \u002f\u002fdiv[contains(@class, 'bottom-sticker-inner')]\u002f\u002fbutton[contains(@name, 'Submit')]",
  "using": "xpath"
}
1756804675347   Marionette      DEBUG   0 -> [0,445,"WebDriver:FindElements",{"using":"xpath","value":"//div[contains(@class, 'bottom-sticker-inner')]//input[@type='submit'] | //div[contains(@class, 'bottom-sticker-inner')]//button[contains(@name, 'Submit')]"}]
1756804675349   Marionette      DEBUG   0 <- [1,445,null,[{"element-6066-11e4-a52e-4f735466cecf":"01e90a31-fb5c-44b1-a215-fad69fee4fc4"}]]
1756804675349   webdriver::server       DEBUG   <- 200 OK {"value":[{"element-6066-11e4-a52e-4f735466cecf":"01e90a31-fb5c-44b1-a215-fad69fee4fc4"}]}
1756804675351   webdriver::server       DEBUG   -> POST /session/21e90390-973c-4d17-9391-5dde18ed91a0/execute/sync {
  "script": "\u002f* isDisplayed *\u002freturn (function ... guments);",
  "args": [
    {
      "element-6066-11e4-a52e-4f735466cecf": "01e90a31-fb5c-44b1-a215-fad69fee4fc4"
    }
  ]
}
1756804675352   Marionette      DEBUG   0 -> [0,446,"WebDriver:ExecuteScript",{"args":[{"element-6066-11e4-a52e-4f735466cecf":"01e90a31-fb5c-44b1-a215-fad69fee4fc4"}],"script":"/* isDisplayed */return (function(){return (function(){var g=this||self;\nfunction aa(a){var b=typeof a;if(\"object\"==b)if(a){i ... Y[Z]=Ta;; return this.se_exportedFunctionSymbol.apply(null,arguments);}).apply(window, arguments);}\n).apply(null, arguments);"}]
1756804675355   Marionette      DEBUG   0 <- [1,446,null,{"value":true}]
1756804675355   webdriver::server       DEBUG   <- 200 OK {"value":true}
1756804675357   webdriver::server       DEBUG   -> POST /session/21e90390-973c-4d17-9391-5dde18ed91a0/element/01e90a31-fb5c-44b1-a215-fad69fee4fc4/click {
  "id": "01e90a31-fb5c-44b1-a215-fad69fee4fc4"
}
1756804675357   Marionette      DEBUG   0 -> [0,447,"WebDriver:ElementClick",{"id":"01e90a31-fb5c-44b1-a215-fad69fee4fc4"}]
1756804675863   RemoteAgent     WARN    TimedPromise timed out after 500 ms: stacktrace:

just incase I also reran with the nightly build and the following change which removes our setting of the scrollBehaviour

diff --git a/src/main/resources/org/jenkinsci/test/acceptance/selenium/disable-sticky-elements.js b/src/main/resources/org/jenkinsci/test/acceptance/selenium/disable-sticky-elements.js
index 525c2f3f..b979aab9 100644
--- a/src/main/resources/org/jenkinsci/test/acceptance/selenium/disable-sticky-elements.js
+++ b/src/main/resources/org/jenkinsci/test/acceptance/selenium/disable-sticky-elements.js
@@ -1,5 +1,5 @@
 // Disable smooth scrolling so scrolling is instantaneous
-document.querySelector("html").style.scrollBehavior = "initial";
+//document.querySelector("html").style.scrollBehavior = "initial";

 // Disable common sticky elements
 const header = document.getElementById("page-header");

If I can get you a reproduction requiring just apache maven and the Java development kit would that help?

[jtnord]

I also tried the following local change (also with the nightly) which made no difference.

diff --git a/src/main/resources/org/jenkinsci/test/acceptance/selenium/disable-sticky-elements.js b/src/main/resources/org/jenkinsci/test/acceptance/selenium/disable-sticky-elements.js
index 525c2f3f..6ed86740 100644
--- a/src/main/resources/org/jenkinsci/test/acceptance/selenium/disable-sticky-elements.js
+++ b/src/main/resources/org/jenkinsci/test/acceptance/selenium/disable-sticky-elements.js
@@ -1,5 +1,5 @@
 // Disable smooth scrolling so scrolling is instantaneous
-document.querySelector("html").style.scrollBehavior = "initial";
+document.querySelector("html").style.scrollBehavior = "instant";

 // Disable common sticky elements
 const header = document.getElementById("page-header");

[jtnord]

another test, I ran firefox (nightly) maximized and the zoom set to 30% so that everything fits in the page and no scrolling is needed at all. I still observe the same timeout.

[jtnord]

ok, I have what I think is a slimmed down reproducer and I think this is a bug in firefox somewhere.
(although I am not 100% sure this is the same issue as it also fails in chrome, which we do not see this issue with)

https://github.com/jtnord/selenium_firefox_click can be used with maven and java but I can also use these files manually to reproduce.

• save https://github.com/jtnord/selenium_firefox_click/blob/3e32e7e6c252e18e5986de61090b0a9fec37f6d4/src/test/resources/simple_page.html locally
• open that page in firefox
• tab to the text input
• enter "anything goes"
• with the mouse click on the "Save" button

Expected results an alert is shown saying the "Save button clicked at coordinates: ..."

Actual results an alert is shown saying "click went to different component.."

you can get the expected results if when doing the click you mousedown on the save button, track the pointer to the new location and then mouse-up.

update: the current behaviour is I think conformant to https://www.w3.org/TR/webdriver2/#element-click, but this leaves you in a sticky place as things would work if you do not disable sticky elements (as the buttons won't jump) however this makes webdriver really combersome as you need to implement custom scrolling before every interaction to ensure that the element is not covered by the sticky element in the viewport.
However as the click isn't delivered to the element I would expect an exception, not a timeout.