DropdownItem tooltip not shown when isDisabled

[cben]

Describe the issue. What is the expected and unexpected behavior?
Actions with tooltip prop only show it when the action is enabled. When both isDisabled and tooltip props are given, no tooltip shows.
(My use case is action objects returned from Table with actionResolver, but I see that's all passed to regular Dropdown containing DropdownItem and it also reproduces there, so let's focus on DropdownItem.)

Please provide the steps to reproduce. Feel free to link CodeSandbox or another tool.
https://codesandbox.io/s/crimson-snowflake-k2snz
The 2 enabled actions show tooltips on hover, the 2 disabled ones ignore the tooltip prop.
I'd expect them to show the tooltip in both cases.

Is this a bug or enhancement? If this issue is a bug, is this issue blocking you or is there a work-around?
Bug. I don't know sure if this worked before, but we had code setting tooltips for disabled actions for a long time — to explain to users why the action is not available — and this is preventing users from seeing the explanations.

What is your product and what release version are you targeting?
OpenShift Cluster Manager, code using this is already in production.

[cben]

@elad661 found the cause:

disabled elements in PF have pointer-events: none which means they don't get the hover event that triggers the tooltip.

Indeed, disabling that CSS rule in the browser makes the tooltip appear for all actions.
But is it a safe fix? I updated codesandbox link ^^ to include href / onClick props and the 2 disabled actions are still effectively disabled, but I don't know what other effects it may have 🤷

[cben]

Another approach could be to render a structure similar to <Tooltip ...><Button isDisabled ... /> </Tooltip> which does work — attaching the tooltip to an outer span, with the pf-m-disabled only on inner element.

EDIT: which is exactly what the code tries to do:

patternfly-react/packages/react-core/src/components/Dropdown/InternalDropdownItem.tsx

Lines 193 to 200 in 9866c1a

	const renderWithTooltip = (childNode: React.ReactNode) =>
	tooltip ? (
	<Tooltip content={tooltip} {...tooltipProps}>
	{childNode}
	</Tooltip>
	) : (
	childNode
	);

, but in the end it renders into a single element that's both the tooltip trigger and disabled? I don't understand enough how Tooltip & FindRefWrapper work to debug this...

[cben]

Turns out in OCM we tend to use extra span or div between Tooltip and Button:

    const addUserBtn = (
      <Button onClick={() => { setTimeout(() => openModal('add-user'), 0); }} variant="secondary" className="access-control-add" isDisabled={disabled}>
        Add user
      </Button>
    );
...
          {disabled ? (
            <Tooltip content={tooltipContent}>
              <span>
                {addUserBtn}
              </span>
            </Tooltip>
          )
            : addUserBtn}

With such span, the tooltip shows, without it doesn't. 💡
Note how the span gets aria-describedby="pf-tooltip-..." while the inner button gets pf-m-disabled class:

Arguably, having to do that is silly and error-prone. A direct <Tooltip ...><Button isDisabled ... /> </Tooltip> structure SHOULD work.

So perhaps Tooltip itself should be considered buggy?
Instead of doing things like React.cloneElement(children, { 'aria-describedby': id }) to its child — and using that directly as the Popper trigger element, maybe it should always wrap the child in a span?
Or maybe Popper should be responsible for wrapping?

[cben]

Oh, I should have searched before opening new issue.

• DropdownItem specifically already covered by Support for tooltips on disabled dropdown items (aria-disabled variation) #5826, Tooltips on disabled actions in react-table #5127, tooltip property on disabled DropdownItem does not work #4581.
  isAriaDisabled implemented in feat(Dropdown): Allow for tooltips on aria-disabled items #6038 but screen readers still have issues (Tooltip examples are not accessible on dropdown items. #6109).
• The big picture for other components tracked in Tooltips for disabled elements #1894. Important discussions on accessibility there, especially Tooltips for disabled elements #1894 (comment). I don't know whether <span> workaround above is accessible!