Ticket #3300 (new defect)

Opened 2 years ago

Last modified 4 months ago

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

Reported by: guest Owned by: bill
Priority: normal Milestone: 1.4
Component: Dijit Version: 0.9
Severity: normal Keywords: dijit, dialog, widget, form, parent
Cc: tk

Description (last modified by bill) (diff)

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. Also 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

Changed 2 years ago by bill

  • description modified (diff)
  • summary changed from Widget parent element as an optional attribute to Dialog, Tooltip: problems because they are moved to document.body

Changed 2 years ago by bill

  • milestone changed from 0.9beta to 1.0

Changed 23 months ago by bill

  • milestone changed from 1.0 to 2.0

Changed 20 months ago by bill

  • milestone changed from 2.0 to 1.1

Changed 17 months 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.

Changed 17 months ago by bill

  • milestone changed from 1.1 to 1.3

Changed 8 months ago by bill

  • description modified (diff)
  • milestone changed from 1.3 to future

Changed 4 months 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.

Changed 4 months ago by bill

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

Changed 4 months ago by bill

  • milestone changed from future to 1.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.

Changed 4 months 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 :)

Changed 4 months ago by bill

  • severity changed from minor to normal

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.

Note: See TracTickets for help on using tickets.