Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#10739 closed bug (fixed)

Tooltip: Does not display in foreground when used in an html5 <dialog> element

Reported by: rden Owned by:
Priority: minor Milestone: 1.12.0
Component: ui.tooltip Version: 1.11.2
Keywords: Cc:
Blocked by: Blocking:

Description

Tooltips does not display in the foreground when used in an Html5 <dialog> element opened with the .showModal() method.
The issue does not appear if the <dialog> is opened using the .show() method.

I don't know if this is an acceptable bug because <dialog> is still in draft mode (and only supported in a few browsers for now) but I think it will be widely used in the near future.
I will try to find a workaround for now. I think it would help if you could provide a way to specify where to append the tooltip container in the DOM (like the 'appendTo' option of the autocomplete widget). Thanks for your great work and happy new year ;-)

Change History (8)

comment:1 Changed 3 years ago by rden

Complete jsFiddle test case: http://jsfiddle.net/6uhhL1q9/1/

comment:2 Changed 3 years ago by tj.vantoll

This is an interesting one. I verified that you can't make an element that resides outside of a <dialog> appear on top of its overlay (::backdrop). It's not possible to z-index trump it. I don't think it's unreasonable to create an appendTo option for the tooltip widget, but I'll let other give their thoughts.

Nevertheless, this use case is trickier than just that. I wrote a hacky extension that appends tooltips to the <dialog> element directly (http://jsfiddle.net/6uhhL1q9/3/), which works, but the positioning logic is screwed up. It seems that some the spec's “magical alignment” might be at odds with our position utility. Someone would have to dig deeper to get to the bottom of that problem.

comment:3 Changed 3 years ago by rden

Yes, I came to the same conclusion with an element outside of the <dialog>.

As a temporary workaround, I defined an open callback to move and reposition the tooltip (http://jsfiddle.net/6uhhL1q9/4/). But if you have a better way please let me know.

comment:4 Changed 3 years ago by Scott González

Status: newopen

We can use the appendTo logic from other widgets, even without introducing the appendTo option, and then adjust that to find dialog in addition to .ui-front from DOM traversal. The only issue is that dialogs try to contain their content, so the width of the tooltip will adjust by appending it to the dialog. This is a bit awkward, but I guess that's what happens when entirely new CSS concepts are created.

comment:6 Changed 3 years ago by Scott González

Resolution: fixed
Status: openclosed

Tooltip: Follow the standard appendTo logic

Even though there's no reason to ever configure the parent element via an appendTo option, following the standard logic is useful for scrollable elements and native dialogs.

Fixes #10739 Closes gh-1517

Changeset: 8cf98798a58afb7197bce0d6ca1c5b658ae04011

comment:7 Changed 3 years ago by Scott González

All: Include native dialogs in appendTo logic (ui-front walking)

Ref #10739 Ref gh-1517

Changeset: dc6703756d388b1f49be0637473a8d55b5ce9270

comment:8 Changed 3 years ago by Scott González

Milestone: none1.12.0
Note: See TracTickets for help on using tickets.