Fixes#10427.
In d51ec00ce1, the target was changed from
'[data-field] > .handsontable' to '.handsontable', as the .handsontable
element is no longer a direct descendant of the [data-field] element.
However, this means that we're marking ALL elements with .handsontable
as resize targets, which is not ideal as pretty much all elements
generated by Handsontable have that class.
The original logic would presumably only select the outermost element
with the .handsontable class, which is equal to the element with the
foo-handsontable-container ID (we store this in the containerId
variable).
Frankly, removing this selector outright would also fix the issue. That
said, let's keep this selector in anyway, to match the logic in older
releases.
Regression in 933a730928 introduced in 4.2.
This causes the discrepancy seen between 4.1 vs 4.2 (and later). In 4.2,
this check was broken, which means the event handler never gets added.
The combination of the event handler and the incorrect selector (fixed
in the next commit) would resize all Handsontable elements, resulting in
the bug where the table cannot be interacted with.
The commit b9f8a6b6c0 fixed another cause
of the issue, which was calling `resizeWidth(getWidth())`. The
getWidth() function should only be used to set the Handsontable's
settings, while resizeWidth should be called with '100%' as done within
the event handler.
However, seeing that the event listener is not even attached in 4.2
onwards, dispatching the resize event might not be necessary and
Handsontable might already handle this correctly. That said, let's
avoid making other changes that could potentially cause issues.
With this commit, the bug should reappear in 4.2 and later releases,
making it consistent with 4.1. The bug will be fixed in the next commit.
Enable / disable the open-modal button on reaching the limit, as we do for InlinePanel's standard add button; and when handling the response from the modal, stop adding new items when max_num is reached
We keep data-chooser-url in the HTML output, and use it as a fallback in the JS - for backwards compatibility with existing BaseChooser subclasses that don't pass an options dict (such as AdminTaskChooser, which overrides render_js_init)
At this point we've been turning the 'opts' dict from a private API specific to PageChooser, that more or less transparently passes options on to the modal as URL query parameters, into a convention shared across all chooser widgets where the question of "will this option become a URL parameter" is an internal implementation detail. Since this is notionally a bundle of JS variables rather than a bundle of URL params, we should take this opportunity to consistently adopt camel case, before this pattern becomes widespread in third-party code and ends up as a mishmash of camel-case and snake-case.
The old signature is still accepted for backwards compatibility.
This then matches the signature of the other chooser widget JS classes, allowing PageChooserFactory to extend the generic ChooserFactory.
This will allow us to refactor it, including adding class-level references to window.PageChooser and window.PageChooserModal as necessary, without dealing with the possibility of telepath/widgets.js being imported before the includes that define those.
This matches the implementation in components/ChooserWidget. This change breaks the tests that pass a jQuery collection object rather than a DOM element, but that was never valid in the first place as per https://docs.wagtail.org/en/stable/reference/streamfield/widget_api.html - fix the tests accordingly.
Previously, anything invoking the chooser modal needed to make its own call to ModalWorkflow, which meant it needed to import the corresponding 'onloadHandlers' dict, know the appropriate chosen response identifier to listen to, and know how to modify the chooser URL to pass parameters (if applicable). This would mean a lot of duplicated logic if there were multiple places where the modal is invoked.
Here we introduce a ChooserModal base class which encapsulates those details - a caller just needs to instantiate it with the base URL, and call `open` on it to open the modal (passing an options dict and a response callback).
- Revise 'redirect' from a string to a 'continue' boolean that defaults to false
- Use 'continue=true' for cases where we do not want to create a next param on submit that takes the user back to the current page
- Fixes#9815
LB Johnston