- Screen name: john.snyders
john.snyders's Profile
3 Posts
5 Responses
0
Followers
Show:
- Expanded view
- List view
Private Message
- I having a problem with jQueryUI dialog on IE8. What I'm finding is that scroll bars are added to the window because the overlay is too big. In addition this causes continuous resize events.
The overlay size problem is because dialog calls $(document).width()/.height() to setup the size of the overlay but on IE8 the size is larger than is should be. In jquery width/height on the document returns the max of a number of things including documentElement clientWidth, scrollWidth and offsetWidth. For some reason offsetWidth is larger than the others on IE8 only. Could this be due to the markup of my page? I'll look into that some more but my page is (I think) simple. It manages the size and layout of divs so that the window is always filled and without scroll bars.
The continuous resize event problem is because of the overlay resize code where it first shrinks the overlay to 0 and then makes it as big as the screen (again getting it wrong). I don't see why this should cause a resize since the window doesn't actually change size. Ticket 4097 says that IE8 used to have a problem with reflow causing a resize. But it says that was fixed. Is this somehow related? Perhaps if the overlay size is calculated right then the scroll bars and resize event problems will go away.
Any one else seen this or have a workaround? I may attempt changing the overlay size code to use documentElement clientWidth which I know works for the browsers I'm supporting.
jQueryUI version 1.7.2 and jQuery version 1.3.2- I believe there is a bug in how ui dialog keeps focus in the dialog. This version 1.7.2.
I have not checked if it is fixed in newer versions. I need the most stable release at this point.
It uses keypress to handle the tab key but IE7 doesn't give tab to keypress.
I changed it to use keydown as so:
// prevent tabbing out of modal dialogs
(options.modal && uiDialog.bind('keypress.ui-dialog', function(event) {
and a corresponding change in the close method.
I made two other minor changes.
When tab on the first or last focusable is detected the focus call is wrapped in a setTimeout.
However initial dialog focus is not set in a setTimeout. In addition the normal behavior for
a text input when it receives focus is to select the contents of the text. I changed the
code as follows:
// set focus to the first tabbable element in the content area or the first button
// if there are no tabbable elements, set focus on the dialog itself
$([])
.add(uiDialog.find('.ui-dialog-content :tabbable:first'))
.add(uiDialog.find('.ui-dialog-buttonpane :tabbable:first'))
.add(uiDialog)
.filter(':first')
.each(function() {
var self = this;
setTimeout(function() {
self.focus();
if (self.nodeName == "INPUT" && self.type == "text") {
self.select();
}
}, 1);
});I think this may be a problem. I have nested droppables. The inner droppables are greedy so if I drop on an inner one the outer one doesn't get dropped on. This works as expected. Both inner and outer accept the same draggables.
The draggables I'm using have revert option set to invalid. I notice that when I drop the draggable is always reverted even though the drop succeeds. This seems wrong. It doesn't happen when there is no nesting.
I think the problem is in ui.ddmanager.drop. The dropped var gets assigned to whatever droppable gets called last. The drop method shoud return whichever drop succeeded. I changed the code as follows:
$.each($.ui.ddmanager.droppables[draggable.options.scope], function() {
var tmp;
if(!this.options) return;
if (!this.options.disabled && this.visible && $.ui.intersect(draggable, this, this.options.tolerance)) {
tmp = this._drop.call(this, event);
if (tmp) {
dropped = tmp;
}
}Is this indeed a bug or am I missing something. Is the solution OK or is there a better way?
Thanks,
-John
- «Prev
- Next »
Moderate user : john.snyders
© 2013 jQuery Foundation
Sponsored by and others.

