Markus_petrux:

I'm following up the conversation started here:
http://hojtsy.hu/blog/2009-jun-17/two-alternatives-d7ux-overlay-implemen...

I'm not talking about page load times or anything like that. I'm talking about the relative UX performance of in-document dialogs like Popups API and iframe dialogs like Modal Frames. I do not think these are very significant differences, but I thought I'd document the difference here.

When modal frame opens an iframe dialog in safari and firefox on mac, I can drag the title bar of the dialog around on the screen, but the iframe contents of the dialog are always a few steps behind the dialog "chrome."

When popups API or any other dialog javascript simply adds new DOM elements to the current document, the dialog chrome and the dialog contents are in perfect sync as I drag the dialog around the window and resize it.

I am not an expert on browser memory usage or anything remotely relevant to what's actually happening when the browser adds more HTML to an existing document vs. creates a new HTML document. "Common sense" tells me that iframes are going to require resources similar to opening a new browser window or a new tab—it's a new document object either way—while non-iframe dialogs simply will not.

Comments

markus_petrux’s picture

markus_petrux commented

Thank you very much for the input. :)

Unfortunately, I don't Macs at hand, so I can't tell. :(

There would be a possible workaround here, I think. But we are somehow limited by the features of jQuery UI Dialog. The idea is that we could override the draggable implementation in UI Dialog by another one that uses a helper DOM element to draw the box while it is being dragged around. The problem with this method would come if/when the draggable implementation in UI Dialog changes in a way that breaks our own.

Well, in fact my implementation of UI Dialog already overrides a few internals (to manage tabindex for elements within the iframe, to check for escape key and adjust close button features), so touching the draggable options here would be another one...

Anonymous’s picture

Anonymous (not verified) commented

I really do not think this is a serious issue. I simply wanted to document it for you, because there were questions.

The simplicity and clarity of the code is more important than providing a 110% perfect UX. It's already 99.9% perfect. See if other people raise the issue before you put any work into it?

markus_petrux’s picture

markus_petrux commented
Category: support » feature
Status: Active » Postponed

Switching this one to "feature request", but postponed until we can find a method to override the draggable implementation in UI Dialog by another one that uses a helper DOM element to draw the box while it is being dragged around. I would be happy to do it, even if that means an update in the jQuery UI inners breaks our own. I guess we can then review our implementation.

corey.aufang’s picture

corey.aufang commented

Draggable in jQueryUI 1.7 has the ability to have a custom helper object http://jqueryui.com/demos/draggable/#visual-feedback

I can't find documentation specifying that this functionality is available in 1.6 so this most likely would require using 1.7, which needs jQuery 1.3 .

markus_petrux’s picture

markus_petrux commented

Last time I checked when working on this module, the problem was that jQuery UI Dialog was implementing its own draggable object, and there was not way to override it.

Now, looking at the docs:

http://jqueryui.com/demos/dialog/

All you can do is draggable:true/false.

But maybe it is now possible to simple use draggable:false for the dialog options, and then implement our own draggable object using the helper element. "Show window content while dragging" would have to be an option in modal frame api, parent.js, the open() method, default to yes (backward compatibility with existing implementations).

markus_petrux’s picture

markus_petrux commented
Status: Postponed » Needs review

I think I have found a way to enhance a little the drag'n'drop operation of the dialog. We can attach dragStart and dragStop callbacks through the dialog options, and this allows us to hide the contents of the dialog, so it probably redraws faster while dragging.

I have just committed a change to parent.js to make it easy to extend jQuery UI dialog options. This should be available with the next development snapshot.

If someone wants to try... once you have the latest dev snapshot, please apply the following mini-patch to parent.js:

+  // Hide the contents of the dialog while dragging?
+  if (self.options.draggable) {
+    dialogOptions.dragStart = function() {
+      self.iframe.$container.hide();
+    };
+    dialogOptions.dragStop = function() {
+      self.iframe.$container.show('fast');
+    };
+  }

   self.iframe.$container.dialog(dialogOptions);

Works/looks better?

markus_petrux’s picture

markus_petrux commented
Status: Needs review » Fixed

Committed #6 to CVS.

http://drupal.org/cvs?commit=265290

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.