[OP / Toolbar(Button) V2]: Hydration of Header Toolbar Actions

[wvudako]

Describe the bug

Like in the code samples in
https://sap.github.io/ui5-webcomponents-react/v2/?path=/docs/layouts-floorplans-objectpage--docs

we are using a Toolbar V2 to display Actions in the OP Header.

[All Imports] from '@ui5/webcomponents-react';

<ObjectPage...
  titleArea={
    <ObjectPageTitle...
      actionsBar={
        <Toolbar...
          <ToolbarButton

Theoretically by a user, but more consistently by automated tests, it is possible to click the button before the button handler is attached.

Our solution was to retry clicking the button until it actually does something
Our preferred solution would be that the buttons are disabled until the handler is attached

https://www.youtube.com/watch?v=8g7FvoRToGo perfectly describes the status quo
We are using Playwright with Chromium, which clicks the button once its visible and enabled
Because of the flakiness of the issue we are unsure which other components are affected by this, but we believe to have had the same issue using the compat Toolbar with standard Buttons, starting with the upgrade to webcomponents 2.x

Playwright 1.47.2
Webcomponents(-react) 2.4.0, but believed to be since 2.0

Isolated Example

No response

Reproduction steps

Using the codesample, click the button immediately after its visible and enabled

Expected Behaviour

Button is not clickable until click handler is attached

Screenshots or Videos

No response

UI5 Web Components for React Version

2.4.0

UI5 Web Components Version

2.4.0

Browser

Chrome

Operating System

Windows 11

Additional Context

No response

Relevant log output

No response

Organization

No response

Declaration

• I’m not disclosing any internal or sensitive information.

[Lukas742]

Hi @wvudako,
using waitForDefine could help improve this behavior, as it ensures the web component is only mounted once the customElement is defined. Please note that this prop is only added by our wrapper and is not available on the web component itself.
However, since UI5 web components themselves are often asynchronous, there’s still a chance that some events, attributes or properties might not be fully initialized.

That said, we’ve never received complaints about this behavior with real user interactions.

Nevertheless, I’ll forward this issue to the ui5-webcomponents team, as all UI5 web components are developed in their repository.

---

Hi Colleagues,
could you please take over?

[ivoplashkov]

Hello colleagues,

The reporter says that after updating to version 2.0, they encounter an issue where buttons in the Toolbar component can not be clicked before their event handlers are attached.

The proposal is that buttons should remain disabled until their handlers are fully initialized to address this.

Could you please have a look and provide insights on whether this behavior is expected or if adjustments are needed at the framework level?

Thank you in advance!
Best regards,
Ivaylo

[pskelin]

@wvudako can you share your test code please? How are you querying for the button? the ui5-toolbar-button is an abstract element, you can't really click it. We recently switched to cypress, and there we will provide helpers how to trigger actions on abstract elements. You have to find the actual ui5-button that is rendered by the ui5-toolbar-button and click it.

Now the second part - when you say the event handlers are not attached - I understand it as the application event handlers. The component has no way of knowing what handlers are attached, or when they are coming. The way the video explains it, the application has to set them as disabled.

In the end, I would like to understand why exactly this happens. The test is probably clicking something that a real user cannot click and this is what we need to address.