Skip to main content

Search and Top Navigation

#10739 closed bug (fixed)

Opened January 02, 2015 11:23AM UTC

Closed March 26, 2015 11:35AM UTC

Last modified March 26, 2015 11:40AM UTC

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 ;-)

Attachments (0)
Change History (8)

Changed January 02, 2015 11:26AM UTC by rden comment:1

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

Changed January 02, 2015 03:37PM UTC by tj.vantoll comment:2

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.

Changed January 02, 2015 04:08PM UTC by rden comment:3

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.

Changed January 05, 2015 05:49PM UTC by scottgonzalez comment:4

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.

Changed March 23, 2015 11:13PM UTC by scottgonzalez comment:5

Changed March 26, 2015 11:35AM UTC by Scott González comment:6

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

Changed March 26, 2015 11:35AM UTC by Scott González comment:7

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

Ref #10739

Ref gh-1517

Changeset: dc6703756d388b1f49be0637473a8d55b5ce9270

Changed March 26, 2015 11:40AM UTC by scottgonzalez comment:8

milestone: none1.12.0