During upgrade to TWiki 4.0 half the machines at our office crashed just by looking at a TWiki topic.
Major disaster.
I did some analysis and found that it is the file prototype.js that causes the trouble. I removed it and all could see TWiki 4 pages again.
I cannot see what I loose when it is not there.
I tried to go to the homepage of this file
http://prototype.conio.net/ and downloaded an older version 1.3.1. It also fails. Then I downloaded version 1.2.0 and it works. I have no idea why this happens or what good prototype.js does but versions 1.3.1 and 1.4.0 both are show stoppers to running TWiki 4.0 in our offices.
I cannot reproduce this at my home installation probably because my IE and Win XP are more up to date than the one at our office.
This is a serious issue. If prototype.js does so little that I cannot even see when it if missing I propose we do not use it. It is also a bit of a monster js file to load into the browser.
KJL
prototype 1.3.1 was in the TWiki 4.0.0 release, then in /pub/TWiki/PatternSkin/.
Did this TWiki release already produce a crash?
BTW prototype is distributed with Ruby on Rails. Link:
http://prototype.conio.net/
AC
I did not install TWiki 4.0.0. I am installing 4.0.1 tonight. Before I have run a test installation here but my own PC is not among the 50% that fails.
KJL
So what operating system and browser versions do the crashing computers have?
AC
This is the great mystery. We all have the same OS and browser. Win XP, SP1 (not SP2) + misc security updates. Browser is 6.0.2800.1106.xpsp2.050301.1526CO. on all our machines. OS and browser versions get controlled centrally in Motorola via SMS. The only difference is what other applications we have installed on our machines.
KJL
I've updated prototype.js to a newer version (1.5.0_pre0). I am curious if this one works better.
AC
No. It did not help at all. Machines still crash the minute they load any page.
KJL
Blame might be on certain BHOs / browser extenstions, this page has more:
http://www.aplus.co.yu/scripts/ie6-scriptaculous-quickfind-bho-pure-virtual-function-call-error-ie-crash/
--
SP
I have been testing more. But not done. I found that other people in the same team and same floor do not have the problem. It is 4 people sitting in a group next to each other.
"Manage add-ons" menu point in IE requires SP2. We are still on SP1. Silly
If I go to view objects under temporary files (misleading placement) one guy had some strange object called {9f1c11aa-197b-4942-ba54-47a8489bb47f} which I do not have. I will try and see what the 3 other guys have.
I will need to find out how to see the BHOs on a SP1 XP machine. Google here I come.
KJL
After the prototype.js was moved to a Contrib is also moved position in the TWiki tree. I had forgotten when I upgraded Monday evening.
It meant that I ran with the new prototype.js instead of the old 1.2. That created lynch mood at Motorola. I had emails from managers complaining that their departments could not work anymore because their access to TWiki was gone with the IE crashing each time.
When a group leader then suggested they used Firefox it started excalating up the manager ladder while I was away from my email.
When I came back I found out why and replaced the prototype.js with version 1.2.0 and sent an email around that explained that it was my mistake.
What the episode showed was that many more then the 4 I had reports from last week have the problem. I even had angry emails from our Polish office you also use the TWiki in Copenhagen. So it is now different departments that have had the problem. The new ones are software developers with nothing in common with the program manager staff that first had the problem last week.
I have been investigating a few more of the strange computers. I did not find any common pattern that explains the error. So it may be more than one browser helper object that causes the trouble. I will still try and investigate more why it happens. What makes it difficult is that I do not have the problem on my computer and I cannot do anything on the others unless they sit besides me because you need to be an administrator to remove BHOs.
For now I strongly advice to downgrade the prototype.js to max version 1.2.0. And maybe avoid it completely.
KJL
But that would mean that these users wouldn't be able to use Ruby on Rails apps as well. Could you try Basecamp (you can set up a free account, easy)? That web app uses the latest prototype as well.
The problem is still that we don't know what javascript we
can use if we replace prototype.
Another option would be to use the recently released Yahoo javascript libraries, for instance the
Connection Manager
AC
OK, I've extracted the functions that I need from prototype that I want to keep for TWiki. I have 2 options:
- Create a new contrib: PrototypeMiniContrib - is it worth a contrib for this?
- Add the js to twiki.js - some js will be duped when users add PrototypeContrib
AC
Scenario 2: SVN 8866
Now one more test from Kenneth is needed.
AC
Aargh.
Item1702. It is virtually impossible to pluck from prototype.js, everything is interconnected. Removing it altogether. Prototype no more.
AC
Thanks for more good work. I will bring my Motion TWiki up to HEAD and have the colleagues with the problem to connect to it and verify that all is fine. You will have an answer Thursday afternoon or night.
KJL
I am happy to confirm that we have tested the new javascript solution on 4 of the machines that crashed with prototype.js and they can view a TWiki site with the latest solution without problems.
So go ahead with this for 4.0.2.
KJL
This seems to be "merged" into the TWiki4 branch, as I couldn't find any trace of prototype in twiki.js. Perhaps Arthur's merges already covered this.
Can you verify and close the item, Kenneth ?
RA
Verified and closed
CC
Closed with the release of 4.0.2
KJL