[jQuery] Re: (Jquery Validate) Keep getting an error in IE8
I stumbled upon the same shit, and this is how IE8 reacts on OPTION
tags without value specified (like, optionblahblah/option). Until
jQuery is fixed to support it (and in my case I must stick to old
version 1.2.6, so fix is impossible) the workaround is to always use
option value=blahblahblahblah/option notation, if possible. Of
course it's not a generic solution, but might help someone.
On Nov 23, 4:55 pm, djseng dave.s...@gmail.com wrote:
I'm getting this same error. Does anyone have a patch for it?
On Nov 7, 9:31 pm, chobo2 howser_...@hotmail.com wrote:
Hi
I don't know what is going but my jqueryvalidateplugin(1.5.5) is not
working and I am not sure for how long since I do most of my testing
on firefox.
The problem is this I go to one of my forms that jqueryvalidateon it
and hit my create button my validation kicks in as it should and
does this right in all browsers includingIE8. Now where it does not
work is when I do this.
I choose the first dropdown list and choose something. Then hit
create now all validation errors should show up expect the one for
the first dropdown box.
It does this in all browsers except in IE 8. I get this
Webpage error details
User Agent: Mozilla/4.0 (compatible;
MSIE 8.0; Windows NT 6.1; Win64; x64;
Trident/4.0; .NET CLR 2.0.50727;
SLCC2; .NET CLR 3.5.30729; .NET CLR
3.0.30729; Media Center PC 6.0; Tablet PC 2.0) Timestamp: Sun, 8 Nov 2009
03:26:08 UTC
Message: Object required Line: 890
Char: 5 Code: 0 URI:
http://localhost:3668/Scripts/Plugins-Development/jquery.validate.js
This is what is on line 890
return options.length 0 ( element.type == select-multiple
|| ($.browser.msie !(options[0].attributes['value'].specified) ?
options[0].text : options[0].value).length 0);
This like the whole method block.
methods: {
//http://docs.jquery.com/Plugins/Validation/Methods/required
required: function(value, element, param) {
// check if dependency is met
if ( !this.depend(param, element) )
return dependency-mismatch;
switch( element.nodeName.toLowerCase() ) {
case 'select':
var options = $(option:selected, element);
return options.length 0 ( element.type
== select-multiple
|| ($.browser.msie !(options[0].attributes['value'].specified) ?
options[0].text : options[0].value).length 0);
case 'input':
if ( this.checkable(element) )
return this.getLength(value,
element) 0;
default:
return $.trim(value).length 0;
}
},
Not sure what is going on.
[jQuery] Re: BlockUI overlapping issue with element negative margin
Hi Mike, I just found out that exactly this behavior (changing the display from static to relative) messes up my page too, only in IE: a known issue with the IE's z-index stacks (well described at http://mahzeh.org/?p=19). Could you consider, if possible, reverting the blocking element's display attribute back to static after unblocking? Thanks a ton in advance, snobo On Jun 19, 7:36 pm, Mike Alsup mal...@gmail.com wrote: Yes it is modified, because the div itself (not the blocking overlay) comes over the ul/li elements when calling blockUI on it. To clarify, the zIndex of the div is not modified. The only thing modified on the blocked element (the div in your case) is the position style, and only if it is currently 'static'. The position is set the 'relative' so that the overlay can be absolutely positioned within. Mike
[jQuery] [validate] invalidHandler is called before the errors are shown, maybe better vice versa?
Hi Jörn,
incredibly awesome plugin you've made, thanks a million! Started to
explore and using it, and stumbled onto situation.
In my invalidHandler, I'm trying to access the first input which is
marked as invalid (in order to ensure that it is visible - my form is
split on tabs, and I need to select a proper tab if the currently
selected one has no invalid fields). I'm doing this via $
('#myform :input.error:first') query, but there is a problem: in your
code, you mark fields as invalid AFTER the invalidHandler call (line
302):
if (!this.valid()) $(this.currentForm).triggerHandler(invalid-form,
[this]);
this.showErrors();
So, as a workaround at the moment I simply call showErrors(); in my
invalidHandler, but maybe - unless you have a special reason for this
- it's better to swap these lines in the jquery.validate.js? That's
actually my $0.02 suggestion.
cheers
[jQuery] Re: [validate] invalidHandler is called before the errors are shown, maybe better vice versa?
Hmm, interesting alternative solution! Thanx, I will consider this.
Well, if you are sure there WILL be issues, let it be, although purely
theoretically for me it seems more logical to have invalidHandler
being run at the moment where errors are shown.
cheers
On Apr 17, 1:55 pm, Jörn Zaefferer joern.zaeffe...@googlemail.com
wrote:
The suggestion makes sense, though there are probably also cases where
the current order makes more sense, and changing it will cause other
issues.
Take a look at this tabs demo for an alternative
implementation:http://jquery.bassistance.de/validate/demo/tabs/
Jörn
On Fri, Apr 17, 2009 at 12:26 PM, snobo g...@riga.ahlers.com wrote:
Hi Jörn,
incredibly awesome plugin you've made, thanks a million! Started to
explore and using it, and stumbled onto situation.
In my invalidHandler, I'm trying to access the first input which is
marked as invalid (in order to ensure that it is visible - my form is
split on tabs, and I need to select a proper tab if the currently
selected one has no invalid fields). I'm doing this via $
('#myform :input.error:first') query, but there is a problem: in your
code, you mark fields as invalid AFTER the invalidHandler call (line
302):
if (!this.valid()) $(this.currentForm).triggerHandler(invalid-form,
[this]);
this.showErrors();
So, as a workaround at the moment I simply call showErrors(); in my
invalidHandler, but maybe - unless you have a special reason for this
- it's better to swap these lines in the jquery.validate.js? That's
actually my $0.02 suggestion.
cheers
[jQuery] [validate] remote vs depends
I've been trying to use remote method coupled with depends, like this:
remote: {
depends: function(element) { element.value = $.trim(element.value);
return element.defaultValue != element.value; },
url: 'my.php',
type: 'post',
data: { action: 'check_user_name' }
}
and this doesn't work, because the whole remote parameter array gets
overwritten with the result of evaluating my 'depends' function (so
instead of array it becomes a scalar, true or false). Therefore in
case of false the AJAX call doesn't happen, and in case of true an
error occurs (because there's no url, no type, and no data anymore).
I assume remote and depends are incompatible, is it correct? If yes,
is there a workaround for this?
TIA
cheers
[jQuery] Re: [validate] remote vs depends
well, I don't see how required can help me... what I want is to make a
remote call/check ONLY under certain circumstances. Plus, this field
is constantly-required already anyway...
actually, now I think there might be various workarounds, e.g.
creating a custom method, which would check the condition first and
then making an AJAX call manually only if needed...
On Apr 17, 4:16 pm, Jörn Zaefferer joern.zaeffe...@googlemail.com
wrote:
This is indeed a bug, in this case something never tested for.
Is using required: function() {} together with remote an option?
Jörn
On Fri, Apr 17, 2009 at 3:03 PM, snobo g...@riga.ahlers.com wrote:
I've been trying to use remote method coupled with depends, like this:
remote: {
depends: function(element) { element.value = $.trim(element.value);
return element.defaultValue != element.value; },
url: 'my.php',
type: 'post',
data: { action: 'check_user_name' }
}
and this doesn't work, because the whole remote parameter array gets
overwritten with the result of evaluating my 'depends' function (so
instead of array it becomes a scalar, true or false). Therefore in
case of false the AJAX call doesn't happen, and in case of true an
error occurs (because there's no url, no type, and no data anymore).
I assume remote and depends are incompatible, is it correct? If yes,
is there a workaround for this?
TIA
cheers
[jQuery] Re: [validate] remote vs depends
Thanx a ton for the ultra-quick reply help! Worked like a charm, I
did it like this:
rules.UserName = {
xRemote: {
condition: function(element) { element.value = $.trim
(element.value); return element.defaultValue != element.value; },
url: 'myurl.php',
data: { action: 'check_user_name' }
}
}
$.validator.addMethod(xRemote, function(value, element) {
var rule = this.settings.rules[element.name].xRemote;
if (rule.condition $.isFunction(rule.condition) !
rule.condition.call(this,element)) return dependency-mismatch;
return $.validator.methods.remote.apply(this, arguments);
}, $.validator.messages.remote);
is this the correct way to reference the current rule?
On Apr 17, 5:13 pm, Jörn Zaefferer joern.zaeffe...@googlemail.com
wrote:
Ok, that makes it a bit more difficult. For a workaround, try
something like this:
$.validator.addMethod(customRemote, function(value, element) {
if (!remoteRequired(element) {
return dependency-mismatch;
}
return $.validator.methods.remote.apply(this, arguments);
}, $.validator.messages.remote);
The idea is to write a custom method that does the dependency-check.
If it isn't necessary, return a special string to have the plugin skip
the method. Otherwise, delegate to the default remote method to
perform its task.
Let me know if that works for you, might be worthwhile adding to the
docs (until depends/remote is fixed).
Jörn
On Fri, Apr 17, 2009 at 3:34 PM, snobo g...@riga.ahlers.com wrote:
well, I don't see how required can help me... what I want is to make a
remote call/check ONLY under certain circumstances. Plus, this field
is constantly-required already anyway...
actually, now I think there might be various workarounds, e.g.
creating a custom method, which would check the condition first and
then making an AJAX call manually only if needed...
On Apr 17, 4:16 pm, Jörn Zaefferer joern.zaeffe...@googlemail.com
wrote:
This is indeed a bug, in this case something never tested for.
Is using required: function() {} together with remote an option?
Jörn
On Fri, Apr 17, 2009 at 3:03 PM, snobo g...@riga.ahlers.com wrote:
I've been trying to use remote method coupled with depends, like this:
remote: {
depends: function(element) { element.value =
$.trim(element.value);
return element.defaultValue != element.value; },
url: 'my.php',
type: 'post',
data: { action: 'check_user_name' }
}
and this doesn't work, because the whole remote parameter array gets
overwritten with the result of evaluating my 'depends' function (so
instead of array it becomes a scalar, true or false). Therefore in
case of false the AJAX call doesn't happen, and in case of true an
error occurs (because there's no url, no type, and no data anymore).
I assume remote and depends are incompatible, is it correct? If yes,
is there a workaround for this?
TIA
cheers
[jQuery] Re: remote vs depends
huh, only one minor thing... wicked things happen to the error
messages. I specify a message for my input in the validate() call:
messages: {
UserName: {
required: ,
remote: 'User name already exists or invalid'
},
...
}
so, in case the input value is invalid, my custom message is correctly
displayed, but only on blur. On submit, when I click the submit
button, the default message (Please fix this field) is displayed.
How can this be fixed?
On Apr 17, 6:02 pm, snobo g...@riga.ahlers.com wrote:
Thanx a ton for the ultra-quick reply help! Worked like a charm, I
did it like this:
rules.UserName = {
xRemote: {
condition: function(element) { element.value = $.trim
(element.value); return element.defaultValue != element.value; },
url: 'myurl.php',
data: { action: 'check_user_name' }
}
}
$.validator.addMethod(xRemote, function(value, element) {
var rule = this.settings.rules[element.name].xRemote;
if (rule.condition $.isFunction(rule.condition) !
rule.condition.call(this,element)) return dependency-mismatch;
return $.validator.methods.remote.apply(this, arguments);
}, $.validator.messages.remote);
is this the correct way to reference the current rule?
On Apr 17, 5:13 pm, Jörn Zaefferer joern.zaeffe...@googlemail.com
wrote:
Ok, that makes it a bit more difficult. For a workaround, try
something like this:
$.validator.addMethod(customRemote, function(value, element) {
if (!remoteRequired(element) {
return dependency-mismatch;
}
return $.validator.methods.remote.apply(this, arguments);
}, $.validator.messages.remote);
The idea is to write a custom method that does the dependency-check.
If it isn't necessary, return a special string to have the plugin skip
the method. Otherwise, delegate to the default remote method to
perform its task.
Let me know if that works for you, might be worthwhile adding to the
docs (until depends/remote is fixed).
Jörn
On Fri, Apr 17, 2009 at 3:34 PM, snobo g...@riga.ahlers.com wrote:
well, I don't see how required can help me... what I want is to make a
remote call/check ONLY under certain circumstances. Plus, this field
is constantly-required already anyway...
actually, now I think there might be various workarounds, e.g.
creating a custom method, which would check the condition first and
then making an AJAX call manually only if needed...
On Apr 17, 4:16 pm, Jörn Zaefferer joern.zaeffe...@googlemail.com
wrote:
This is indeed a bug, in this case something never tested for.
Is using required: function() {} together with remote an option?
Jörn
On Fri, Apr 17, 2009 at 3:03 PM, snobo g...@riga.ahlers.com wrote:
I've been trying to use remote method coupled with depends, like this:
remote: {
depends: function(element) { element.value =
$.trim(element.value);
return element.defaultValue != element.value; },
url: 'my.php',
type: 'post',
data: { action: 'check_user_name' }
}
and this doesn't work, because the whole remote parameter array gets
overwritten with the result of evaluating my 'depends' function (so
instead of array it becomes a scalar, true or false). Therefore in
case of false the AJAX call doesn't happen, and in case of true an
error occurs (because there's no url, no type, and no data anymore).
I assume remote and depends are incompatible, is it correct? If yes,
is there a workaround for this?
TIA
cheers
[jQuery] jQuery 1.3.2: error in Safari when running a multi-selector query in the context of an element not yet added to DOM
I've stumbled upon a wicked problem, which appears only in 1.3.2
(works ok in 1.3.1, 1.3.0 and 1.2.6), and only in Safari (3.2.2 on
Windows) (works ok in FF2/3, IE6/7, Opera). To cut a long story short,
here's the test case:
http://tmp.ahlers.com/test/safari-132.html
My application employs FlexiGrid, so I've isolated the chunk of code
to a bare minimum that reproduces the error.
var sDiv = document.createElement('div');
sDiv.className = 'sDiv';
$(sDiv).append(div class='sDiv2'Quick Search input type='text'
name='q' / select name='qtype'option selected='selected'
value='port'Port/option/select input type='button'
value='Clear' //div);
$('#output3').append(
$('input[name=q],select[name=qtype]',sDiv).map( function(){
return
this.name } ).get().join(', ')
);
$('#form .bDiv').after(sDiv);
So, the query $('input[name=q],select[name=qtype]',sDiv) crashes
jQuery 1.3.2 on the line #2118:
aRange.selectNode(a);
with the error INVALID_NODE_TYPE_ERR: DOM Range Exception 2. At the
same time, single-selector queries like $('input[name=q]',sDiv) don't
crash. Also, the problem only happens if a context (sDiv) is an
element NOT YET ADDED to DOM.
Seems like quite a hypothetical situation? Nah, as I said I'm using
FlexiGrid and it took me a few hours to track down the reason why my
application no longer works under jQuery 1.3.2 :(
[jQuery] linkSelect - the width of the options container
Hi, 1st of all thanx and kudos to the creators of mighty LinkSelect plugin! I stumbled upon the situation, which seems confusing to me. In my app, I noticed that the LinkSelect used to create the container for its option list which is too wide. I read the docs and found the option fixedWidth. To my bewilderment, it didn't work. I fired the Venkman and analyzed, what's going on... So, the following piece of code takes care of the container width (lines 532-537): // get the width of the anchor link unless inline, then grab width of parent var aw = ($a.css(display).indexOf(inline) -1) ? $a.parent().outerWidth() : $a.outerWidth(); // get the original width of the container var width = options.fixedWidth ? aw : $container.width(); // make sure the width of the drop down is at least as wide as the link if( width aw ) width = aw; in my case, the fragment of DHTML structure (after LinkSelect has already transformed SELECT into A) is: td h5ORIGIN/h5 labelCountry: /label a class=linkselectLink id=_link href=#Select country.../ ainput type=hidden value= id= name=/ labelPort:/label a class=linkselectLink id=_link href=#Select city.../ainput type=hidden value= id= name=/ /td so, while the width the options for each SELECT is only appox 140px, LinkSelect executes the line if( width aw ) width = aw; and takes the WIDTH OF THE CONTAINER (td), which is way bigger - 330px in my case. Needless to say, the container turns to be excessively wide. I worked this around by enclosing my original SELECTs in a span. But the question to the developers of LinkSelect - is it the intended and correct behavior? cheers, snobo P.S. I posted this one also to jQuery Plugins group, but seems this group is kinda dead... Hmm, I wonder should that group be eliminated - right now it seems confusing to which group messages regarding plugins UI ought to be posted...
[jQuery] tableSorter: correct handling of a non-standard decimal (proposed bug fix)
By default, tableSorter assumes that decimal point character is '.',
and assigns a text parser to a column that contain strings like
123,45. There is an undocumented (why?) property decimal, which
helps tableSorter understand that these are in fact numbers:
$(...).tablesorter( { decimal: ',' } );
But, alas, this property is NOT USED by a digit parser, when
actually sorting the records! Therefore, the number 123,45 becomes
123, and you [might] get incorrect sorting. This can be fixed very
easily in the code around line #712:
instead of
format: function(s) {
return $.tablesorter.formatFloat(s);
},
I suggest something like this:
format: function(s,table) {
if (table.config.decimal table.config.decimal!='.') s =
s.replace(table.config.decimal,'.');
return $.tablesorter.formatFloat(s);
},
my 2 cents :)
[jQuery] tableSorter: modify existing parsers?
I was going to modify the standard digit parser for the tableSorter plugin to fix the other problem I reported here: http://groups.google.com/group/jquery-en/browse_frm/thread/c5d1ecc422e68a89 but I found out that it seems impossible. It's very easy to add a new parser using $.tablesorter.addParser() method, but there is no interface for updating the existing parsers. If the author has no objections, I would humbly request adding this possibility in any way it seems suitable. Maybe even by modifying the existing addParser() method to allow replacing the parser if it's already exists (currently, this option is disabled). thanx in advance!
[jQuery] Re: removeAttr for rowspan
CORRECTION: no, rowspan doesn't work in IE, which ONLY understands
it with a capital S: rowSpan. So, now (since 1.2.5) the only way to
remove a rowspan in IE is to do
.attr('rowSpan',1)
and not removeAttr('rowspan') or removeAttr('rowSpan') or
attr('rowspan',1).
FF forgives and understands all of the above. Weird...
On May 29, 9:19 am, snobo [EMAIL PROTECTED] wrote:
Huh, interesting! Indeed, specifying an attribute in lowercase makes
it work.
All in all, it seems like a inconsistency to me, that attr() method
and FF don't care about the case, but removeAttr() and IE do.
On May 29, 12:31 am, kape [EMAIL PROTECTED] wrote:
I encountered the same problem when I upgraded to 1.2.6 and using
rowspan instead of rowSpan fixed it. I guess it was a bug fix.
On May 27, 1:27 pm,snobo[EMAIL PROTECTED] wrote:
Since upgrading to 1.2.5 (the same applies to1.2.6), an attempt to $
('... td').removeAttr('rowSpan') triggers an error in IE6/7.
Previously (up to 1.2.4b) it effectively setrowSpanto 1. It still
works that way in FF.
I'm not sure is it a bug or a feature, but of course it has broken my
application, so... I guess it should be either fixed or explicitly
noted in the docs. I wonder, will it cause the same problem for some
other attributes?
[jQuery] Re: removeAttr for rowspan
Huh, interesting! Indeed, specifying an attribute in lowercase makes
it work.
All in all, it seems like a inconsistency to me, that attr() method
and FF don't care about the case, but removeAttr() and IE do.
On May 29, 12:31 am, kape [EMAIL PROTECTED] wrote:
I encountered the same problem when I upgraded to 1.2.6 and using
rowspan instead of rowSpan fixed it. I guess it was a bug fix.
On May 27, 1:27 pm,snobo[EMAIL PROTECTED] wrote:
Since upgrading to 1.2.5 (the same applies to1.2.6), an attempt to $
('... td').removeAttr('rowSpan') triggers an error in IE6/7.
Previously (up to 1.2.4b) it effectively setrowSpanto 1. It still
works that way in FF.
I'm not sure is it a bug or a feature, but of course it has broken my
application, so... I guess it should be either fixed or explicitly
noted in the docs. I wonder, will it cause the same problem for some
other attributes?
[jQuery] removeAttr for rowspan
Since upgrading to 1.2.5 (the same applies to 1.2.6), an attempt to $
('... td').removeAttr('rowSpan') triggers an error in IE6/7.
Previously (up to 1.2.4b) it effectively set rowSpan to 1. It still
works that way in FF.
I'm not sure is it a bug or a feature, but of course it has broken my
application, so... I guess it should be either fixed or explicitly
noted in the docs. I wonder, will it cause the same problem for some
other attributes?
[jQuery] remove() works differently in 1.5b4, at least for UI Dialogs
I stumbled upon a tricky situation. In my app, I use UI Dialogs based
on my form's. When a dialog is created, it takes the form out of
the HTML context where it was originally located, moves before the
closing /body tag and wraps it with all these dialog divs, buttons
etc. But when my AJAX calls replace body content with a new HTML, the
problem occurs that now I have TWO identical forms in the DOM: one
that was just returned with AJAX call, and another one that remains in
this ghost dialog stuck in the end of the body. This makes a mess
and also leads to creating duplicated dialogs...
So, before creating a dialog, I previously had to check for existence
of those ghost dialogs:
if ($('.ui-dialog '+pid).length) $('.ui-dialog '+pid).parents('.ui-
dialog').remove();
where pid is the id of my form that the dialog is made of.
Now, after upgrading to 1.5b4, it turned out that remove() works
differently! It doesn't remove the $('.ui-dialog '+pid).parents('.ui-
dialog'), which is a main dialog div, from DOM! Instead, it kinda
destroys the dialog, stripping all its divs and buttons, and leaving
my original form hanging in the air, still stuck in the end of the
body...
Maybe it's because UI Dialogs have their own remove() method and it
replaces general jQuery remove-from-DOM method?
[jQuery] Re: blockUI: message vertical centering, is there a way to switch it off?
Excellent, exactly what I needed! Thanx a lot for quick fix! cheers, snobo On Apr 29, 2:21 am, Mike Alsup [EMAIL PROTECTED] wrote: v2.03 is available now. This page demos how to use the new position stuff: http://malsup.com/jquery/block/position.html Mike
[jQuery] Re: modal dialogs - noticeably slow
I'm using standard Dialog UI with setting modal=true. OS is Windows XP, control styling and other visual beautifications are switched off. Slowdown is experienced on Firefox 2.0.0.14 and IE6/7. On IE7, it's quite annoying. In FF, it's still quite noticeable, on IE6, a little bit worse than on FF. On Apr 25, 8:06 pm, Richard D. Worth [EMAIL PROTECTED] wrote: Which plugin are you using? Also, which browser and OS? - Richard On Fri, Apr 25, 2008 at 9:27 AM, snobo [EMAIL PROTECTED] wrote: hi, when using modal dialogs with more or less complicated forms inside, working with form controls gets noticeably slow, at least on Pentium 4 2.6 GHz. Opening drop-downs, pressing buttons, typing in the input fields - all actions with a noticeable delay. I understand that in order to make a dialog modal handlers are added to all events, but... is there a way to optimize the productivity? Has anybody experienced the same slowdown? Of course when I switch off the modality everything works as intended - fast and without delays. cheers
[jQuery] Re: blockUI: message vertical centering, is there a way to switch it off?
thanx, but it doesn't help to control vertical positioning of the message within the element-blocked area. I already tried all margin- top and top combinations, of course including negative. Setting top to a constant value works when blocking the whole page (as demonstrated on http://www.malsup.com/jquery/block/css.html), but not a custom area - where only % more or less work, but because the area I'm blocking is of a variable height, it doesn't help either. No matter how I experiment, the message still pops up in different locations depending on the area's height at this particular moment. And because I need a constant offset from the top of the blocked area, currently the only solution that works for me is commenting a line in the BlockUI source code. :( Ugh :( -=snobo=- On Apr 25, 5:49 pm, Mike Alsup [EMAIL PROTECTED] wrote: These pages show how you can take control of the block styling. Control over the positioning is achieved by using margin offsets. (Note that these pages use the 2.0 blockUI code) http://www.malsup.com/jquery/block/css.htmlhttp://www.malsup.com/jquery/block/css2.htmlhttp://www.malsup.com/jquery/block/stylesheet.html Mike
[jQuery] blockUI: message vertical centering, is there a way to switch it off?
Hi, the message is always centered horizontally+vertically within the blocked area. I need the possibility to switch it off, the reason: when I block a long screen section, the vertically centered message might often displayed invisible for a user (below the bottom of the screen!). It seems there is no way to switch it off or in any way to bypass/control it (height=100% doesn't work in IE). I would like to see the possibility to override the autocentering of the message (via CSS or .defaults). thanx!
[jQuery] modal dialogs - noticeably slow
hi, when using modal dialogs with more or less complicated forms inside, working with form controls gets noticeably slow, at least on Pentium 4 2.6 GHz. Opening drop-downs, pressing buttons, typing in the input fields - all actions with a noticeable delay. I understand that in order to make a dialog modal handlers are added to all events, but... is there a way to optimize the productivity? Has anybody experienced the same slowdown? Of course when I switch off the modality everything works as intended - fast and without delays. cheers
