Feature and motivation
The newer Python _bidi layer has no coverage or ergonomic API for the input.fileDialogOpened event, while the older bidi package has both. Anything migrating from one to the other loses that functionality.
The older suite covers the event in three tests:
test_file_dialog_event_handler_multiple — py/test/selenium/webdriver/common/bidi/input_tests.py:370
test_file_dialog_event_handler_unsubscribe — py/test/selenium/webdriver/common/bidi/input_tests.py:405
test_multiple_file_dialog_handlers — py/test/selenium/webdriver/common/bidi/input_tests.py:779
py/test/selenium/webdriver/common/_bidi/input_tests.py has none — a grep for file_dialog in that file returns nothing.
The convenience helpers are in the same position. add_file_dialog_handler / remove_file_dialog_handler are injected by the older generator's enhancement manifest:
https://github.com/SeleniumHQ/selenium/blob/trunk/py/private/bidi_enhancements_manifest.py#L1854-L1872
That manifest is consumed by generate_bidi.py, which emits selenium/webdriver/common/bidi/. The _bidi layer is generated by generate_bidi_protocol.py and is raw protocol only, so it has no equivalent subscribe/unsubscribe ergonomics for this event.
Noticed while reviewing the Python BiDi input code for upload coverage (#18007), which touches the _bidi input suite.
Things to consider
- Whether
_bidi is intended to stay raw protocol with ergonomics layered above it, or whether it should carry the handler helpers itself. That answer decides whether this is "port the manifest enhancement" or "add the helpers at whatever layer replaces it".
- The
FileDialogInfo dataclass and its from_json are also manifest-provided (same file, just above the methods), so the event's deserialisation needs a home too, not just the subscribe helpers.
- Once there is somewhere to hang them, the three tests above port over fairly mechanically.
- Worth checking whether any other manifest enhancements are in the same position, so this is fixed as a class rather than one event at a time.
Feature and motivation
The newer Python
_bidilayer has no coverage or ergonomic API for theinput.fileDialogOpenedevent, while the olderbidipackage has both. Anything migrating from one to the other loses that functionality.The older suite covers the event in three tests:
test_file_dialog_event_handler_multiple—py/test/selenium/webdriver/common/bidi/input_tests.py:370test_file_dialog_event_handler_unsubscribe—py/test/selenium/webdriver/common/bidi/input_tests.py:405test_multiple_file_dialog_handlers—py/test/selenium/webdriver/common/bidi/input_tests.py:779py/test/selenium/webdriver/common/_bidi/input_tests.pyhas none — agrepforfile_dialogin that file returns nothing.The convenience helpers are in the same position.
add_file_dialog_handler/remove_file_dialog_handlerare injected by the older generator's enhancement manifest:https://github.com/SeleniumHQ/selenium/blob/trunk/py/private/bidi_enhancements_manifest.py#L1854-L1872
That manifest is consumed by
generate_bidi.py, which emitsselenium/webdriver/common/bidi/. The_bidilayer is generated bygenerate_bidi_protocol.pyand is raw protocol only, so it has no equivalent subscribe/unsubscribe ergonomics for this event.Noticed while reviewing the Python BiDi input code for upload coverage (#18007), which touches the
_bidiinput suite.Things to consider
_bidiis intended to stay raw protocol with ergonomics layered above it, or whether it should carry the handler helpers itself. That answer decides whether this is "port the manifest enhancement" or "add the helpers at whatever layer replaces it".FileDialogInfodataclass and itsfrom_jsonare also manifest-provided (same file, just above the methods), so the event's deserialisation needs a home too, not just the subscribe helpers.