Hi gang,
I ran into this very problem earlier today. I'd just written
something using a modal dialog which contained a textarea for input,
and in my testing (using Safari) it worked fine. It also seemed to be
OK in Firefox... When my colleague tested in IE7 the textarea input
was intolerably slow, and he found Firefox to be slightly sluggish as
well on his machine.
Anyway, I eventually discovered this thread, and am now better
educated. Sure enough, when I try modal dialogs on very complex pages
(and I have a few) on Firefox that was slow too.
I'm very puzzled as to why ui.dialog.js binds to everything that could
receive input to enforce modality. It feels wrong to me. I'd have
thought that one could trap events at the overlay and/or at the window
level, and stop them bubbling back up through the DOM, if one ensures
that the overlay is a direct child of body, and the dialog a direct
child of the overlay. I'd have thought this could be made to work for
multiple (modal) dialogs too over a single overlay.
I was going to implement my own overlay... but I'm lazy. :) So, thank
you Dave for your patch - this has solved the problem for me very
nicely.
Steve
On Aug 6, 8:15 pm, Fontzter <[EMAIL PROTECTED]> wrote:
> Hey Scott,
>
> I think I've narrowed the problem down to the maximum dialog z-index
> calculation. Commenting that out took care of the issue for me. I
> just replaced lines 371-387:
>
> // - there are no modal dialogs
> // - there are modal dialogs, but we are in front of the topmost
> modal
> var allow = false;
> var $dialog = $(this).parents('.ui-dialog');
> if ($dialog.length) {
> var $overlays = $('.ui-dialog-overlay');
> if ($overlays.length) {
> var maxZ = parseInt($overlays.css('z-index'), 10);
> $overlays.each(function() {
> maxZ = Math.max(maxZ,
> parseInt($(this).css('z-index'), 10));
> });
> allow = parseInt($dialog.css('z-index'), 10) > maxZ;
> } else {
> allow = true;
> }
> }
> return allow;
>
> with this:
> return ($(this).parents('.ui-dialog').size() > 0);
>
> I know that this will (wrongly) allow events from a dialog below the
> topmost modal, but I don't have that scenario, nor the expertise with
> the dialog to remedy it. It seems that if there were a way to discern
> which dialog was active/topmost or to put the maxZ in an expando or
> something, the slowness could be fixed.
>
> Anyway, Hth.
>
> Dave
>
> On Aug 6, 9:30 am, Scott González <[EMAIL PROTECTED]> wrote:
>
> > Hey snobo,
>
> > I haven't forgotten about your problem. I still have your emails in
> > my inbox for reference and access to your intranet.
>
> > It is confusing that the problem is seemingly unrelated to the event
> > bindings, so I'll probably just have to go through ripping out
> > functionality from modal dialogs until I can track down what is
> > actually causing the slowness. I'll try to set aside some more time
> > for this in the next week or so.
>
> > On Aug 5, 2:54 pm, snobo <[EMAIL PROTECTED]> wrote:
>
> > > Hi Scott,
>
> > > if you still remember, this is exactly the problem I have submitted
> > > some time ago (both here and as a ticket), and even gave you the
> > > access to our intranet for a test case... And it still remains the
> > > problem, although I managed to diminish it a bit by dynamically
> > > purging up some DOM parts hidden by CSS and not in use at the moment.
> > > What puzzles me, is why a big table, which has NO inputs or links,
> > > slows down the form input? If it was "The modal plugin binding key and
> > > mouse events to all links and inputs, to cancel them (to enforce the
> > > modal)" as Richard says above, there would be a slowdown only if that
> > > big demo table had hundreds of inputs or links... Or am I missing
> > > smth?
>
> > > That was also my case: I have a set of tabs, with cache enabled. One
> > > of the tabs contains a very long table (again, no links/inputs). I go
> > > to another tab (so the former one becomes hidden by display:none) and
> > > open a dialog, where I experience a slowdown like 10 seconds between
> > > keystrokes in IE7. But! When I kill the contents of that hidden tab
> > > panel, the dialog more or less "unfreezes". Which probably means, that
> > > Modal Dialog attaches (?) some events on all DOM elements? This is
> > > already puzzling, but even if it's necessary, maybe it should do so
> > > only for visible elements?
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"jQuery UI" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/jquery-ui?hl=en
-~----------~----~----~----~------~----~------~--~---
