Custom Query (18300 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:

Results (163 - 165 of 18300)

← 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 →
Ticket Resolution Summary Owner Reporter
#11544 duplicate The Script Defer mechanism in IE for dojo's onload event breaks with flash objects on page anonymous Yousuf Haider
Description

If you have :

  • an external JS file included in your page


  • a flash object included in the page

in IE the script defer mechanism breaks because deferred script is parsed before the external JS file has been parsed. This is a timing issue so it doesn't happen every time but happens often enough (and on some machines very regularly) to break Dojo's onLoad event mechanism.

The result is that functions attached using addOnLoad() get called before some external js files have been parsed. If the addOnLoad() functions depend on code in those files the page breaks.

Based on my discussion with James Burke on the mailing list external JS files should have been parsed before functions attached using addOnLoad() were called.

Removing the flash object from the page fixes the issue and dojo's onload is triggered at the correct point. (i.e after the external JS files have been parsed)

Happens in both IE 8 and 7.

Steps to reproduce:

  1. Download the attached files and copy them in a local web server.


  1. Open IE with Developer toolbar and open the Script console screen.


  1. The test structure is as follows:


  • The main page contains an IFrame.


  • The Iframe source file innerFrameWithFlash.html is a page with a flash video on it and, a defer script and an external JS file.


  1. Access the defer_test.html page. This page will run the script defer test 50 times by default and print the results in the console.

Since its a timing issue we run it multiple times in case the issue doesn't show up in one run. The expected output for all 50 cases should be:

" external.js parsed readystate complete".


However you will see that some of the runs will log this :
" readystate complete external.js parsed "
indicating that the defer script onreadystate=complete occured before the external JS was parsed.


  1. Now change the iframe's src attribute inside defer_test.html to be innerFrameSimple.html and reload the page.

The results will be :

" external.js parsed readystate complete".


which is what we expect.


This is a serious issue because it breaks the semantics of dojo's onload event. We discovered this issue in our product when a flash object was included on a page that was using Dojo extensively.

#12225 fixed Problem with xdomain loading, setTimeout and IE James Burke Yousuf Haider
Description

In one of our pages we were running into an issue with cross domain loaders and IE. I was able to distill the problem down into an easily reproducible case. Place the following markup in a html file 

<!DOCTYPE html>
<html>
<head>
    <script src="http://ajax.googleapis.com/ajax/libs/dojo/1.5/dojo/dojo.xd.js" type="text/javascript"></script>
</head>
<body>
    <script type="text/javascript">
        dojo.addOnLoad(function() {
            setTimeout(loadStackContainer, 0);
        });
       
        function loadStackContainer() {
            var div = dojo.byId('result');
            dojo.require("dijit.layout.StackContainer");
            dojo.addOnLoad(function() {
                if (dijit && dijit.layout && dijit.layout.StackContainer && dijit.layout.StackContainer.prototype) {
                    div.innerHTML = "Stack container loaded properly";
                } else {
                    div.innerHTML = "Stack Container wasn't loaded dude!";
                }
            });
        }       
    </script>
    <button type="button" onclick="setTimeout(loadStackContainer, 0);">Click here to load stack container again </button>
    <div id='result'>Initial</div>
</body>
</html>

Access this page in IE and you will notice that the StackContainer? doesn't get loaded properly.

What we are doing here is pretty simple. We have an xdomain version of dojo being used.

  1. We have a addOnLoad() function that calls a setTimeout.
  1. The setTimeout calls a function that calls a function does a dojo.require on a module (StackContainer?) that doesn't exist on the page yet.
  1. Dojo uses the xdomain loader to load it. Since we are using an xdomain build the code that is supposed to use the StackContainer? is actually inside another addOnLoad().
  1. Inside the second addOnload() we expect the StackContainer? to be loaded as per Dojo's documentation. Also this would work in all browsers except for IE.
  1. What actually happens on IE is that we do have a stub available but StackContainer? isn't really loaded even on addOnLoad()


This problem goes away if we do two things:

  1. Do not call loadStackContainer() using a setTimeout().
  1. Or if we call loadStackContainer() after page has been loaded. For eg. when clicking on the button.

For some reason this is a problem in IE only.

(note that some of you may wonder why I have the setTimeout in the first place. This is just a very distilled version of what we are actually doing on the page and there are other reasons why we need a setTimeout())

Breaks on IE 7/8

#8226 fixed FilePicker - fix for 'node is null' error Nathan Toone youngstuart
Description

I'm not sure if this has been attended to already but I couldn't find it on this site so I thought I would post this as a FYI.

Problem:

I encountered a 'node is null' error with FilePicker?.js. Here's how I produce the error:

  1. Click on a file (non-directory) node, which displays the file details in the next pane
  2. Click on a directory (non-file) node, which should display the rolling list of files in the next pane, but instead gives this console error in Firefox: 'node is null' in dojo/html.js at line 29 (in the function dojo.html._emptyNode).

Solution:

I traced it back to the _removeAfter function of RollingList? which FilePicker? inherits from. The error can be fixed by replacing line 481 in dojox.widget.RollingList?:

c.destroyRecursive();

c.destroy();

Cheers,

youngstuart

← 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 →
Note: See TracQuery for help on using queries.