adjustButtons not fired

[dimyy]

Version: 8.2.2

https://github.com/espocrm/espocrm/blob/268354f3c610d57609a12ef4ca5f30d489f98cd7/client/src/views/modals/detail.js#L593

Steps:
1. show smallDetail dialog
2. edit in smallEdit dialog
3. close smallEdit dialog

Causes difficulties when using third-party libraries that base their rendering on the visibility of elements. At the moment, there are no events like afterShow and the only safe method is to override adjustButtons.

[dimyy]

afterRender does not help - in the case of a dialog, it is called before the elements become visible

[yuri]

Could not reproduce.

[dimyy]

I'll try to explain in more detail

1. when a small detail view is called through an action in the list view, then adjustButtons is called several times and the key call occurs here - https://github.com/espocrm/espocrm/b.../modal.js#L384 after this.dialog.show();

2. When a small detail view is appear after small edit view is closed "after:render" is not fired and adjustButtons() in that place is not fired. (https://github.com/espocrm/espocrm/b.../modal.js#L375)

[dimyy]

The key point is that in this place (https://github.com/espocrm/espocrm/b.../modal.js#L375) the adjustButtons call occurs in a visible dialogue, and all the rest - in a hidden one. And accordingly, it is impossible to calculate the actual parameters of the visible view area


reproduced on any list view.

Set breakpoint at devtool on https://github.com/espocrm/espocrm/b.../modal.js#L384 and make 3 steps:
1. Open any entity from list (debugger stoped on this point)
2. Hit edit button (another stop)
3. Close edit form, doesn't matter via save or cancel : no stop in debugger

[yuri]

But where is the bug? It's not called. But should it be? Is it possible to reproduce the problem that buttons are not rounded without any manipulation with DOM?

[yuri]

The problem that adjustButtons was called for the hidden modal while the edit modal was displayed? If yes, what invoked this call?

[dimyy]

The problem is that the custom function "A" needs to be called after the div (in this case SmallDetailView) becomes visible.

The div is made visible by dialog.show() and the only function that is called after dialog.show is adjustButtons .

Thus, in order to make safe customization, calll of the function "A' must be thrown into custom adjustButtons.

But in the case when smalldetail is shown after smalledit calling adjustButtons after dialog.show() does not happen. Also after:render for smalldetail not fired.

adjustButtons after smallEdit invoked at showButton and at showActionItem

[yuri]

Ok. This is not a bug and a completely different problem that it appeared to me initially.

[dimyy]

I apologize for misleading you and not being able to convey the idea. Although the lack of after:render after the reappearance and change of data can be considered a bug.

[yuri]

You can just add another this.on('after:render', () => {}); in the setup method and it will be called after the modal is rendered. Does not solve the problem, but completely removes "adjustButtons" out of the question.

[yuri]

One may consider as a bug almost everything. There's no render, the modal is not rendered. The class 'hidden' is added and removed.

[yuri]

As your code or lib relies on the DOM, which can be considered as bit dirty. you can come up with some dirty solution that fires a code whenever the class is removed.

[yuri]

https://developer.mozilla.org/en-US/docs/Web/API/MutationObserver

[dimyy]

I looked in the direction of the MutationObserver, but it looks too much like crutches.
I suspect that this is a more beautiful option - it may be useful in the future

At the same view where adjustButtons customization

        actionEdit: function() {
            return Dep.prototype.actionEdit.call(this).then((view)=>{
                this.listenToOnce(view, 'remove', () => {
                    this.adjustButtons();
                });
            });
        }​

[yuri]

To be consistent this, we would need to add many such crutches for every possible modal view. Including sub-sub-sub views. It's not good for the product. We should not add code for every peculiar use case. It's not good.

[dimyy]

You are absolutely right