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

N

Nik Coughlin

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/
 
R

rf

Nik said:
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.
 
N

Neredbojias

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.
 
G

Gregor Kofler

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
 
T

The Natural Philosopher

Nik said:
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.
 
T

Thomas 'PointedEars' Lahn

Nik said:
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
 
R

Roy A.

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/

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.
 
N

Neredbojias

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.
 
R

Roy A.

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?


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.
 
J

Jorge

(...)
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... :)
 
R

Roy A.

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.
 
D

dorayme

"Roy A. said:
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>
 
R

Roy A.

Do you think all cars should be equally fast?

A browser that has noting else to brag about should be fast.
You some sort of universal
conceptual communist or something? <g>

Conceptual communist? Is your world that black and white?

Anyone that have used Firefox can see that it don't live up to its
expectations.

When you install it, it has nothing to offer, when you install ad-ons
it seems ok.
 
D

dorayme

"Roy A. said:
A browser that has nothing else to brag about should be fast.

But it has things to brag about. It was regarded by many of us as a
great contrast to IE in keeping much more to the standards that are
admired by the web developing world. It does not seem to me to be
importantly slower than other browsers in surfing but I agree it is a
real slow coach starting up, it maybe thinks it is the engines in the
Titanic, maybe I don't know any more because I have it *for* its
extensions and not that much else.

Conceptual communist? Is your world that black and white?

I am afraid so, Roy, am big of B&W pics, both still and movie.
Anyone that have used Firefox can see that it don't live up to its
expectations.

So! You think it has a mind of its own! said:
When you install it, it has nothing to offer,

Perhaps nowadays, it is not as competitive. But was once.
 
J

Julian Turner

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.3
Outside : 156MS
Inside : 16 seconds (with a long period of "Not Responding").

There is another similar bug with Firefox 3.5.3 and Textareas. If you
set the value of a textarea to more than about 500 lines, you get a
similar sort of very long delay. This is an already reported bug.
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,767
Messages
2,569,570
Members
45,045
Latest member
DRCM

Latest Threads

Top