[🐛 Bug]: [py] javascript_error_handler fails with Firefox due to stackTrace not present in the json object

[qiu-lijie]

What happened?

Trying to use the new BiDi feature to get browser console logs/errors with Firefox. However, with certain types (not sure the exact cause of this) of js error, a stackTrace object is not present in the json passed in callback handler, resulting in a KeyError and ws connection being closed, thus all subsequent logs/errors being lost

After some preliminary analysis, it seems like this line is causing the issue. Monkey patching it to stacktrace=json["stackTrace"] if "stackTrace" in json else {}, solved the issue for me, but I'm not sure what's causing these js errors with no stackTrace and if this issue exist with other browsers etc.

How can we reproduce the issue?

from selenium import webdriver

options = webdriver.FirefoxOptions()
options.enable_bidi = True
# somehow I need this for Firefox to work now, could be a separate issue
options.set_capability("loggingPrefs", None)
options.add_argument("--headless")
service = webdriver.FirefoxService(executable_path="/snap/bin/firefox.geckodriver")
driver = webdriver.Firefox(options=options, service=service)

console_logs = []
driver.script.add_console_message_handler(console_logs.append)
driver.script.add_javascript_error_handler(console_logs.append)

# example website with js error
driver.get('https://www.microsoft.com/en-ca/')
# observer error is not present
console_logs
# and subsequent get to the site result in no logs at all, neither js errors nor console logs

Relevant log output

N/A

Operating System

Ubuntu 24.04.1 (WSL and native)

Selenium version

Python 4.26.1

What are the browser(s) and version(s) where you see this issue?

Firefox 132.0.1 | 131.0.3

What are the browser driver(s) and version(s) where you see this issue?

geckodriver 0.35.0

Are you using Selenium Grid?

no

[github-actions]

@qiu-lijie, thank you for creating this issue. We will troubleshoot it as soon as we can.

---

Info for maintainers

Triage this issue by using labels.

If information is missing, add a helpful comment and then I-issue-template label.

If the issue is a question, add the I-question label.

If the issue is valid but there is no time to troubleshoot it, consider adding the help wanted label.

If the issue requires changes or fixes from an external project (e.g., ChromeDriver, GeckoDriver, MSEdgeDriver, W3C), add the applicable G-* label, and it will provide the correct link and auto-close the issue.

After troubleshooting the issue, please add the R-awaiting answer label.

Thank you!

[navin772]

@qiu-lijie I wasn't able to reproduce this issue in both Chrome and Firefox in macOS, below are the logs that I got:

[ConsoleLogEntry(level='info', text='1DS Initialized..', timestamp=1731309070114, method='log', args=[{'type': 'string', 'value': '1DS Initialized..'}], type_='console'), ConsoleLogEntry(level='info', text='MWF v2.15.1', timestamp=1731309074065, method='log', args=[{'type': 'string', 'value': 'MWF v2.15.1'}], type_='console'), ConsoleLogEntry(level='info', text='displaying component', timestamp=1731309074073, method='log', args=[{'type': 'string', 'value': 'displaying component'}], type_='console')]

Can you confirm if you face this issue in Ubuntu only?

[qiu-lijie]

@navin772 thanks for taking a look. Here is the console_logs I get with the monkey patch applied

[ConsoleLogEntry(level='info', text='1DS Initialized..', timestamp=1731310520412, method='log', args=[{'type': 'string', 'value': '1DS Initialized..'}], type_='console'),
 ConsoleLogEntry(level='info', text='MWF v2.15.1', timestamp=1731310520465, method='log', args=[{'type': 'string', 'value': 'MWF v2.15.1'}], type_='console'),
 ConsoleLogEntry(level='info', text='displaying component', timestamp=1731310520489, method='log', args=[{'type': 'string', 'value': 'displaying component'}], type_='console'),
 JavaScriptLogEntry(level='error', text='The character encoding of the document was not declared, so the encoding was guessed from content. The character encoding needs to be declared in the Content-Type HTTP header, using a meta tag, or using a byte order mark.', timestamp=1731310520516, stacktrace={}, type_='javascript')]

Noticed the very last entry JavaScriptLogEntry, which is not present in your output (and has an empty stacktrace). Keep in mind Microsoft can decide to patch this out any day, so maybe it is not the best example. However, when I tired just throwing an error in js or have some invalid syntax for a standalone example, the stacktrace is present thus not trigging the edge case here.

If you try getting the same page again, you can check if the console_logs is growing, thus inferring if the underlying ws connection is closed