• Bug 20670 has been marked as a duplicate of this bug. ***

• Bug 20680 has been marked as a duplicate of this bug. ***

Assigning to Roan as Trevor's currently out on paternity leave.

Same problem for IE7. I could not edit for the whole day at all, until I read it in this bug report. Either make it widely known, or solve it

I've disabled the new edit toolbar pending fixes. :(

• Bug 20704 has been marked as a duplicate of this bug. ***

ayg wrote:

I'm guessing this is because of the overall extreme slowness of the edit toolbar construction . . . IIRC, wasn't it hanging for a second or two even on Firefox? IE has a much slower JS engine. I think I discussed this with either Roan or Trevor at some point.

(In reply to comment #7)

I'm guessing this is because of the overall extreme slowness of the edit
toolbar construction . . . IIRC, wasn't it hanging for a second or two even on
Firefox? IE has a much slower JS engine. I think I discussed this with either
Roan or Trevor at some point.

I don't know about that. It felt more like an infinite loop slowly consuming more and more resources until it ate everything the system would allow it to have and it died. Duplicate bug 20680 mentions page swapping and over a gigabyte of memory use.

rockmfr wrote:

for ( msg in configuration.buttons ) {

configuration.buttons[gM( msg )] = configuration.buttons[msg];
delete configuration.buttons[msg];

}

Find the bug! :)

(In reply to comment #9)

for ( msg in configuration.buttons ) {

configuration.buttons[gM( msg )] = configuration.buttons[msg];
delete configuration.buttons[msg];

}

Find the bug! :)

Hehehe, interesting.

This code adds new properties to the object being iterated on. Firefox doesn't loop over these newly added properties, IE8 does, causing it to grow the object indefinitely.

Fix is underway.

(In reply to comment #10)

Fix is underway.

r56588 should do it.

wikibugs wrote:

This bug was noticed in Avant 11.7 web browser too.

Environment details ::

Browser (User-Agent): Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;Trident/4.0; GTB6; Avant Browser; SLCC1; .NET CLR 2.0.50727; Media Center PC5.0; .NET CLR 3.5.21022; .NET CLR 1.1.4322; InfoPath.2; .NET CLR 3.5.30729;.NET CLR 3.0.30618)
Javascript: Enabled
Cookies Enabled: Enabled
Java Enabled: Enabled
CPU class/type: CPU Class x86
Screen Width x Height: 1280 x 800
Screen Color Depth: 32
Window Width: 585 (45.7% of 1280)
Window Height: 353 (44.1% of 800)

(In reply to comment #11)

(In reply to comment #10)

Fix is underway.

r56588 should do it.

This fix has been deployed and the toolbar reenabled. Please test with IE8 and close this bug if the issue is fixed.

(In reply to comment #7)

I'm guessing this is because of the overall extreme slowness of the edit
toolbar construction . . . IIRC, wasn't it hanging for a second or two even on
Firefox? IE has a much slower JS engine. I think I discussed this with either
Roan or Trevor at some point.

I've made some performance improvements some time after that conversation, which made it run 5.6 times faster. It's been a while, though, so I'm gonna take a look at it again to verify that recent development hasn't caused performance to degrade too much.

(In reply to comment #13)

(In reply to comment #11)

(In reply to comment #10)

Fix is underway.

r56588 should do it.

This fix has been deployed and the toolbar reenabled. Please test with IE8 and
close this bug if the issue is fixed.

I asked someone on IRC, and apparently the issue is fixed.

wikibugs wrote:

Verified. It is working.