There are a few problems with your suggested proposal. First, it
suffers from the same problem as the current implementation. The real
problem is that we have to calculate whether the element being used is
in the top-most dialog. Also, putting handlers on the overlay
wouldn't do anything since the elements that can't be used are not
children of the overlay. The second problem is that you can't have
just one overlay for all modal dialogs because if you have two modal
dialogs open at the same time, you should only have access to one of
them.
On Sep 23, 4:20 pm, Steve Sims <[EMAIL PROTECTED]> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
