Diego -

Thanks for the clarification, I'll land this as soon as possible.

--John



On Tue, Jan 27, 2009 at 2:47 PM, Diego Perini <diego.per...@gmail.com> wrote:
>
> John,
> it result that it was my fault then...
>
> Here are the relevant commit infos:
>
>   http://dev.jquery.com/changeset/5941/trunk/jquery/src/event.js
>
> this was the ticket:
>
>   http://dev.jquery.com/ticket/2614
>
> I don't know/remember what made me suggest the use of
> "window.frameElement", but "window == window.top" works.
>
> Diego
>
>
> On 27 Gen, 23:06, Diego Perini <diego.per...@gmail.com> wrote:
>> John,
>> I could finally replicate the problem with the help of john dalton on
>> IE7 (I only had IE6 to test).
>>
>> The problem is the use of window.frameElement, shouldn't error since
>> the property is in our global space but who knows...
>>
>> Revert back the change to what is used in the original
>> ContentLoaded.js here:
>>
>>    http://javascript.nwbox.com/ContentLoaded/contentloaded.js
>>
>>    window == top
>>
>> or better as john dalton suggest:
>>
>>    window == window.top
>>
>> it seems that testing in this way the "Access denied" error is
>> circumvented, I probably never fall in this case since I wasn't using
>> jQuery window.frameElement in my own code.
>>
>> Diego
>>
>> On 27 Gen, 21:34, Diego Perini <diego.per...@gmail.com> wrote:
>>
>> > John,
>>
>> > On 27 Gen, 20:23, John Resig <jere...@gmail.com> wrote:
>>
>> > > I think you misunderstood me. Simply accessing the frameElement
>> > > property from a frame that isn't on the same domain as the parent
>> > > frame causes an exception to be thrown.
>>
>> > I probably did. However I don't see any cross-frame access in that
>> > part of the code we are just peeking a property on the same window
>> > where jQuery is loaded, we always own that window.frameElement
>> > property. Am I missing something ?
>>
>> > > Previously the check was: !window.frameElement
>>
>> > Well the other way to do it is:
>>
>> >    window.frameElement === null
>>
>> > which we already talked about when writing that patch, hope you recall
>> > that.
>>
>> > > Which was not enough - it completely breaks use of jQuery. There needs
>>
>> > It seemed to work well in 1.2.6 from what the OP says, I am sure there
>> > are other edge cases but even trying what is pointed out in ticket
>> > #3898 I cannot reproduce this bug.
>>
>> > It will help having a link to an example showing the misbehavior of
>> > ready().
>>
>> > > to be a new check. Granted, the typeof one appears to be too extreme
>> > > but the previous one was broken, as well (and in a much worse way).
>>
>> > Could you further elaborate on the exact problems you detected with
>> > the iframe check ?
>>
>> > Diego
>>
>> > > --John
>>
>> > > On Tue, Jan 27, 2009 at 11:18 AM, Diego Perini <diego.per...@gmail.com> 
>> > > wrote:
>>
>> > > > John,
>> > > > well the reasons are ok, but the method is wrong in fact the doScroll
>> > > > () trick is actually short-circuited and will never be usable neither
>> > > > in iframes nor on the main document. So in IE everything will be
>> > > > started by the "onreadystatechange" event...a bit too late.
>>
>> > > > Diego
>>
>> > > > On 27 Gen, 20:09, John Resig <jere...@gmail.com> wrote:
>> > > >> That check, alone, is not sufficient, though. We were hitting a number
>> > > >> of ugly exceptions with IE - when dealing with cross-domain frames.
>>
>> > > >>http://dev.jquery.com/ticket/3880
>>
>> > > >> In this commit:http://dev.jquery.com/changeset/6120
>>
>> > > >> So some alternative solution will need to be derived - especially
>> > > >> since getting the exceptions was far worse (the page didn't load, at
>> > > >> all).
>>
>> > > >> --John
>>
>> > > >> On Tue, Jan 27, 2009 at 11:00 AM, Diego Perini 
>> > > >> <diego.per...@gmail.com> wrote:
>>
>> > > >> > John,
>> > > >> > the report is OK and says the truth...Mexicans would say "ay ay
>> > > >> > ay !!!".
>>
>> > > >> > This is something that should have been avoided...a too critical 
>> > > >> > place
>> > > >> > to play with.
>>
>> > > >> > The problem I see is that my patch and test for iframes got changed:
>>
>> > > >> > Line 2952 is currently:
>>
>> > > >> > if ( document.documentElement.doScroll && typeof window.frameElement
>> > > >> > === "undefined" ) (function(){
>>
>> > > >> > This will always exclude the doScroll() magic.
>>
>> > > >> > When does the type of that property assumes an "undefined" type ? I
>> > > >> > would bet for "never" ?
>>
>> > > >> > That property can be "null" which is an "object" not an "undefined"
>> > > >> > value. Please fix that a.s.a.p. to avoid further problems and wrong
>> > > >> > reports.
>>
>> > > >> > I would take my part of responsibility for not having checked that,
>> > > >> > but releases are so fast I didn't even know a 1.3.1 was already
>> > > >> > available.
>>
>> > > >> > Diego
>>
>> > > >> > On 27 Gen, 17:24, John Resig <jere...@gmail.com> wrote:
>> > > >> >> Do you have a demo page that we can look at?
>>
>> > > >> >> --John
>>
>> > > >> >> On Fri, Jan 23, 2009 at 11:01 AM, helianthus
>>
>> > > >> >> <project.heliant...@gmail.com> wrote:
>>
>> > > >> >> > 1.2.6:
>> > > >> >> > No problems on all browsers tested.
>> > > >> >> > 1.3.1:
>> > > >> >> > IE7 & IE8 beta2: Fires only after all images are completely 
>> > > >> >> > loaded.
>> > > >> >> > FF3, Opera 9, Chrome: Fires right after DOM is loaded.
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to 
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/jquery-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to