Custom Query (18300 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (211 - 213 of 18300)

Ticket Resolution Summary Owner Reporter
#9180 fixed 1.3 dijit.Dialog / dijit._underlay uses references to self-created DialogUnderlay bill Phil DeJarnett
Description

This is hard to explain, but in Dialog.js, if dijit._underlay is created by a specific dialog, that Underlay is always used for the fadeIn, due to the fact that it is assigned to the variable underlay. However, the fadeOut correctly refers to dijit._underlay directly.

This is an edge case, but the possibility exists that dijit._underlay was changed, and the Dialog now no longer refers to the correct underlay if it is shown at a later time.

I'm attaching a diff that replaces the underlay variable with dijit._underlay.

Note: this would be irrelevant if dijit.Dialog supported multiple Dialogs. The new single-underlay, while more efficient, makes this extremely difficult to pull off in custom code.

#8877 duplicate 1.3.0 beta3: dijit.form.Textarea not working in AccordionContainer beyond233
Description

It appears that if I place a dijit.form.Textarea inside a panel of a AccordionContainer?, the textarea control stop accepting user input. I've verified that if I instead place the textarea in a standalone plain ContentPanel?, it works fine. This only occurs in 1.3.0b3. Tested also in 1.3.0b2 and it worked.

I didn't play much with the SimpleTextarea? to know whether it's also broken.

Browser tested: IE6, 7, Firefox 3. All failed.

#9731 fixed 1.3.2: Editor sometimes triggers a secure/insecure warning in IE6 Jared Jurkiewicz Jared Jurkiewicz
Description

1.3.2: Editor sometimes triggers a secure/insecure warning in IE6

This problem occurs due to a fix we put in to handle corrupted charsets in IE, which occurred when we changed the editor over from being loaded from blank.html to dynamic JS string creation. The blank.html change was needed to fix an IE iframes/back button issue so going back to that isn't satisfactory.

The problem occurs (I believe), when the charset of the main page doesn't match the charset the iframe is initially created as and then loaded. When the iframe encounters the charset declaration, it triggers a reparse. If that reparse occurs while the frame is still in the middle of doing something, it then throws the secure/insecure warning.

This, I suspect, is very similar to another very well known bug in IE6 where if you remove a <DIV> that had a background image from the page while the image was loading it threw a secure/insecure warning. Neither of these situations have anything to do with secure/insecure, but however IE6 handles the case seems to trip their hander for such.

In any event, Bill Keese made changes to 1.4 that got rid of the need to set the charset meta tag and still obtained a correct encoding for the editor content. I backported that change and verified with a co-worker that the backport eliminated the warning he was getting. I'll be attaching the patch for it here. After some quick testing, I'll also commit the change.

Note: See TracQuery for help on using queries.