Random asset load order in Safari causing runtime bugs about blue-ridge HOT 12 OPEN

Dr Nic, thanks for pointing this out. It looks like we need to explicitly chain the requires in the blue-ridge.js file rather than just require them all asynchronously.

from blue-ridge.

Hi,

I reordered the require's in blue-ridge.js like so:

require(BLUE_RIDGE_LIB_PREFIX + "jquery-1.3.2.js", { onload: function() {
    require(BLUE_RIDGE_LIB_PREFIX + "jquery.fn.js", { onload: function() {
        require(BLUE_RIDGE_LIB_PREFIX + "jquery.print.js", { onload: function() {
            require(BLUE_RIDGE_LIB_PREFIX + "screw.builder.js", { onload: function() {
                require(BLUE_RIDGE_LIB_PREFIX + "screw.matchers.js", { onload: function() {
                    require(BLUE_RIDGE_LIB_PREFIX + "screw.events.js", { onload: function() {
                        require(BLUE_RIDGE_LIB_PREFIX + "screw.behaviors.js", { onload: function() {
                            require(BLUE_RIDGE_LIB_PREFIX + "smoke.core.js", { onload: function() {
                                require(BLUE_RIDGE_LIB_PREFIX + "smoke.mock.js", { onload: function() {
                                    require(BLUE_RIDGE_LIB_PREFIX + "smoke.stub.js", { onload: function() {
                                        require(BLUE_RIDGE_LIB_PREFIX + "screw.mocking.js", { onload: function() {
                                            require(derive_spec_name_from_current_file());
                                        }});
                                    }});
                                }});
                            }});
                        }});
                    }});
                }});
            }});
        }});
    }});    
}});

Everything loads in order, but it tests still don't run correctly on Safari 4. Any ideas?

from blue-ridge.

Let's just take a moment to observe how disturbing that code looks due to the nested nature. ... I need another moment... :D

If we do get this working, it would be fun to come up with a DSL for nested require's, something like:

   require('some_file.js').
   then_require('dependent_file.js)

That would be sweet.

Are you coming to FutureRuby this weekend?

from blue-ridge.

@tanzeeb: Have you actually got it working with that? When I make that change, the files load correctly, but Safari 4.0.2 doesn't actually run any of the tests.

It looks like Safari either 1) isn't telling jQuery that the DOM is ready or 2) telling jQuery that the DOM is ready too soon.

from blue-ridge.

@karnowski - @tanzeeb says above it still isn't working for him on Safari.

Hmm, interesting problem. I'm sure I've seen the tests run occasionally on Safari. Hopefully I can find some time to poke around. Stupid bug.

from blue-ridge.

Ah, so he does! Thanks @drnic.

from blue-ridge.

@drnic Well if you rotate your monitor 90 degrees, it looks like a very nice pyramid. ;-) Missed out on FutureRuby, did you go? How was it?

@karnowski No I still haven't figured out why it doesn't run in Safari 4. Tight deadline on my project, but once its done I'll take a look to see why. I think you're right about it being a jQuery / DOM Ready issue.

from blue-ridge.

any updates?

I'm stuck with a safari specific bug and I'd love to write some tests to verify the bugs are fixed.

from blue-ridge.

Updates: We can use tazeeb's fix above, but then we're still stuck with the Safari-4 problem described in issue #21. I'm leaving this issue open to add tanzeeb's fix (but with a more fluent interface on require).

from blue-ridge.

I/we are nearly there with a fix to this. See my "safari" branch for current code. It's not ready yet, but close. A few things of note:
(1) there was an extra slash in the paths, causing scripts not to be loaded
(2) safari/chrome seem to cache local files mercilessly. The only way I was able to see changes was to restart chrome with each change. Ugh. I put in an alert and changed it so I could see changes. Quite tedious.
(3) My approach to the "require" problem is this: "require" collects all needed files into an array (but doesn't include them). There's a final process call that pulls them off one at a time, creating an onload handler.
(4) screw unit still tries to start up before it's ready. By removing this from the screw builder file and calling it after all the onloads have run, it seems to run reliably.

This has broken existing tests, so I'll have to sort that out.

from blue-ridge.

See my pull request.

from blue-ridge.

I'm running tests in multiple browsers using ndp's branch. I think this is a great improvement and fixes two open issues.
Karnowski can you pull these changes into the relevance branch?

from blue-ridge.