Hi all,
This might be a more generic browser/javascript questions than a
prototype specific quesiton but i thought it would better to ask here
because you all tend to really understand javascript and browsers in a
ton of detail. So here goes.
var count = 0;
var f = function() {
if ($('inserted') == null) {
console.log("not there");
count++;
if (count > 50) {
$('area'.insert({bottom: "<div id="inserted"></
div>"});
count = 0;
}
f.defer();
} else {
console.log("there");
}
};
f();
Result:
Most of the time it just shows:
>> there
but some of the time it does this
>> not there
>> not there
>> not there
>> there
I am assuming because the insert is something that is queued and the
browser then inserts the nodes into the DOM in its next event loop. I
know that webkit is a single threaded so this makes sense that
sometimes its not there and then it gets there, so really i guess i
have to wait till its there before i can do the "next thing" on that
inserted node. What about firefox and IE? Are they all single threaded
in the same way? What happens in Chrome?
Sometimes i see the following happen also which is really concerning
to me:
>> not there
>> not there
>> ... 50 times
>> not there
>> there
It happens every so often on webkit (mac os) and on iPhone webkit and
i can reproduce it pretty easily. I have built something simple that
will do this but all this seems a little crazy to me because when i
look at others code they dont even take this into account. They never
way for DOM elements to show up when inserting HTML text into a DOM
element.
It sounds like you've already put together a minimalist test case,
would you post it (e.g., to Pastie[1] or similar)? I haven't run into
a situation where a single defer wasn't sufficient, but I also haven't
tested extensively on Mac OS.
Cheers,
--
T.J. Crowder
Independent Software Consultant
tj / crowder software / com
www.crowdersoftware.com
On Oct 30, 7:19 am, phegaro <pheg...@gmail.com> wrote:
> Hi all,
> This might be a more generic browser/javascript questions than a
> prototype specific quesiton but i thought it would better to ask here
> because you all tend to really understand javascript and browsers in a
> ton of detail. So here goes.
> var count = 0;
> var f = function() {
> if ($('inserted') == null) {
> console.log("not there");
> count++;
> if (count > 50) {
> $('area'.insert({bottom: "<div id="inserted"></
> div>"});
> count = 0;
> }
> f.defer();
> } else {
> console.log("there");
> }
> };
> f();
> Result:
> Most of the time it just shows:
> >> there
> but some of the time it does this
> >> not there
> >> not there
> >> not there
> >> there
> I am assuming because the insert is something that is queued and the
> browser then inserts the nodes into the DOM in its next event loop. I
> know that webkit is a single threaded so this makes sense that
> sometimes its not there and then it gets there, so really i guess i
> have to wait till its there before i can do the "next thing" on that
> inserted node. What about firefox and IE? Are they all single threaded
> in the same way? What happens in Chrome?
> Sometimes i see the following happen also which is really concerning
> to me:
> >> not there
> >> not there
> >> ... 50 times
> >> not there
> >> there
> It happens every so often on webkit (mac os) and on iPhone webkit and
> i can reproduce it pretty easily. I have built something simple that
> will do this but all this seems a little crazy to me because when i
> look at others code they dont even take this into account. They never
> way for DOM elements to show up when inserting HTML text into a DOM
> element.
HI T.J,
I'm sorry but are you asking for more than what is above? I can
write a simple page that puts together the HTML and JS listed above.
Is that what you want?
Kiran
On Oct 30, 2:22 am, "T.J. Crowder" <t...@crowdersoftware.com> wrote:
> It sounds like you've already put together a minimalist test case,
> would you post it (e.g., to Pastie[1] or similar)? I haven't run into
> a situation where a single defer wasn't sufficient, but I also haven't
> tested extensively on Mac OS.
> On Oct 30, 7:19 am, phegaro <pheg...@gmail.com> wrote:
> > Hi all,
> > This might be a more generic browser/javascript questions than a
> > prototype specific quesiton but i thought it would better to ask here
> > because you all tend to really understand javascript and browsers in a
> > ton of detail. So here goes.
> > >> not there
> > >> not there
> > >> not there
> > >> there
> > I am assuming because the insert is something that is queued and the
> > browser then inserts the nodes into the DOM in its next event loop. I
> > know that webkit is a single threaded so this makes sense that
> > sometimes its not there and then it gets there, so really i guess i
> > have to wait till its there before i can do the "next thing" on that
> > inserted node. What about firefox and IE? Are they all single threaded
> > in the same way? What happens in Chrome?
> > Sometimes i see the following happen also which is really concerning
> > to me:
> > >> not there
> > >> not there
> > >> ... 50 times
> > >> not there
> > >> there
> > It happens every so often on webkit (mac os) and on iPhone webkit and
> > i can reproduce it pretty easily. I have built something simple that
> > will do this but all this seems a little crazy to me because when i
> > look at others code they dont even take this into account. They never
> > way for DOM elements to show up when inserting HTML text into a DOM
> > element.
> > Any answers/suggestions would be super helpful.
Function.defer is simply delegating the functions execution to
Function.delay which in the end delegates it to a wrapper of
window.setTimeout.
By using defer it enforces the timeout to be a value of 0.01 which is
just enough to hiccup the browser's procedural processing.
If your application relies on this element to be inserted, avoid the
defer and you'll be sure the content is loaded after execution of
insert.
> HI T.J,
> I'm sorry but are you asking for more than what is above? I can
> write a simple page that puts together the HTML and JS listed above.
> Is that what you want?
> Kiran
> On Oct 30, 2:22 am, "T.J. Crowder" <t...@crowdersoftware.com> wrote:
> > Hi Kiran,
> > It sounds like you've already put together a minimalist test case,
> > would you post it (e.g., to Pastie[1] or similar)? I haven't run into
> > a situation where a single defer wasn't sufficient, but I also haven't
> > tested extensively on Mac OS.
> > On Oct 30, 7:19 am, phegaro <pheg...@gmail.com> wrote:
> > > Hi all,
> > > This might be a more generic browser/javascript questions than a
> > > prototype specific quesiton but i thought it would better to ask here
> > > because you all tend to really understand javascript and browsers in a
> > > ton of detail. So here goes.
> > > >> not there
> > > >> not there
> > > >> not there
> > > >> there
> > > I am assuming because the insert is something that is queued and the
> > > browser then inserts the nodes into the DOM in its next event loop. I
> > > know that webkit is a single threaded so this makes sense that
> > > sometimes its not there and then it gets there, so really i guess i
> > > have to wait till its there before i can do the "next thing" on that
> > > inserted node. What about firefox and IE? Are they all single threaded
> > > in the same way? What happens in Chrome?
> > > Sometimes i see the following happen also which is really concerning
> > > to me:
> > > >> not there
> > > >> not there
> > > >> ... 50 times
> > > >> not there
> > > >> there
> > > It happens every so often on webkit (mac os) and on iPhone webkit and
> > > i can reproduce it pretty easily. I have built something simple that
> > > will do this but all this seems a little crazy to me because when i
> > > look at others code they dont even take this into account. They never
> > > way for DOM elements to show up when inserting HTML text into a DOM
> > > element.
> > > Any answers/suggestions would be super helpful.
> Function.defer is simply delegating the functions execution to
> Function.delay which in the end delegates it to a wrapper of
> window.setTimeout.
> By using defer it enforces the timeout to be a value of 0.01 which is
> just enough to hiccup the browser's procedural processing.
> If your application relies on this element to be inserted, avoid the
> defer and you'll be sure the content is loaded after execution of
> insert.
> On Nov 2, 7:41 pm, phegaro <pheg...@gmail.com> wrote:
> > HI T.J,
> > I'm sorry but are you asking for more than what is above? I can
> > write a simple page that puts together the HTML and JS listed above.
> > Is that what you want?
> > Kiran
> > On Oct 30, 2:22 am, "T.J. Crowder" <t...@crowdersoftware.com> wrote:
> > > Hi Kiran,
> > > It sounds like you've already put together a minimalist test case,
> > > would you post it (e.g., to Pastie[1] or similar)? I haven't run into
> > > a situation where a single defer wasn't sufficient, but I also haven't
> > > tested extensively on Mac OS.
> > > On Oct 30, 7:19 am, phegaro <pheg...@gmail.com> wrote:
> > > > Hi all,
> > > > This might be a more generic browser/javascript questions than a
> > > > prototype specific quesiton but i thought it would better to ask here
> > > > because you all tend to really understand javascript and browsers in a
> > > > ton of detail. So here goes.
> > > > >> not there
> > > > >> not there
> > > > >> not there
> > > > >> there
> > > > I am assuming because the insert is something that is queued and the
> > > > browser then inserts the nodes into the DOM in its next event loop. I
> > > > know that webkit is a single threaded so this makes sense that
> > > > sometimes its not there and then it gets there, so really i guess i
> > > > have to wait till its there before i can do the "next thing" on that
> > > > inserted node. What about firefox and IE? Are they all single threaded
> > > > in the same way? What happens in Chrome?
> > > > Sometimes i see the following happen also which is really concerning
> > > > to me:
> > > > >> not there
> > > > >> not there
> > > > >> ... 50 times
> > > > >> not there
> > > > >> there
> > > > It happens every so often on webkit (mac os) and on iPhone webkit and
> > > > i can reproduce it pretty easily. I have built something simple that
> > > > will do this but all this seems a little crazy to me because when i
> > > > look at others code they dont even take this into account. They never
> > > > way for DOM elements to show up when inserting HTML text into a DOM
> > > > element.
> > > > Any answers/suggestions would be super helpful.
> On Nov 5, 3:22 pm, Matt Foster <mattfoste...@gmail.com> wrote:
> > Hey Kiran,
> > Function.defer is simply delegating the functions execution to
> > Function.delay which in the end delegates it to a wrapper of
> > window.setTimeout.
> > By using defer it enforces the timeout to be a value of 0.01 which is
> > just enough to hiccup the browser's procedural processing.
> > If your application relies on this element to be inserted, avoid the
> > defer and you'll be sure the content is loaded after execution of
> > insert.
> > On Nov 2, 7:41 pm,phegaro<pheg...@gmail.com> wrote:
> > > HI T.J,
> > > I'm sorry but are you asking for more than what is above? I can
> > > write a simple page that puts together the HTML and JS listed above.
> > > Is that what you want?
> > > Kiran
> > > On Oct 30, 2:22 am, "T.J. Crowder" <t...@crowdersoftware.com> wrote:
> > > > Hi Kiran,
> > > > It sounds like you've already put together a minimalist test case,
> > > > would you post it (e.g., to Pastie[1] or similar)? I haven't run into
> > > > a situation where a single defer wasn't sufficient, but I also haven't
> > > > tested extensively on Mac OS.
> > > > On Oct 30, 7:19 am,phegaro<pheg...@gmail.com> wrote:
> > > > > Hi all,
> > > > > This might be a more generic browser/javascript questions than a
> > > > > prototype specific quesiton but i thought it would better to ask here
> > > > > because you all tend to really understand javascript and browsers in a
> > > > > ton of detail. So here goes.
> > > > > >> not there
> > > > > >> not there
> > > > > >> not there
> > > > > >> there
> > > > > I am assuming because the insert is something that is queued and the
> > > > > browser then inserts the nodes into the DOM in its next event loop. I
> > > > > know that webkit is a single threaded so this makes sense that
> > > > > sometimes its not there and then it gets there, so really i guess i
> > > > > have to wait till its there before i can do the "next thing" on that
> > > > > inserted node. What about firefox and IE? Are they all single threaded
> > > > > in the same way? What happens in Chrome?
> > > > > Sometimes i see the following happen also which is really concerning
> > > > > to me:
> > > > > >> not there
> > > > > >> not there
> > > > > >> ... 50 times
> > > > > >> not there
> > > > > >> there
> > > > > It happens every so often on webkit (mac os) and on iPhone webkit and
> > > > > i can reproduce it pretty easily. I have built something simple that
> > > > > will do this but all this seems a little crazy to me because when i
> > > > > look at others code they dont even take this into account. They never
> > > > > way for DOM elements to show up when inserting HTML text into a DOM
> > > > > element.
> > > > > Any answers/suggestions would be super helpful.
> I'm sorry but are you asking for more than what is above? I can
> write a simple page that puts together the HTML and JS listed above.
Yes, there are a lot of details not included in that post, which may
be relevant. There are lots of good reasons to do a complete, stand-
alone test case, not least that it eliminates that problem (of missing
details). _Your_ doing it (rather than someone who isn't seeing the
problem) ensures that you create a test case that replicates the
behavior. Separately, when I'm seeing behavior that doesn't quite make
sense to me, when I do a separate isolated test case, I frequently
find that I did something _slightly_ wrong in the original. And if I
don't find that, I have something useful I can post here. :-)
> HI T.J,
> I'm sorry but are you asking for more than what is above? I can
> write a simple page that puts together the HTML and JS listed above.
> Is that what you want?
> Kiran
> On Oct 30, 2:22 am, "T.J. Crowder" <t...@crowdersoftware.com> wrote:
> > Hi Kiran,
> > It sounds like you've already put together a minimalist test case,
> > would you post it (e.g., to Pastie[1] or similar)? I haven't run into
> > a situation where a single defer wasn't sufficient, but I also haven't
> > tested extensively on Mac OS.
> > On Oct 30, 7:19 am, phegaro <pheg...@gmail.com> wrote:
> > > Hi all,
> > > This might be a more generic browser/javascript questions than a
> > > prototype specific quesiton but i thought it would better to ask here
> > > because you all tend to really understand javascript and browsers in a
> > > ton of detail. So here goes.
> > > >> not there
> > > >> not there
> > > >> not there
> > > >> there
> > > I am assuming because the insert is something that is queued and the
> > > browser then inserts the nodes into the DOM in its next event loop. I
> > > know that webkit is a single threaded so this makes sense that
> > > sometimes its not there and then it gets there, so really i guess i
> > > have to wait till its there before i can do the "next thing" on that
> > > inserted node. What about firefox and IE? Are they all single threaded
> > > in the same way? What happens in Chrome?
> > > Sometimes i see the following happen also which is really concerning
> > > to me:
> > > >> not there
> > > >> not there
> > > >> ... 50 times
> > > >> not there
> > > >> there
> > > It happens every so often on webkit (mac os) and on iPhone webkit and
> > > i can reproduce it pretty easily. I have built something simple that
> > > will do this but all this seems a little crazy to me because when i
> > > look at others code they dont even take this into account. They never
> > > way for DOM elements to show up when inserting HTML text into a DOM
> > > element.
> > > Any answers/suggestions would be super helpful.
Hi T.J.,
I tried out creating a unit test case for this and doing stuff on
page load and i cant seem to reproduce this on Safari on the desktop
anymore. Its odd because i think it might have to do with timing and
how long the browser takes to render the content into the DOM but i
can reproduce in a simple unit test. I'll check that this unit test
works on iPhone and give you an update.
Thanks
Kiran
On Nov 17, 6:37 am, "T.J. Crowder" <t...@crowdersoftware.com> wrote:
> > I'm sorry but are you asking for more than what is above? I can
> > write a simple page that puts together the HTML and JS listed above.
> Yes, there are a lot of details not included in that post, which may
> be relevant. There are lots of good reasons to do a complete, stand-
> alone test case, not least that it eliminates that problem (of missing
> details). _Your_ doing it (rather than someone who isn't seeing the
> problem) ensures that you create a test case that replicates the
> behavior. Separately, when I'm seeing behavior that doesn't quite make
> sense to me, when I do a separate isolated test case, I frequently
> find that I did something _slightly_ wrong in the original. And if I
> don't find that, I have something useful I can post here. :-)
> On Nov 3, 12:41 am, phegaro <pheg...@gmail.com> wrote:
> > HI T.J,
> > I'm sorry but are you asking for more than what is above? I can
> > write a simple page that puts together the HTML and JS listed above.
> > Is that what you want?
> > Kiran
> > On Oct 30, 2:22 am, "T.J. Crowder" <t...@crowdersoftware.com> wrote:
> > > Hi Kiran,
> > > It sounds like you've already put together a minimalist test case,
> > > would you post it (e.g., to Pastie[1] or similar)? I haven't run into
> > > a situation where a single defer wasn't sufficient, but I also haven't
> > > tested extensively on Mac OS.
> > > On Oct 30, 7:19 am, phegaro <pheg...@gmail.com> wrote:
> > > > Hi all,
> > > > This might be a more generic browser/javascript questions than a
> > > > prototype specific quesiton but i thought it would better to ask here
> > > > because you all tend to really understand javascript and browsers in a
> > > > ton of detail. So here goes.
> > > > >> not there
> > > > >> not there
> > > > >> not there
> > > > >> there
> > > > I am assuming because the insert is something that is queued and the
> > > > browser then inserts the nodes into the DOM in its next event loop. I
> > > > know that webkit is a single threaded so this makes sense that
> > > > sometimes its not there and then it gets there, so really i guess i
> > > > have to wait till its there before i can do the "next thing" on that
> > > > inserted node. What about firefox and IE? Are they all single threaded
> > > > in the same way? What happens in Chrome?
> > > > Sometimes i see the following happen also which is really concerning
> > > > to me:
> > > > >> not there
> > > > >> not there
> > > > >> ... 50 times
> > > > >> not there
> > > > >> there
> > > > It happens every so often on webkit (mac os) and on iPhone webkit and
> > > > i can reproduce it pretty easily. I have built something simple that
> > > > will do this but all this seems a little crazy to me because when i
> > > > look at others code they dont even take this into account. They never
> > > > way for DOM elements to show up when inserting HTML text into a DOM
> > > > element.
> > > > Any answers/suggestions would be super helpful.
|
