Mozilla To Drop Support For All NPAPI Plugins In Firefox 52 Except Flash

What does this mean to Documentum? Well, if your Webtop/D2 is using applets (UCF), starting March, you’ll only be able to use it with IE11 and older versions, as no other major browser (actually, Firefox is the only “major” browser that still allows NPAPI plugins, but this is due to their slow pace of development) will allow NPAPI plugins (Java).

D2 (and Webtop and xCP) CTF

CTF (Content Transfer Framework) is how EMC Dell calls their “new UCF”. It works as a browser extension, and is the same extension you’ve used for the latest version of Webtop (new functionality getting first to Webtop? LOL). And this mode is not the default (why?) so you’ll need to change it in the file of D2.

Also, this extension will generate some “index” files on the folder where you download files:

  • .checkout.xml
  • .d2_edit_storage.json
  • .d2_view_storage.json
  • .view.xml

That contain object names, ids, operation performed, and folder paths of the files transferred.

Tested on latest Firefox Nightly x64 and Chrome.

FYI, I’m pasting the “wonderful” ASCII compatibility matrix provided by Dell in the configuration file:

#¬†¬†¬†¬† +——————-+——+——+——+——+
#     | Browser:OS \ Mode | Thin | Java | ctf  | Note |
#¬†¬†¬†¬† +——————-+——+——+——+——+
#     | IE 11             | yes  | yes  | yes  |      |
#¬†¬†¬†¬† +——————-+——+——+——+——+
#     | Edge              | yes  | NO   | NO   | (1)  |
#¬†¬†¬†¬† +——————-+——+——+——+——+
#     | Firefox           | yes  | yes  | yes  |      |
#¬†¬†¬†¬† +——————-+——+——+——+——+
#     | Chrome            | yes  | NO   | yes  | (1)  |
#¬†¬†¬†¬† +——————-+——+——+——+——+
#     | Safari:Mac_OSX    | yes  | yes  | yes  |      |
#¬†¬†¬†¬† +——————-+——+——+——+——+
#     | Safari:Mac_IOS    | yes  | NO   | NO   | (2)  |
#¬†¬†¬†¬† +——————-+——+——+——+——+
# Notes:
# (1) Chrome and Edge do not support java applets, and Edge does not support the CTF plugin.
#     D2 will fallback to thin client mode appropriately when java or ctf has been
#     specified in the value of the browser.plugin.mode setting as described above.
# (2) If browser.plugin.mode contains java or ctf, then D2 will silently continue to run in
#     thin client mode. Safari running on Mac_IOS does not support the java or ctf plugin.

  • Prompt for installing the extension:


  • View content prompt:


  • Edit:


  • Check in:


WebTop’s new content transfer mechanism

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.

Chrome dropping NPAPI (Java) support and UCF

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 {
        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\ with:



UCF troubleshooting v2

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 (
  • [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=”“/> to <option value=”“/>

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\
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/):


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

Firefox 24 and future versions will block every Java object by default

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!