Firefox 3.5.5 crapping itself on large updates inside event handlers, just me?

Discussion in 'Javascript' started by Nik Coughlin, Dec 14, 2009.

  1. Nik Coughlin

    Nik Coughlin Guest

    Adding 2000 elements to the page outside an event handler takes a handful of
    milliseconds. Doing the same from within an event handler takes over 6
    seconds. Doesn't happen in Chrome, Opera, Safari or even IE.

    Does anyone else see this with Firefox 3.5.5 or is it just something weird
    happening on my computer? I thought it might be some flaky addon, so tried
    it with a fresh Firefox profile, same result.

    Demo:
    http://nrkn.com/temp/ffwtf/
    Nik Coughlin, Dec 14, 2009
    #1
    1. Advertising

  2. Nik Coughlin

    rf Guest

    Nik Coughlin wrote:
    > Adding 2000 elements to the page outside an event handler takes a
    > handful of milliseconds. Doing the same from within an event handler
    > takes over 6 seconds. Doesn't happen in Chrome, Opera, Safari or even
    > IE.
    > Does anyone else see this with Firefox 3.5.5 or is it just something
    > weird happening on my computer? I thought it might be some flaky
    > addon, so tried it with a fresh Firefox profile, same result.
    >
    > Demo:
    > http://nrkn.com/temp/ffwtf/


    Inside event handler: 257ms.

    Firefox 3.5.3.
    rf, Dec 14, 2009
    #2
    1. Advertising

  3. Nik Coughlin

    dorayme Guest

    In article <lAlVm.62232$>,
    "rf" <> wrote:

    > Nik Coughlin wrote:
    > > Adding 2000 elements to the page outside an event handler takes a
    > > handful of milliseconds. Doing the same from within an event handler
    > > takes over 6 seconds. Doesn't happen in Chrome, Opera, Safari or even
    > > IE.
    > > Does anyone else see this with Firefox 3.5.5 or is it just something
    > > weird happening on my computer? I thought it might be some flaky
    > > addon, so tried it with a fresh Firefox profile, same result.
    > >
    > > Demo:
    > > http://nrkn.com/temp/ffwtf/

    >
    > Inside event handler: 257ms.
    >
    > Firefox 3.5.3.


    Inside, 360ms on my Safari, but on my FF latest Mac, 2892ms

    --
    dorayme
    dorayme, Dec 14, 2009
    #3
  4. Nik Coughlin

    Neredbojias Guest

    On 13 Dec 2009, "Nik Coughlin" <> wrote:

    > Adding 2000 elements to the page outside an event handler takes a
    > handful of milliseconds. Doing the same from within an event handler
    > takes over 6 seconds. Doesn't happen in Chrome, Opera, Safari or even
    > IE.
    >
    > Does anyone else see this with Firefox 3.5.5 or is it just something
    > weird happening on my computer? I thought it might be some flaky
    > addon, so tried it with a fresh Firefox profile, same result.
    >
    > Demo:
    > http://nrkn.com/temp/ffwtf/


    Repeated testing gave me 58ms outside/130ms inside in ff 3.5.5 on my
    setup. In ie8 it was 0/0?? Opera 10.10 seems to be 16/16 and Safari
    4.0.4 for Windows 6/59. Last but not least, SeaMonkey 1.1.16 showed
    about 16/60-80. I dumped Chrome because its js runtime is bad.

    --
    Neredbojias
    http://www.neredbojias.org/
    http://www.neredbojias.net/
    Neredbojias, Dec 14, 2009
    #4
  5. Re: Firefox 3.5.5 crapping itself on large updates inside event handlers,just me?

    Nik Coughlin meinte:
    > Adding 2000 elements to the page outside an event handler takes a
    > handful of milliseconds. Doing the same from within an event handler
    > takes over 6 seconds. Doesn't happen in Chrome, Opera, Safari or even IE.
    >
    > Does anyone else see this with Firefox 3.5.5 or is it just something
    > weird happening on my computer? I thought it might be some flaky addon,
    > so tried it with a fresh Firefox profile, same result.
    >
    > Demo:
    > http://nrkn.com/temp/ffwtf/


    FF 3.5.5:
    107ms vs. 253ms.

    Chromium 4.0.270:
    9ms vs. 103ms.

    Opera: 10.10:
    18ms vs. 23ms.

    All on Ubuntu 9.10 64bit.


    Gregor



    --
    http://www.gregorkofler.com
    Gregor Kofler, Dec 14, 2009
    #5
  6. Re: Firefox 3.5.5 crapping itself on large updates inside event handlers,just me?

    Nik Coughlin wrote:
    > Adding 2000 elements to the page outside an event handler takes a
    > handful of milliseconds. Doing the same from within an event handler
    > takes over 6 seconds. Doesn't happen in Chrome, Opera, Safari or even IE.
    >
    > Does anyone else see this with Firefox 3.5.5 or is it just something
    > weird happening on my computer? I thought it might be some flaky addon,
    > so tried it with a fresh Firefox profile, same result.
    >
    > Demo:
    > http://nrkn.com/temp/ffwtf/


    Firefox 3.5.5 Debian 64bit linux 180/520 ms respectively.
    The Natural Philosopher, Dec 14, 2009
    #6
  7. Nik Coughlin wrote:

    > Adding 2000 elements to the page outside an event handler takes a handful
    > of milliseconds. Doing the same from within an event handler takes over 6
    > seconds. Doesn't happen in Chrome, Opera, Safari or even IE.
    >
    > Does anyone else see this with Firefox 3.5.5 or is it just something weird
    > happening on my computer? I thought it might be some flaky addon, so
    > tried it with a fresh Firefox profile, same result.
    >
    > Demo:
    > http://nrkn.com/temp/ffwtf/


    "Outside event handler: 99ms
    Inside event handler: 11050ms"

    in Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091123
    Iceweasel/3.5.5 (like Firefox/3.5.5; Debian-3.5.5-1) GTB5

    ("GTB" apparently means Google ToolBar but I have a lot of other add-ons
    installed, too.)

    But: Your analysis of the situation is wrong, and your test case is flawed.

    0. There is no "page". The test case uses an (invalid) HTML document.

    It must be considered invalid HTML because there is no public
    standard that specifies its current HTML-resembling markup.
    As a result, since there is not at least one implementation of it that
    implements each feature (which is an exit criterion for a W3C Working
    Draft to become a W3C Proposed Recommendation), it is more then likely
    that different implementations exhibit different behavior already just
    because of their different level of support for this non-standard markup.

    Consequently, for the time being, Web development test cases should be
    Valid HTML 4.01 (the newest Specification with Recommendation status)
    unless a specific markup language and its DOM is being tested.

    1. It is incorrect of you to say "inside event handler" and "outside event
    handler" for two reasons:

    1. The code in which you are using `innerHTML' is event _listener_-code.
    (The built-in unmutable event handler of the DOM implementation calls
    it.)

    2. Where you display "outside event handler" is actually *within*
    the event listener for the `load' event of the `body' element.

    2. `test' is particularly bad an identifier for a property of the global
    object, especially if there is an element with ID `test' in the test
    document.

    Remember that testing frameworks may introduce such a method that would
    be overwritten, and that IDs of elements become the names of properties
    of a host object in the scope chain in MSHTML/IE and potentially other
    runtime environments that support this referencing.

    3. You are missing here that non-standard implementations like that of
    MSHTML do not pass a reference to an event object to an event listener.

    As a result, for those environments you are displaying the wrong text
    (according to your wrong definition, though) because `e' is either `null'
    or (being `undefined' in my tests with MSIE 6.0 on Wine) converts to 0,
    the same as `null' does. (See the ECMAScript Language Specification,
    Edition 5, 11.9.3, steps 3, 8 and 9, and Edition 3 Final which
    corresponds more with the tested environment but says the same.)

    4. *Most important*: You are missing here that the initial situation for the
    second test is not the same as for the first test.

    Because in the first test the `div' element with ID `test' did not have
    any children before the assignment to `innerHTML', while in the second
    test it did have 2000 SPAN children each with one text node child that
    need to be removed first.

    That need for removal, potential marking for garbage collection or
    effective garbage collection of host objects no longer being referred to,
    and re-addition would explain the greater time it takes very well, much
    better than your (provably wrong) notion of "outside" and "inside".

    The differences between runtime environments that you observed could then
    be easily attributed to a more sophisticated comparison algorithm in the
    `innerHTML' setter (that would not remove and re-add if the content is
    the same), and garbage collection using other parameters, in at least
    one of these environments. As for the former, it would be worth to take
    a look at the source code of the respective implementation; as for the
    latter, it would be worth to take a look at the size of the memory
    footprint of the user agent before and after the test.

    Bottom line: Be sure what you are testing before complaining, and avoid the
    proprietary `innerHTML' property (as if that was news around here).


    F'up2 comp.lang.javascript;
    please do not crosspost to alt.* and Usenet without.

    PointedEars
    --
    Use any version of Microsoft Frontpage to create your site.
    (This won't prevent people from viewing your source, but no one
    will want to steal it.)
    -- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)
    Thomas 'PointedEars' Lahn, Dec 14, 2009
    #7
  8. Nik Coughlin

    Nik Coughlin Guest

    "Thomas 'PointedEars' Lahn" <> wrote in message
    news:...
    > Nik Coughlin wrote:
    >
    >> Adding 2000 elements to the page outside an event handler takes a handful
    >> of milliseconds. Doing the same from within an event handler takes over 6
    >> seconds. Doesn't happen in Chrome, Opera, Safari or even IE.
    >>
    >> http://nrkn.com/temp/ffwtf/

    >
    > "Outside event handler: 99ms
    > Inside event handler: 11050ms"


    Hi Thomas.

    Thanks for that!

    Unfortunately none of the things that you've brought up (while all valid
    points) make any difference whatsoever.

    > 0. There is no "page". The test case uses an (invalid) HTML document.


    The original page from which I was having this problem used an HTML 4.01
    Strict doctype. Switching to the incompletely-specified HTML 5 doctype
    doesn't make any difference to Firefox in this instance.

    I still should have used 4.01 here. Seduced by the shorter doctype
    declaration.

    >
    > 1. It is incorrect of you to say "inside event handler" and "outside event
    > handler" for two reasons:
    >
    > 1. The code in which you are using `innerHTML' is event _listener_-code.
    > (The built-in unmutable event handler of the DOM implementation calls
    > it.)
    >
    > 2. Where you display "outside event handler" is actually *within*
    > the event listener for the `load' event of the `body' element.


    Sorry about that. I encounter this with mouse and keyboard event listeners,
    I haven't tried it with others, and as you say, it's already in the onload
    listener, which I hadn't considered. Nonetheless, there is still a massive
    difference in execution time between the two calls, which exists
    independantly of my misunderstanding of the terminology.

    > 2. `test' is particularly bad an identifier for a property of the global
    > object, especially if there is an element with ID `test' in the test
    > document.
    >
    > Remember that testing frameworks may introduce such a method that would
    > be overwritten, and that IDs of elements become the names of properties
    > of a host object in the scope chain in MSHTML/IE and potentially other
    > runtime environments that support this referencing.


    You're right, but it doesn't make any difference in this case.

    > 3. You are missing here that non-standard implementations like that of
    > MSHTML do not pass a reference to an event object to an event listener.
    >
    > As a result, for those environments you are displaying the wrong text
    > (according to your wrong definition, though) because `e' is either
    > `null'
    > or (being `undefined' in my tests with MSIE 6.0 on Wine) converts to 0,
    > the same as `null' does. (See the ECMAScript Language Specification,
    > Edition 5, 11.9.3, steps 3, 8 and 9, and Edition 3 Final which
    > corresponds more with the tested environment but says the same.)
    >


    I should have said, this code is massively reduced from the original, in
    order to make it a minimal test case. I don't care about IE in this instance
    because it's only Firefox that's giving me grief. This is the same reason
    that I'm using innerHTML instead of DOM manipulation here as well, because
    it makes no difference.

    > 4. *Most important*: You are missing here that the initial situation for
    > the
    > second test is not the same as for the first test.
    >
    > Because in the first test the `div' element with ID `test' did not have
    > any children before the assignment to `innerHTML', while in the second
    > test it did have 2000 SPAN children each with one text node child that
    > need to be removed first.


    You're assuming that I just knocked the test case together and didn't try
    anything else first - which is a fair assumption given that I gave no
    indication otherwise. I played with this problem for most of a day before
    posting, and in this case, the order makes no difference.

    > Bottom line: Be sure what you are testing before complaining, and avoid
    > the
    > proprietary `innerHTML' property (as if that was news around here).


    It's the same when using createElement, appendChild etc.

    As I said above, I've played with this already for most of a day, with many
    difference variants of the test. So far the only common thread between the
    tests seems to be that it happens if I insert a lot of elements into another
    element in response to a mouse or keyboard event. The method of insertion
    (DOM/innerHTML) doesn't seem to matter, it doesn't seem to matter whether I
    insert them one at a time or all at once either.

    Do you have any suggestions for how I might go about divining the cause and
    solution to this problem?
    Nik Coughlin, Dec 14, 2009
    #8
  9. Nik Coughlin

    Nik Coughlin Guest

    "Nik Coughlin" <> wrote in message
    news:hg6a55$6vc$-september.org...
    > "Thomas 'PointedEars' Lahn" <> wrote in message
    > news:...
    >> Nik Coughlin wrote:
    >>
    >>> Adding 2000 elements to the page outside an event handler takes a
    >>> handful
    >>> of milliseconds. Doing the same from within an event handler takes over
    >>> 6
    >>> seconds. Doesn't happen in Chrome, Opera, Safari or even IE.
    >>>
    >>> http://nrkn.com/temp/ffwtf/

    >>
    >> "Outside event handler: 99ms
    >> Inside event handler: 11050ms"

    >
    > Hi Thomas.
    >
    > Thanks for that!
    >
    > Unfortunately none of the things that you've brought up (while all valid
    > points) make any difference whatsoever.
    >
    >> 0. There is no "page". The test case uses an (invalid) HTML document.

    >
    > The original page from which I was having this problem used an HTML 4.01
    > Strict doctype. Switching to the incompletely-specified HTML 5 doctype
    > doesn't make any difference to Firefox in this instance.
    >
    > I still should have used 4.01 here. Seduced by the shorter doctype
    > declaration.
    >
    >>
    >> 1. It is incorrect of you to say "inside event handler" and "outside
    >> event
    >> handler" for two reasons:
    >>
    >> 1. The code in which you are using `innerHTML' is event
    >> _listener_-code.
    >> (The built-in unmutable event handler of the DOM implementation
    >> calls
    >> it.)
    >>
    >> 2. Where you display "outside event handler" is actually *within*
    >> the event listener for the `load' event of the `body' element.

    >
    > Sorry about that. I encounter this with mouse and keyboard event
    > listeners, I haven't tried it with others, and as you say, it's already in
    > the onload listener, which I hadn't considered. Nonetheless, there is
    > still a massive difference in execution time between the two calls, which
    > exists independantly of my misunderstanding of the terminology.
    >
    >> 2. `test' is particularly bad an identifier for a property of the global
    >> object, especially if there is an element with ID `test' in the test
    >> document.
    >>
    >> Remember that testing frameworks may introduce such a method that would
    >> be overwritten, and that IDs of elements become the names of properties
    >> of a host object in the scope chain in MSHTML/IE and potentially other
    >> runtime environments that support this referencing.

    >
    > You're right, but it doesn't make any difference in this case.
    >
    >> 3. You are missing here that non-standard implementations like that of
    >> MSHTML do not pass a reference to an event object to an event listener.
    >>
    >> As a result, for those environments you are displaying the wrong text
    >> (according to your wrong definition, though) because `e' is either
    >> `null'
    >> or (being `undefined' in my tests with MSIE 6.0 on Wine) converts to 0,
    >> the same as `null' does. (See the ECMAScript Language Specification,
    >> Edition 5, 11.9.3, steps 3, 8 and 9, and Edition 3 Final which
    >> corresponds more with the tested environment but says the same.)
    >>

    >
    > I should have said, this code is massively reduced from the original, in
    > order to make it a minimal test case. I don't care about IE in this
    > instance because it's only Firefox that's giving me grief. This is the
    > same reason that I'm using innerHTML instead of DOM manipulation here as
    > well, because it makes no difference.
    >
    >> 4. *Most important*: You are missing here that the initial situation for
    >> the
    >> second test is not the same as for the first test.
    >>
    >> Because in the first test the `div' element with ID `test' did not have
    >> any children before the assignment to `innerHTML', while in the second
    >> test it did have 2000 SPAN children each with one text node child that
    >> need to be removed first.

    >
    > You're assuming that I just knocked the test case together and didn't try
    > anything else first - which is a fair assumption given that I gave no
    > indication otherwise. I played with this problem for most of a day before
    > posting, and in this case, the order makes no difference.


    My apologies. You're completely right about point 4. I think I may be
    going crazy, I thought that I'd tried this any number of times yesterday.
    Nik Coughlin, Dec 14, 2009
    #9
  10. Nik Coughlin

    Roy A. Guest

    Re: Firefox 3.5.5 crapping itself on large updates inside eventhandlers, just me?

    On 14 Des, 07:42, "Nik Coughlin" <> wrote:
    > Adding 2000 elements to the page outside an event handler takes a handfulof
    > milliseconds. Doing the same from within an event handler takes over 6
    > seconds. Doesn't happen in Chrome, Opera, Safari or even IE.
    >
    > Does anyone else see this with Firefox 3.5.5 or is it just something weird
    > happening on my computer?  I thought it might be some flaky addon, so tried
    > it with a fresh Firefox profile, same result.
    >
    > Demo:http://nrkn.com/temp/ffwtf/


    As Thomas 'PointedEars' Lahn says "your test case is flawed", but you
    have proven a point I allready know. Firefox, in many cases sucks. A
    bare bone browser like Firefox should be best in test cases like this.
    It can't compete with Google Chrome, but it should be better than any
    other browser. There is far to many web pages that is badly written,
    so the error handling in firefox should far be better than this.

    Even if your is "your test case is flawed", the numbers is correct.
    All is happening inside a javascript body, and the rest of the
    document is all ready fixed. Firefox is just not up to the task.
    Roy A., Dec 16, 2009
    #10
  11. Nik Coughlin

    Jorge Guest

    Re: Firefox 3.5.5 crapping itself on large updates inside eventhandlers, just me?

    On Dec 14, 10:36 pm, "Nik Coughlin" <> wrote:
    > "Nik Coughlin" <> wrote in message
    >
    > news:hg6a55$6vc$-september.org...
    >
    >
    >
    >
    >
    > > "Thomas 'PointedEars' Lahn" <> wrote in message
    > >news:...
    > >> Nik Coughlin wrote:

    >
    > >>> Adding 2000 elements to the page outside an event handler takes a
    > >>> handful
    > >>> of milliseconds. Doing the same from within an event handler takes over
    > >>> 6
    > >>> seconds. Doesn't happen in Chrome, Opera, Safari or even IE.

    >
    > >>>http://nrkn.com/temp/ffwtf/

    >
    > >> "Outside event handler: 99ms
    > >> Inside event handler: 11050ms"

    >
    > > Hi Thomas.

    >
    > > Thanks for that!

    >
    > > Unfortunately none of the things that you've brought up (while all valid
    > > points) make any difference whatsoever.

    >
    > >> 0. There is no "page".  The test case uses an (invalid) HTML document.

    >
    > > The original page from which I was having this problem used an HTML 4.01
    > > Strict doctype. Switching to the incompletely-specified HTML 5 doctype
    > > doesn't make any difference to Firefox in this instance.

    >
    > > I still should have used 4.01 here. Seduced by the shorter doctype
    > > declaration.

    >
    > >> 1. It is incorrect of you to say "inside event handler" and "outside
    > >> event
    > >>   handler" for two reasons:

    >
    > >>   1. The code in which you are using `innerHTML' is event
    > >> _listener_-code.
    > >>      (The built-in unmutable event handler of the DOM implementation
    > >> calls
    > >>      it.)

    >
    > >>   2. Where you display "outside event handler" is actually *within*
    > >>      the event listener for the `load' event of the `body' element.

    >
    > > Sorry about that. I encounter this with mouse and keyboard event
    > > listeners, I haven't tried it with others, and as you say, it's alreadyin
    > > the onload listener, which I hadn't considered. Nonetheless, there is
    > > still a massive difference in execution time between the two calls, which
    > > exists independantly of my misunderstanding of the terminology.

    >
    > >> 2. `test' is particularly bad an identifier for a property of the global
    > >>   object, especially if there is an element with ID `test' in the test
    > >>   document.

    >
    > >>   Remember that testing frameworks may introduce such a method that would
    > >>   be overwritten, and that IDs of elements become the names of properties
    > >>   of a host object in the scope chain in MSHTML/IE and potentially other
    > >>   runtime environments that support this referencing.

    >
    > > You're right, but it doesn't make any difference in this case.

    >
    > >> 3. You are missing here that non-standard implementations like that of
    > >>   MSHTML do not pass a reference to an event object to an event listener.

    >
    > >>   As a result, for those environments you are displaying the wrong text
    > >>   (according to your wrong definition, though) because `e' is either
    > >> `null'
    > >>   or (being `undefined' in my tests with MSIE 6.0 on Wine) converts to 0,
    > >>   the same as `null' does.  (See the ECMAScript Language Specification,
    > >>   Edition 5, 11.9.3, steps 3, 8 and 9, and Edition 3 Final which
    > >>   corresponds more with the tested environment but says the same.)

    >
    > > I should have said, this code is massively reduced from the original, in
    > > order to make it a minimal test case. I don't care about IE in this
    > > instance because it's only Firefox that's giving me grief. This is the
    > > same reason that I'm using innerHTML instead of DOM manipulation here as
    > > well, because it makes no difference.

    >
    > >> 4. *Most important*: You are missing here that the initial situation for
    > >> the
    > >>   second test is not the same as for the first test.

    >
    > >>   Because in the first test the `div' element with ID `test' did nothave
    > >>   any children before the assignment to `innerHTML', while in the second
    > >>   test it did have 2000 SPAN children each with one text node child that
    > >>   need to be removed first.

    >
    > > You're assuming that I just knocked the test case together and didn't try
    > > anything else first - which is a fair assumption given that I gave no
    > > indication otherwise. I played with this problem for most of a day before
    > > posting, and in this case, the order makes no difference.

    >
    > My apologies.  You're completely right about point 4.  I think I may be
    > going crazy, I thought that I'd tried this any number of times yesterday.


    See: http://jorgechamorro.com/cljs/087/

    The time for inside === outside... but, if you've got FireBug enabled,
    it takes is about ~ 8x longer:

    FireBug Off:
    Outside event handler: 53ms
    Inside event handler: 52ms

    FireBug On:
    Outside event handler: 402ms
    Inside event handler: 392ms

    A slight delay also happens in Safari as well:

    WebInspector Off:
    Outside event handler: 43ms
    Inside event handler: 43ms

    WebInspector On:
    Outside event handler: 81ms
    Inside event handler: 92ms

    But not in Opera:

    DragonFly Off:
    Outside event handler: 11ms
    Inside event handler: 13ms

    DragonFly On:
    Outside event handler: 11ms
    Inside event handler: 13ms
    --
    Jorge.
    Jorge, Dec 16, 2009
    #11
  12. Nik Coughlin

    Neredbojias Guest

    Re: Firefox 3.5.5 crapping itself on large updates inside event handlers, just me?

    On 16 Dec 2009, "Roy A." <> wrote:

    > On 14 Des, 07:42, "Nik Coughlin" <> wrote:
    >> Adding 2000 elements to the page outside an event handler takes a
    >> handful

    > of
    >> milliseconds. Doing the same from within an event handler takes over
    >> 6 seconds. Doesn't happen in Chrome, Opera, Safari or even IE.
    >>
    >> Does anyone else see this with Firefox 3.5.5 or is it just something
    >> weir

    > d
    >> happening on my computer?  I thought it might be some flaky addon,
    >> so t

    > ried
    >> it with a fresh Firefox profile, same result.
    >>
    >> Demo:http://nrkn.com/temp/ffwtf/

    >
    > As Thomas 'PointedEars' Lahn says "your test case is flawed", but you
    > have proven a point I allready know. Firefox, in many cases sucks. A
    > bare bone browser like Firefox should be best in test cases like
    > this. It can't compete with Google Chrome, but it should be better
    > than any other browser. There is far to many web pages that is badly
    > written, so the error handling in firefox should far be better than
    > this.


    Bull. Ff may be slower than Chrome but Chrome is seriously flawed when
    it comes to javascript. Besides, the OP's lament is atypical and
    probably relates to something specific to his dilemma. And just how
    *should* ff (or any browser) handle errors in code or markup as well?

    > Even if your is "your test case is flawed", the numbers is correct.
    > All is happening inside a javascript body, and the rest of the
    > document is all ready fixed. Firefox is just not up to the task.


    I do agree that Mozilla should address the nagging, long-persistent
    parsing problems that still infest the browser and strive to make it
    load more quickly than it presently does rather than trying to
    incorporate new doodads which will ultimately only add to the problem.
    Nevertheless, ff is the best browser out there and has been for a long
    time.

    --
    Neredbojias
    http://www.neredbojias.org/
    http://www.neredbojias.net/
    Neredbojias, Dec 16, 2009
    #12
  13. Nik Coughlin

    Roy A. Guest

    Re: Firefox 3.5.5 crapping itself on large updates inside eventhandlers, just me?

    On 16 Des, 15:40, Neredbojias <> wrote:
    > On 16 Dec 2009, "Roy A." <> wrote:
    >
    >
    >
    >
    >
    > > On 14 Des, 07:42, "Nik Coughlin" <> wrote:
    > >> Adding 2000 elements to the page outside an event handler takes a
    > >> handful

    > >  of
    > >> milliseconds. Doing the same from within an event handler takes over
    > >> 6 seconds. Doesn't happen in Chrome, Opera, Safari or even IE.

    >
    > >> Does anyone else see this with Firefox 3.5.5 or is it just something
    > >> weir

    > > d
    > >> happening on my computer?  I thought it might be some flaky addon,
    > >> so t

    > > ried
    > >> it with a fresh Firefox profile, same result.

    >
    > >> Demo:http://nrkn.com/temp/ffwtf/

    >
    > > As Thomas 'PointedEars' Lahn says "your test case is flawed", but you
    > > have proven a point I allready know. Firefox, in many cases sucks. A
    > > bare bone browser like Firefox should be best in test cases like
    > > this. It can't compete with Google Chrome, but it should be better
    > > than any other browser. There is far to many web pages that is badly
    > > written, so the error handling in firefox should far be better than
    > > this.

    >
    > Bull.  Ff may be slower than Chrome


    I agree.

    > but Chrome is seriously flawed when
    > it comes to javascript.  Besides, the OP's lament is atypical and
    > probably relates to something specific to his dilemma.  And just how
    > *should* ff (or any browser) handle errors in code or markup as well?
    >
    > > Even if your is "your test case is flawed", the numbers is correct.
    > > All is happening inside a javascript body, and the rest of the
    > > document is all ready fixed. Firefox is just not up to the task.

    >
    > I do agree that Mozilla should address the nagging, long-persistent
    > parsing problems that still infest the browser and strive to make it
    > load more quickly than it presently does rather than trying to
    > incorporate new doodads which will ultimately only add to the problem.
    > Nevertheless, ff is the best browser out there and has been for a long
    > time.


    FF is not near the best browser out there. It is bare bone, and it
    stinks.
    Roy A., Dec 16, 2009
    #13
  14. Nik Coughlin

    Jorge Guest

    Re: Firefox 3.5.5 crapping itself on large updates inside eventhandlers, just me?

    On Dec 16, 5:54 pm, "Roy A." <> wrote:
    > (...)
    > FF is not near the best browser out there. It is bare bone, and it
    > stinks.


    FF is an excellent browser. Safari, Chrome & Opera too. The one that
    stinks is IE... :)
    --
    Jorge.
    Jorge, Dec 16, 2009
    #14
  15. Nik Coughlin

    dorayme Guest

    In article
    <>,
    "Roy A." <> wrote:

    > FF is not near the best browser out there. It is bare bone


    Do you know what the expression "bare bones" means?

    --
    dorayme
    dorayme, Dec 16, 2009
    #15
  16. Nik Coughlin

    Jorge Guest

    Re: Firefox 3.5.5 crapping itself on large updates inside eventhandlers, just me?

    On Dec 16, 9:08 pm, dorayme <> wrote:
    > In article
    > <>,
    >  "Roy A." <> wrote:
    >
    > > FF is not near the best browser out there. It is bare bone

    >
    > Do you know what the expression "bare bones" means?


    Minimum, limited, minimalist ?
    --
    Jorge.
    Jorge, Dec 16, 2009
    #16
  17. Nik Coughlin

    dorayme Guest

    In article
    <>,
    Jorge <> wrote:

    > On Dec 16, 9:08 pm, dorayme <> wrote:
    > > In article
    > > <>,
    > >  "Roy A." <> wrote:
    > >
    > > > FF is not near the best browser out there. It is bare bone

    > >
    > > Do you know what the expression "bare bones" means?

    >
    > Minimum, limited, minimalist ?



    Oh, a misunderstanding Jorge! I was just asking Roy, it was not meant to
    be a trivia quiz...

    --
    dorayme
    dorayme, Dec 16, 2009
    #17
  18. Nik Coughlin

    Roy A. Guest

    Re: Firefox 3.5.5 crapping itself on large updates inside eventhandlers, just me?

    On 16 Des, 21:31, Jorge <> wrote:
    > On Dec 16, 9:08 pm, dorayme <> wrote:
    >
    > > In article
    > > <>,
    > >  "Roy A." <> wrote:

    >
    > > > FF is not near the best browser out there. It is bare bone

    >
    > > Do you know what the expression "bare bones" means?

    >
    > Minimum, limited, minimalist ?


    Firefox is great if you need any of the many extensions. Some of these
    extensions, like NoScript, make the browser go bananas. When I tested
    NoScript the browser started to crash. I could not uninstall it or
    reinstall Firefox. I had to uninstall Firefox, delete all folders, and
    then install it again.

    IMO, Firefox without extensions should be as fast as any browser.
    Roy A., Dec 16, 2009
    #18
  19. Nik Coughlin

    Jorge Guest

    Re: Firefox 3.5.5 crapping itself on large updates inside eventhandlers, just me?

    On Dec 16, 10:05 pm, dorayme <> wrote:
    >  Jorge <> wrote:
    > > On Dec 16, 9:08 pm, dorayme <> wrote:

    >
    > > > Do you know what the expression "bare bones" means?

    >
    > > Minimum, limited, minimalist ?

    >
    > Oh, a misunderstanding Jorge! I was just asking Roy, it was not meant to
    > be a trivia quiz...


    LOL. I know. But what's the point in asking him that ?
    --
    Jorge.
    Jorge, Dec 16, 2009
    #19
  20. Nik Coughlin

    dorayme Guest

    In article
    <>,
    "Roy A." <> wrote:

    > IMO, Firefox without extensions should be as fast as any browser.


    Do you think all cars should be equally fast? You some sort of universal
    conceptual communist or something? <g>

    --
    dorayme
    dorayme, Dec 16, 2009
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. sam

    PythonService crapping out

    sam, May 12, 2004, in forum: Python
    Replies:
    1
    Views:
    335
  2. Nik Coughlin
    Replies:
    19
    Views:
    767
    Julian Turner
    Dec 18, 2009
  3. Replies:
    2
    Views:
    159
  4. Safalra
    Replies:
    2
    Views:
    126
    -Lost
    Mar 30, 2007
  5. Nik Coughlin

    Firefox 3.5.5 crapping itself (redux)

    Nik Coughlin, Dec 14, 2009, in forum: Javascript
    Replies:
    28
    Views:
    208
    Thomas 'PointedEars' Lahn
    Dec 16, 2009
Loading...

Share This Page