NoSuchElementException in DetachEvent.getUI when detaching components twice #20685
Labels
Comments
|
It's probably way simpler to implement BeforeLeaveObserver in your dialog and just call close() in there. |
|
I haven't thought about that, that would probably work here. But navigation is just one example where the outer component is detached. But there are other scenarios where the outer component is detached without navigation. For example, it could simply be removed from a parent component for whatever reason. Or, it could itself be embedded in an outer dialog, which you can close manually. |
mshabarov
moved this from 🆕 Needs triage
to 🔖 Low Priority (P3)
in Vaadin Flow bugs & maintenance (Vaadin 10+)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description of the bug
Many of our views can open non-modal dialogs. When navigating to another view, these dialogs should be closed. Therefore, these views call
Dialog.closein theironDetachhooks.However, if some component inside the dialog also overrides
onDetachand callsDetachEvent.getUI, this leads toNoSuchElementExceptionwhen the whole browser tab is closed. The reason is that the dialog is detached twice in this case: once explicitely by our view, and once implicitely by Vaadin when detaching the whole component tree. Thus, when detached for the second time, the component has actually already been detached, so you cannot get a UI.Interestingly,
onDetachitself is always only called once at some later point, not insideDialog.close, but the problem does not arise when not callingclose.Expected behavior
Inside an onDetach hook,
DetachEvent.getUIshould never throw. When all components are detached anyway, an additionalDialog.closeshould only affect the order in which detach hooks are called.Minimal reproducible example
You see an exception that looks similar to this:
The outer one depends on the servlet container, which is Jetty in my case. But the cause shows that the exception happens when removing the UI in
requestEnd.On another note, I wonder if such an error shouldn't be passed to
VaadinSession.getErrorHandler. Currently, it simply bubbles up to the servlet container, which apparently simply logs it as a warning. We usually don't enable these loggers, so we didn't know about this exception, even though the issue probably exists for quite some time. I can open a separate issue for this if you like.The main workaround I've found is to avoid calling
dialog.closeif the UI is closing:Versions
The text was updated successfully, but these errors were encountered: