Tobie,
for now the following is the easy test that shows how previous version
of prototype where firing the "dom:loaded" event in the wrong order in
Internet Explorer, that was my main concern about, the version I could
"rake" up from "jdalton" git (with kind help from Samuel) did produce
correct results, here is the test:

<script type="text/javascript" src="prototype.js"></
script>
<script type="text/javascript">
/*
 * these events will still be available to IE applications
 * they are not affected, and will normally fire before
 * listeners/observers
 */
if (Prototype.Browser.IE) {
 document.onreadystatechange = function () {
  if (this.readyState == 'complete') {
   document.body.innerHTML += ' * ' + event.type + '<br />';
   status += ' * ' + event.type;
  }
 };
}

window.onload = function (event) {
 event = event || window.event;
 document.body.innerHTML += ' * ' + event.type + '<br />';
 status += ' * ' + event.type;
};

/*
 * IEContentLoaded test (Prototype implementation)
 */
Event.observe(document, 'dom:loaded', function () {
 document.body.innerHTML += ' * dom:loaded<br />';
 status += ' * dom:loaded';
});
</script>

If you run this script "as is" in IE, or adding the bare minimum
required tags the result are the same, it seems browsers will add
these automatically for HTML files. You can also add as much text you
want to the file the result should remain the same, so the "size" of
the page does not affect the test while it is text only...as soon as
you add an image things changes and the order is OK even in previous
versions of prototype if used with IE for this task.

I say this because this is one of the reasons this behavior (and the
infamous IE "Operation Aborted") has remained hidden and seemed
unsolvable for so long time, another reason is that only lately we
have started to see an overload of these hooks, pages where probably
not so complex as today and they didn't need all that interaction.
Anyway I would like to stress this is not the only situation where we
need the "onreadystatechange" fall back. The setTimeout/setInterval is
often not enough alone in situations where the users press the
backward/forward buttons, the reload/refresh keys or access the same
functions by using buttons shortcuts or menu items. The
"onreadystatechange" is what saves us most of the time from these
cached hits.

One issue I am having with "jdalton" git sources is that I get an
extra "dataavailable" event along with the expected "load" event, by
looking at the sources I found this is deliberately done on all
":" (custom) events. I am going to believe you are actually
implementing the "force bubble" for events that does not normally
bubble...nice you added this capability.

Did I understand correctly the sources and the issue I am seeing ?
(createEvent/createEventObject/initEvent/fire/dispatchEvent) sounds ??

Thank you for explaining/expanding,

--
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to