You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Race condition leading to Argument should belong to the same JavaScript world as target object #233
We are occasionally seeing this error come from Ferrum:
Argument should belong to the same JavaScript world as target object
From what I can tell, it may have to do with how cuprite handles finding within elements. If the page navigates in the middle of a find (in between the time when the within is resolved in Ruby to when the find is done) then the crash occurs.
page.within(:css, ".some-class") do
page.find(:css, ".some-other-class")
end
Just started seeing this occurring frequently, but with no obvious changes. We do use within quite a lot as above but it had been fine for months/years...
Intermittent issues like that often manifest themselves on CI due to its slowness. Lower memory ceiling, slower CPU and it fails more often in comparison to flying macbooks
When the page navigated between Cuprite resolving the within element and running the find inside it, Chrome rejected the search with Argument should belong to the same JavaScript world as target object: the element belonged to the previous page. Ferrum raised that as a plain Ferrum::BrowserError, which Capybara doesn't retry, so the test failed immediately. Now it's Ferrum::NodeNotFoundError. Cuprite turns that into ObsoleteNode, and Capybara finds the within element again and retries, the same as when the navigation finishes before the find.
Activity
emilkarl commentedon Feb 6, 2024
Did you solve this?
aaronjensen commentedon Feb 6, 2024
No, we have tended to avoid
withinfor this reason. I haven't looked into it recently as a result.markedmondson commentedon Feb 1, 2025
Just started seeing this occurring frequently, but with no obvious changes. We do use
withinquite a lot as above but it had been fine for months/years...route commentedon Feb 1, 2025
@markedmondson something has changed on the js side maybe?
markedmondson commentedon Feb 3, 2025
@route I don't see anything immediately obvious but that's a good callout.
What's interesting is that it fails in CI (using CircleCI) only and not locally. Also it seems intermittent (so basically the worst kind!).
Edit: Got it - there was a Stimulus controller occasionally raising which seems to have caused this!
route commentedon Feb 4, 2025
Intermittent issues like that often manifest themselves on CI due to its slowness. Lower memory ceiling, slower CPU and it fails more often in comparison to flying macbooks
route commentedon Oct 16, 2026
Fixed in rubycdp/ferrum#647, which ships in the next Ferrum release.
When the page navigated between Cuprite resolving the
withinelement and running thefindinside it, Chrome rejected the search withArgument should belong to the same JavaScript world as target object: the element belonged to the previous page. Ferrum raised that as a plainFerrum::BrowserError, which Capybara doesn't retry, so the test failed immediately. Now it'sFerrum::NodeNotFoundError. Cuprite turns that intoObsoleteNode, and Capybara finds thewithinelement again and retries, the same as when the navigation finishes before thefind.