Tobie / Samuel, this is the second test case I promised about the DOMContentLoaded patch that Samuel kindly assembled. Since it is bigger than the previous test I prefer to temporarily publish the tests on my site:
http://javascript.nwbox.com/IEContentLoaded/prototype/tester.html http://javascript.nwbox.com/IEContentLoaded/prototype/tester.php You can grab a compressed archive of all the tests (including the one I sent previously) here: http://javascript.nwbox.com/IEContentLoaded/prototype/prototype-domloaded.tar.gz Please let me know if there is something that should be commented, your implementation of the doScroll technique is the most complete and functional up to now. It really take in consideration many more cases including a nice fall back to "onreadystatechange" for iframes in IE. Also I obviously vote for inclusion (if my vote is valid), I stress that somebody can explain me why I am getting back an event of type "dataavailable" from an observer registered on "DOMContentLoaded". -- Diego Perini On 9 Mag, 04:09, Tobie Langel <[EMAIL PROTECTED]> wrote: > Hi Diego, > > Thanks for your feedback. > > Actually, yes, the move to git + lighthouse has slowed things down > quite a bit. And a couple of bug fixes in events slowed things even > more. > > Afaik, JDD has a port of your patch in his own repositiory (http:// > github.com/jdalton/prototype/tree/master/src/event.js). > > Would you mind letting us know if it's fit for core ? > > Thanks, > > Tobie > > On May 9, 2:05 am, Diego Perini <[EMAIL PROTECTED]> wrote: > > > Samuel / Tobie, > > > Don't know if everything was cleared in our latest conversations > > or there are further doubts or problems implementing this. > > > I would like to know if something has stopped this and > > if I can do something else on the subject. > > > Thank you. > > > Diego Perini > > > On 13 Mar, 20:53, Diego Perini <[EMAIL PROTECTED]> wrote:> Samuel, > > > on Opera the stylesheet fix is in some way documented > > > somewhere, just don't remember where...but the "disabled" > > > property seemed a good hook to me when I answered that post. > > > > For the reasons about using the "onreadystatechange" event, > > > enable "Staus Bar" writing if you are using IE 7, and > > > then run this small code (IE only obviously): > > > > [script type="text/javascript"] > > > document.onreadystatechange = function () { > > > if (this.readyState == 'complete') { > > > status += ' * ' + event.type; > > > } > > > > }; > > > > window.onload = function () { > > > status += ' * ' + event.type; > > > > }; > > > > (function () { > > > try { > > > document.documentElement.doScroll('left'); > > > } catch(e) { > > > setTimeout(arguments.callee,0); > > > return; > > > } > > > status += ' * doScroll';})(); > > > > [/script] > > > > I used the status bar to log the event sequence > > > because the "alert()" will just obfuscate things. > > > > If you look at the output of the above you will > > > see that my "doScroll" method will always fire > > > last, the first always being "readystatechange". > > > > If you now insert an image in the above code or > > > make the page much longer, than "doScroll" will > > > fire as first instead. Not always though... > > > > This is the reason the "onreadystatechange" method > > > used in combination is essential. Without it you > > > cannot ensure the "dom:loaded" will fire before > > > "onload" as various tickets already confirms. > > > > And don't look to others implementation, I tried > > > hard to explain this to them too, unfortunately > > > english is not my native language so I may have > > > explained this wrong, or they have evidences > > > I am wrong but haven't show me where. > > > > I may look a bit paranoid in adding this, nobody > > > write empty pages, it seems an edge case that will > > > never show up in real world, however, trust me a > > > page without images is enough to destroy our > > > expectations very soon. B/F buttons too. > > > > The "IEContentLoaded" will help with many of these > > > "magic" IE situations, we just need to use all the > > > pieces, not just part of it. > > > > Thank you for your time listening...cooperation is king. > > > > Diego Perini > > > > On 13 Mar, 07:52, Samuel Lebeau <[EMAIL PROTECTED]> wrote: > > > > > Diego, feel free to complete/modify the patch I submitted if you find > > > > something missing or incorrect. > > > > This was just an attempt to concretise all that was said here and on > > > > jQuery group. > > > > > It would be great if we could find a way to actually test this > > > > stylesheet issue, for instance by using jstest.rb's SlowServlet > > > > serving a stylesheet file with some special rule... > > > > > Regards, > > > > > Samuel > > > > > Le 13 mars 08 à 02:17, Tobie Langel a écrit : > > > > > > Hi Diego, > > > > > > Thank you very much for the feedback so far. > > > > > > I'd love to hear your comments on Samuel's proposed patch. > > > > > > Best, > > > > > > Tobie > > > > > > On Mar 13, 1:24 am, Samuel Lebeau <[EMAIL PROTECTED]> wrote: > > > > >> I attached a patch (http://dev.rubyonrails.org/ticket/9394) that > > > > >> fixes > > > > >> IE event handlers calling order (ensure FIFO) and tends to fix > > > > >>dom:loadedafter window.onload issue. > > > > >> It uses document.doScroll as you suggested and waits for stylesheets > > > > >> to load on Opera / non-nightly WebKit. > > > > >> Test for event handlers calling order pass on all platforms, but I > > > > >> didn't had much time to test if stylesheets are actuallyloaded. > > > > >> I guess this should do the trick as it's inspired by jQuery whose > > > > >> implementation is working fine. > > > > > >> Best, > > > > >> Samuel Lebeau > > > > > >> Le 12 mars 08 à 18:02, Diego Perini a écrit : > > > > > >>> Tobie, > > > > >>> the following is a patch to current "event.js" in Prototype 1.6.x > > > > >>> that should do the trick for primary documents: > > > > > >>> --- event.js.orig 2008-03-10 18:39:44.000000000 +0100 > > > > >>> +++ event.js 2008-03-10 19:06:49.000000000 +0100 > > > > >>> @@ -308,12 +308,23 @@ > > > > >>> } > > > > > >>> } else { > > > > >>> - document.write("<script id=__onDOMContentLoaded defer > > > > >>> src=//:><\/ > > > > >>> script>"); > > > > >>> - $("__onDOMContentLoaded").onreadystatechange = function() { > > > > >>> + // trying to always fire before onload > > > > >>> + document.onreadystatechange = function() { > > > > >>> if (this.readyState == "complete") { > > > > >>> this.onreadystatechange = null; > > > > >>> fireContentLoadedEvent(); > > > > >>> } > > > > >>> }; > > > > >>> + (function() { > > > > >>> + try { > > > > >>> + // throws errors until after ondocumentready > > > > >>> + document.documentElement.doScroll("left"); > > > > >>> + } catch(e) { > > > > >>> + setTimeout(arguments.callee, 50); > > > > >>> + return; > > > > >>> + } > > > > >>> + // no errors, fire > > > > >>> + fireContentLoadedEvent(); > > > > >>> + }); > > > > >>> } > > > > >>> })(); > > > > > >>> iframes must be handled differently, and there are Opera and > > > > >>> Safari improvements that you may be interested too, see here > > > > >>> for an explanation of the problem and a solution: > > > > > >>>http://groups.google.com/group/jquery-dev/browse_thread/thread/ad7e75 > > > > >>> ... > > > > > >>> If you are interested in my dev site I have a "tester.php" that may > > > > >>> be useful if you need to dig deeper in the problem, however the > > > > >>> reason an event is still needed is because a javascript timer is > > > > >>> still unpredictable even if we set it's timeout to 0ms. > > > > > >>> Regards, > > > > > >>> Diego > > > > > >>> On 25 Feb, 07:37, Tobie Langel <[EMAIL PROTECTED]> wrote: > > > > >>>> Hi, > > > > > >>>> I'm all for it myself. > > > > > >>>> I even had implemented it for 1.6.0.2 and had to revert because it > > > > >>>> was > > > > >>>> making our tests fail. > > > > > >>>> The problem is that the doScroll technique can trigger the > > > > >>>>dom:loaded > > > > >>>> event *after* window.onload, notably on short pages. Delegating to > > > > >>>> window.onload in that case doesn't work, as it's not ordered in > > > > >>>> IE... > > > > >>>> so that's the first thing to solve. > > > > > >>>> Not impossible, of course, so any implementation that passes our > > > > >>>> current tests is more than welcomed. > > > > > >>>> Best, > > > > > >>>> Tobie > > > > > >>>> On Feb 25, 4:21 am, Diego Perini <[EMAIL PROTECTED]> wrote: > > > > > >>>>> Don't know if you already tried the doScroll("left") trick, > > > > >>>>> many frameworks already implemented it, YUI and > > > > >>>>> jQuery to name some, but Mootools have it in SVN > > > > >>>>> and tools like sIFR already uses it. > > > > > >>>>> I proposed this to solve the fact that IE is missing > > > > >>>>> such useful native method. I know many methods > > > > >>>>> exists, each method having his own advantages > > > > >>>>> and disadvantages. This trick is not different in > > > > >>>>> that respect but it has some tasty advantages. > > > > > >>>>> This is a link to the original code and trick: > > > > > >>>>> http://javascript.nwbox.com/IEContentLoaded/ > > > > > >>>>> And here you can find a tentative test case / tester if you > > > > >>>>> want to try out your own code / modifications: > > > > > >>>>> http://javascript.nwbox.com/IEContentLoaded/tester.php > > > > > >>>>> The current pre-loadedjavascript is only for IE, but you > > > > >>>>> may paste your code in the text area and see if > > > > >>>>> it fires correctly in your preferred browser. > > > > > >>>>> Sorry for the colors...and shortness in general. > > > > > >>>>> Diego Perini --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Prototype: Core" group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~----------~----~----~----~------~----~------~--~---
