Opened 12 years ago

Closed 4 years ago

#3300 closed defect (patchwelcome)

Dialog, Tooltip: problems because they are moved to document.body

Reported by: guest Owned by: bill
Priority: high Milestone: 1.13
Component: Dijit Version: 0.9
Keywords: dijit, dialog, widget, form, parent Cc: tk
Blocked By: Blocking:

Description (last modified by bill)

Dialog Tooltip contents, and drop downs (popups) are moved from their original position in the DOM tree to be direct children of <body>, thus:

  • causing a problem if you want to have *part* of a form inside a dialog and the rest of the form outside.
  • destroyRecursive() on a Dialog doesn't work
  • causes issues with styling, if the class=tundra tag is not on document.body but on a sub-node.

The reason we move them is that leaving a dialog attached to a sub-node has problems too... if the subnode is a div with limited size and overflow: hidden or overflow: auto, then the Dialog won't be able to display outside the div.

What to do?

Change History (17)

comment:1 Changed 12 years ago by bill

Description: modified (diff)
Summary: Widget parent element as an optional attributeDialog, Tooltip: problems because they are moved to document.body

comment:2 Changed 12 years ago by bill

Milestone: 0.9beta1.0

comment:3 Changed 12 years ago by bill

Milestone: 1.02.0

comment:4 Changed 12 years ago by bill

Milestone: 2.01.1

comment:5 Changed 12 years ago by tk

Cc: tk added

Possibly solution to this problem: tested with Menu yesterday by a user via dojoML

<script type="dojo/connect" method="postCreate">
    this.connect(dijit.getEnclosingWidget(this.domNode.parentNode), 'destroy', 'destroyRecursive');
</script>

Obviously this would be converted to regular JS inside the Menu/Dialogs? postCreate.... but this allows the widgets to watch for their parents destroy function and clean themselves up...

It worked for Menu, havent tested with Dialog.

comment:6 Changed 12 years ago by bill

Milestone: 1.11.3

comment:7 Changed 11 years ago by bill

Description: modified (diff)
Milestone: 1.3future

comment:8 Changed 11 years ago by bill

One approach is to leave the dialog/tooltip where it was originally in the markup, and only move it (or it's contents) to be under <body> when the dialog is displayed.

comment:9 Changed 11 years ago by bill

... and then move the contents back to their original position when the dialog is hidden.

comment:10 Changed 11 years ago by bill

Milestone: future1.4

Another approach is to just leave the dialog where it is... but this only works in cases when:

  1. Dialog.domNode.offsetParent is null or <body>
  2. none of Dialog.domNode's ancestors have a z-index specified. (If an ancestor has a z-index specified it generates a local stacking context which will make the dialog end up behind the DialogUnderlay, see http://www.w3.org/TR/CSS2/visuren.html#q30)

But this seems overly complicated and problematic, especially since when a Dialog is initialized programatically there may be no srcNodeRef at all, so we can't do tracing about it's ancestor DOM nodes.

For 1.4 I'll work on the code to temporarily move the Dialog underneath <body> during the time it's displayed.

comment:11 Changed 11 years ago by thekryz

I accidently added another bug ticket concerning this problem at http://bugs.dojotoolkit.org/ticket/8842

My problem feels more though than "minor". I have to integrate a page using tundra into a given webapp-frame and can't use the body element, because it's used by the frame. Luckily, I can add the class="tundra" to the body at the moment, because the frame doesn't use any Dojo Elements (in whatever theme) at the moment - but this will be likely to change, since it's also still in development. So fixing this would be very appreciated :)

comment:12 Changed 11 years ago by bill

severity: minornormal

Agreed.... just not sure how to fix it. My comments above were related to solving the form-submit problem. As for the styling problem maybe we can call getComputedStyle() at the original position of the dialog, or for a more low-tech solution have a "theme" or "class" parameter to the widget itself that can be applied to a wrapper node for the dialog.

comment:13 Changed 10 years ago by bill

Milestone: 1.4future

comment:14 Changed 5 years ago by bill

#18312 is a duplicate of this ticket.

comment:15 Changed 5 years ago by bill

Description: modified (diff)

comment:16 Changed 4 years ago by dylan

Milestone: future1.12

We could consider this for 1.12. Otherwise we should probably close as patchwelcome.

comment:17 Changed 4 years ago by bill

Resolution: patchwelcome
Status: newclosed

At this point it's not worth changing in the 1.x line.

Note: See TracTickets for help on using tickets.