Browser lock-ups with Content Explorer

Has anyone else experienced these?

On some systems and some browsers, we see an effect in which you can edit one, sometimes two or three, items, and then the browser basically locks up, consuming all available system resources. Usually this results in a frozen and partly-loaded or partly-refreshed editing form. The only option is to kill the browser process. We have seen this on Firefox, on a system on which IE7 works fine, but now some weeks later it seems to have cleared on Firefox on that PC. However, an external user is now experiencing it on IE7.

Our staff use a standard XP desktop, which makes differences between users particularly hard to understand. Our externals use whatever they have locally, but in the case above it is a new Vista system with plenty of resources. Therefore the behaviour looks like conflicts affecting Content Explorer. For example, has anyone come across problems with anti-virus packages, Firefox Extensions, IE add-ins and settings, or other utilities and add-ons, that conflict?

We do all the obvious things, such as keeping systems and Java up to date.

Thanks for any ideas.

Hi,

I can’t say I’ve experienced your exact issue, but I have seen the AV struggling with the browser for resources.

We use McAfee VirusScan Enterprise 8.5i. When loading the JRE under HTTPS the browser appears to freeze while loading the JRE, but when looking at the Task Manager the AV is going nuts consuming CPU cycles as is the browser. This only happens under HTTPS though. If I wait long enough it will finally load (time varies from 1-3 minutes), but during that time the browser does appear frozen. The JRE loads in a few seconds under HTTP. This is definitely an example of AV not playing nice with a component used by Rhythmyx.

We’re not sure if it’s something we need to address with our AV configuration or the JRE, but it’s not a priority for us at the moment.

Perhaps take a step backwards on the version of the JRE. You may find a previous version that works better while you hunt for a solution to the problem.

Thanks. I’m interested that you saw that with McAfee. Please post again if you discover more.

We have a mixture of internal editors (on a well-controlled standard desktop) and externals (on whatever they choose to use). We have seen the issue appear on both, but most lately from an external who uses Vista and McAfee.

That said, he tried on a second machine with XP and McAfee and did not reproduce the lock-ups - so it is far from proven that McAfee is conflicting.

I can’t easily try this as we don’t use McAfee internally. When we have seen the effect here it has been just the browser and not the AV that was consuming 95% or more of available resources. Sometimes after waiting several minutes it will continue, but sometimes not.

I’d appreciate any more experience from others. We are also looking at the latest EditLive patch as a means of reducing its resource utilitisation.

Here at Percussion, we also use McAfee VirusScan enterprise version 8.0.

We have seen some issues with earlier versions of McAfee, but not recently. It appears to be an issue with McAfee and Java, not something that is Percussion or Ephox specific.

I don’t think I’ve tried using SSL for this recently. It would be interesting to hear from other people who have this issue.

We’re not using SSL either.

I recognise that we could be looking at Java issues rather than/as well as Rhythmyx ones. Our problem is that we don’t have much internally that uses Java, and I don’t detect that our externals do either. Therefore from a user perspective Java and Rhythmyx are inseparable.

The one user reporting McAfee has V11.2 antivirus and personal firewall V8.2. The further indication that conflicts are possible is helpful. However, again, we have seen this on internal systems with different AV, firewall and browser set-ups, so I don’t want to focus totally on McAfee.

Obviously the ideal would be to find a set of things to look for or avoid, owing to the prospect of numbers of external editors starting on the system and some of them encountering similar issues.

In the meantime we are going to get on with that patch.

We have the same problem with our systems (Rhythmyx v6.1) - we also have McAfee 8.5 running on a standard XP SP2 desktop. We’ve got users with a variety of Java versions and browsers who all experience the same problems.

There doesn’t seem to be any consistency to the error - some days it’ll not lock but on others it’ll break a dozen times. I keep meaning to log it with support as it’s causing a lot of our users a lot of aggravation as they are not familiar with killing processes in the operating system.

Our problem tends to centre on Ephox with its status bar getting to a point, quite often 78%, and then locking up.

I’d be interested in any solutions that anyone may have.

We are also experiencing issues with IE locking up during content editing - the ephox control loads to 75 sometimes 95 percent and then becomes unresponsive. We are running 6.5 in a brand new implementation. This is frustrating our users to no end as they’re trying to enter content and have to keep restarting their browser sessions. We’ve updated to the latest java version (1.6.0_3). We also are using McAfee 8.0.0.109. Any assistance that can be provided in resolving this would be very greatly appreciated.

When Ephox seems to lock up, can you open the Java console for the browser and see if any exceptions are noted and post them here.

have you tried (downgrading to) java 1.5.0_14 ?

there are a number of known issues with java 6 (1.6)

The Java patch fixed this issue for me.