Yesterday I saw Webtop 6.8.2 was released, and as this was great news because this version was supposed to remove Java applets once and for all. While most of us though that removing applets would imply moving to HTML5, EMC has decided to implement an intermediate solution 😦

Webtop 6.8.2 will prompt users to install a browser extension first time you log in:

In Firefox the extension will be installed, and in Chrome user will be redirected to the Chrome Web Store:

After installing the extension, the first time users try to download something they’ll be prompted to install a local application that will handle the transfers (WebSockets I presume).

Good news: Now you don’t need to fight with Java/browser combination

Bad news: Users have to perform operations. Not the cleanest solution (IMHO).

Bonus: Now importing files is really not-user friendly:

1. File -> import
2. Ugly Java window will pop-up over the import container asking for files to import
3. Select files/folders, press ok and… nothing happens. You are kept in a blank container window with “Next” and “Finish” buttons and no indication whatsoever if the files are been/have been uploaded or what is going on.

Since Chrome 42 was released, NPAPI plugins are disabled by default and the support for these plugins will be completely removed in Chrome 45 (expected to be released in September). This means no more UCF in Chrome. So, what will EMC do?

Considering that in the latest Webtop release (6.8) only 3 browsers are supported (IE 10/11, Firefox 24.6 and Safari 6.1.4/7.0.4) most likely nothing. Besides, this move from Google can “help” EMC to keep pushing D2/xCP to customers and reinforce the “Webtop won’t be developed anymore” message. But, what does this move means for current users?

I think sooner or later Java will be removed from every browser. Spartan/Edge won’t even support Microsoft’s own ActiveX, and considering I don’t see Oracle developing a new plugin based on PPAPI (which by the way is not a standard protocol and it’s only supported by Chrome and Opera), so it wouldn’t surprise me to see Mozilla announcing they’re dropping support for NPAPI in future releases.

This means that by the end of this year, there will be most likely 6 browsers (Chrome, IE, Spartan/Edge, Firefox, Opera, Safari) and EMC will provide support only for 3 of them (2 being “obsolete”, IE and Firefox 24.x). And even though we know that (until now) even without being officialy supported webtop (mostly) works with any browser, this won’t be the case much longer (as long as you need to transfer content).

In the end, we’ll have to deal with angry users that like Chrome because it’s cool and because they don’t want to use the corporative IE6/7/8 (not supported also) or the company-branded browser they’ve come to hate through the years.

Until know, my “usual” hack for matching IE/Firefox performance with Chrome’s was mainly disabling the ucfinvoker in the main component and any plugin not used in app.xml. This makes webtop to load the ucf libraries only when needed instead of doing it every time the user login so it seems that the main component loads faster (yes, I’m cheating :D). And I’m also considering disabling UCF transfer for view action and leaving UCF enabled only for edition, so read-only users won’t be disturbed with error messages/warnings when using Webtop.

However, there’s still the problem of dealing with the users that cannot use their preferred browser to do their job and convincing them that is not Documentum’s fault…

Edit: Even better solution (removing UCF in chrome)

Extend the evaluator class defined in the action (LaunchViewEvaluator, LaunchEditEvaluator, ContentTransferLaunchComponentEvaluator, etc.) with:

    public class ContentTransferLaunchComponentEvaluator extends com.documentum.web.contentxfer.ContentTransferLaunchComponentEvaluator {
        public String evaluate(String strName, String strAction, IConfigElement config, ArgumentList arg, Context context, Component component){
            HttpServletRequest request = (HttpServletRequest)component.getPageContext().getRequest();
            String userAgent = request.getHeader("User-Agent");  

            if (userAgent!=null && userAgent.length()>0 && userAgent.indexOf("Chrome")>=0) {
                    return "http";
            }
            return super.evaluate(strName, strAction, config, arg, context, component);
        }
    }

Edit v2: The best solution:

1. Check PanfilovAB post about Component Qualifiers and check the request listener class: Component qualifier

2. Create the following class:

    public class CustomContentTransferConfig extends com.documentum.web.contentxfer.ContentTransferConfig {
        @Override
        public String getContentTransferMechanism(){
            String userAgent=ComponentRequestListener.getBrowserUserAgent();  

            if (userAgent!=null && userAgent.length()>0 && userAgent.indexOf("Chrome")>=0) {
                return "http";
            }
            return super.getContentTransferMechanism();
        }
    }

3. Modify webtop\WEB-INF\classes\com\documentum\web\contentxfer\ContentTransferConfig.properties with:

configReaderClass=CustomContentTransferConfig

Done!

Here is an updated version from previous post (UCF troubleshooting) with some more/new tips:

UCF installation paths:

• Windows XP: C:\Document and Settings\[user]\Documentum
• Windows Vista/7/8: C:\Users\[user]\Documentum
• Linux: ${home}/Documentum

Timeout/browser/jre problems:

• Check the supported environment tables in webtop/da release notes. Most JRE versions will work even when aren’t supported, but you’d better check if the supported version works.
• If not needed, disable ACS and BOCS.
• If using a proxy, add host’s IP and hostname to the proxy exceptions
• Add Webtop url to the browser’s pop-up blocker exceptions.
• In case the UCF aplet cannot be installed, try disabling DEP protection
• Delete the local UCF installation and try a clean installation
• [Firefox] Check Java plugin is enabled. Mozilla automatically disables outdated JRE plugins.
• [IE] Check Sun/Oracle JRE is the default JRE, disable ActiveX filtering, and check Java plugins are enabled in the Manage Addons window.
• [IE/Firefox] If you are working with a 64 bit SO, check you’re using a 32bit browser with 32bit JRE. 64 bit browser/JRE with UCF is probably a bad idea.
• [IE] Check Java integration with browsers is enabled.
• [Java control panel] Delete JRE cache
• [Java control panel] Disable the next generation Java plug-in.
• [Java control panel] Disable verification of mixed code security.
• [Java control panel] Check “Direct Connection” is selected in Network Settings (vishnu.music)
• [UCF configuration] If UCF keeps throwing a timeout, disable the IPv6 compatibility by changing the following line in ucf.installs.config.xml (located in ${Documentum_UCF}/ucf/config)

<option value=”-Djava.net.preferIPv6Addresses=true“/> to <option value=”-Djava.net.preferIPv6Addresses=false“/>

JRE 7u51+ workaround:

In Java control panel check that:

• Security is set to medium
• Your application server url is listed under the exception site list

You should also check the thread The specified discussion was not found. by PanfilovAB if you’re having issues with multiple Java versions

Manual installation:

• You can install the UCF applet in the client computer manually, just run the folowing bat script:

set DIRNAME=%~dp0%lib\
set URLDIR=%DIRNAME:\=/%
java -cp %DIRNAME%ucfinit.jar com.documentum.ucf.client.install.TestInstall "file:///%URLDIR%" "ucf.installer.config.xml"

This is the structure/files you need for this script to work (you can find these files in /wdk/contentXfer/):

UCFTestInstall.bat
\lib
\lib\ExJNIAPI.dll
\lib\ExJNIAPIGateway.jar
\lib\jacob.dll
\lib\jacob.jar
\lib\ucf-ca-office-auto.jar
\lib\ucf-client-installer.zip
\lib\ucf.installer.config.xml
\lib\ucfinit.jar
\lib\UCFWin32JNI.dl

And don’t forget to check UCF logs if you’re still having problems

As stated here: 914690 – In Firefox 24 and following, mark all versions of Java as unsafe every java version is going to be marked as unsafe by default, meaning you’ll have to manually enable/allow every time you use any java object (If you’re on Firefox beta channel you should realized by now that something was “wrong” when using webtop/ucf transfer with the latest versions: You have to manually allow actions like selecting a file to check-in or every UCF operation)

You probably know by now what this means to Webtop… oh God, when I though I couldn’t hate more UCF, now this… Am I the only one that *loves* having to deal with end-users/customers that take for granted that this Java-Browser compatibilities are a “Documentum problem”…

PS: go HTTP transfer mode!