Uploaded image for project: 'Confluence Data Center'
  1. Confluence Data Center
  2. CONFSERVER-36710

"Edit in Office" button opens attachments twice after using the file browser preview

XMLWordPrintable

      In Confluence 5.7, the "Edit in Office" button in the Attachments macro should cause a file to open once.

      However, after accessing any part of the file browser (such as by clicking on any preview on the page), the Edit in Office button now launches the attachment twice.

      This is shown in the attached screencap. In the first pass, the page has just been loaded and the Excel file is launched normally.

      In the second half of the video, after viewing a preview, clicking the Edit in Office button launches the file...but two copies appear, which can be really confusing for the user.

      The problem seems to stem from the fact that the Office Connector is binding the "onclick" event for "Edit in Office" twice: once in com.atlassian.confluence.extra.officeconnector:editinoffice, and a second time in com.atlassian.confluence.extra.officeconnector:file-viewer-plugin.

      The latter binding appears to have been designed to target the edit-in-office link in the "..." dropdown menu within the file browser itself, but the jQuery selector for "office-editable" class is DOM-wide and not scoped to the file browser, so it ends up attaching the onclick handler to all elements on the page, including those in the Attachments macro that already have their own onclick handler already set up:

      /* module-key = 'com.atlassian.confluence.extra.officeconnector:file-viewer-plugin', location = 'templates/extra/editinword/editInOffice.js' */
AJS.toInit(function ($) {
    var contextPath = AJS.Data.get('context-path');

    var editInOfficeLinks = $('#edit-in-word, #edit-in-word-pathauth, a.office-editable, a.office-editable-pathauth');
    editInOfficeLinks.click(function (e) {
        [...]

      Note that this bug also causes problems with third-party plugins that have a <dependency> on the Office Connector's file-viewer-plugin component, since the dependency can also cause this behavior to appear every time the page is loaded, without even needing to access the file previewer.

      Workaround

      The following workaround should resolve the problem until the issue is able to be formally fixed in an upcoming version of the product.

      1. Navigate to Confluence Admin > Manage Add-Ons > System (in the dropdown)
      2. Locate the Office Connector plugin and expand it
      3. Expand the modules, locate the module labeled "file-viewer-plugin" and disable it.
      4. Try the Edit in Office functionality again and let us know how it goes

        1. EditInOfficeProblem.mov
          9.03 MB

            [CONFSERVER-36710] "Edit in Office" button opens attachments twice after using the file browser preview

            Scott Dudley [Inactive] added a comment -

            paul.labarbera, I see that you found this ticket too in addition to CONF-38322!

            The only functionality provided by the "file-viewer-plugin" module is the addition of "Edit in Office" link within the "..." dropdown in the file viewer when viewing Office files. If you disable that module, the Edit in Office option will disappear from within the file viewer, but there should be no other impact. (Given how well this option is hidden, I am doubtful that many people are using it anyway!)

            Scott Dudley [Inactive] added a comment - paul.labarbera , I see that you found this ticket too in addition to CONF-38322 ! The only functionality provided by the "file-viewer-plugin" module is the addition of "Edit in Office" link within the "..." dropdown in the file viewer when viewing Office files. If you disable that module, the Edit in Office option will disappear from within the file viewer, but there should be no other impact. (Given how well this option is hidden, I am doubtful that many people are using it anyway!)

            Paul LaBarbera added a comment -

            Does anyone know what other functionality we lose if we turn off "file-viewer-plugin"?

            Paul LaBarbera added a comment - Does anyone know what other functionality we lose if we turn off "file-viewer-plugin"?

            Paul LaBarbera added a comment -

            Is this going to be fixed for server versions? This bug is appearing for me in Confluence 5.8.5.

            Paul LaBarbera added a comment - Is this going to be fixed for server versions? This bug is appearing for me in Confluence 5.8.5.

            Scott Dudley [Inactive] added a comment -

            Hi shaffenden. I see that this is marked as resolved for OD. Is there a known fixversion for Confluence Server too?

            Thanks!
            Scott

            Scott Dudley [Inactive] added a comment - Hi shaffenden . I see that this is marked as resolved for OD. Is there a known fixversion for Confluence Server too? Thanks! Scott

            Stephen Gramm added a comment -

            This trick is also working for me.

            Stephen Gramm added a comment - This trick is also working for me.

            Roger Oberg added a comment -

            I can confirm that disabling module "file-viewer-plugin" stops the double-opening bahavior. Great and simple workaround!

            Roger Oberg added a comment - I can confirm that disabling module "file-viewer-plugin" stops the double-opening bahavior. Great and simple workaround!

            Scott Dudley [Inactive] added a comment - - edited

            roger.oberg, after further thought, I just realized that there is a workaround for the core Confluence bug. This workaround will fix this issue across the board (regardless of whether the user accesses the file browser or not).

            Note that this change will eliminate the ability to click "Edit in Office" from within the "..." menu of the file browser, but it does stop the double-opening behavior from occurring everywhere:

            • Go to Toolgear->Manage add-ons
            • Select the "System" value in the dropdown
            • Click on "Office Connector plugin" to expand it
            • Click the "+" next to "xx of 91 modules enabled" to expand the module list
            • Find the module labeled "file-viewer-plugin" and disable it.

            Scott Dudley [Inactive] added a comment - - edited roger.oberg , after further thought, I just realized that there is a workaround for the core Confluence bug . This workaround will fix this issue across the board (regardless of whether the user accesses the file browser or not). Note that this change will eliminate the ability to click "Edit in Office" from within the "..." menu of the file browser, but it does stop the double-opening behavior from occurring everywhere: Go to Toolgear->Manage add-ons Select the "System" value in the dropdown Click on "Office Connector plugin" to expand it Click the "+" next to "xx of 91 modules enabled" to expand the module list Find the module labeled "file-viewer-plugin" and disable it.

            Scott Dudley [Inactive] added a comment - - edited

            We (at Arsenale Support) are working with Roger offline regarding the issue he mentioned with Lockpoint locks getting stuck (we can't reproduce the issue), but in terms of the Lockpoint and the double-opening issue described here:

            It is true that Lockpoint exacerbates the double-opening problem because Lockpoint 1.6 includes a dependency on the Office Connector, and this dependency causes this double-opening behavior to occur for every page, as opposed to happening only after the user has used the Confluence file browser.

            We do, however, have a partial workaround that can reduce the frequency of this issue for Lockpoint 1.6. (UPDATE: the core Confluence workaround in the next comment below is probably more appropriate for most users than this one.)

            Go to Toolgear->Add-ons, click on Lockpoint, expand the “68 of 68 modules enabled” section, and disable the module named "Office Connector Transitive Dependency”. You then need to re-load the page containing the attachments.

            This should prevent the document from being launched twice with Edit in Office, at least until a user accesses the file browser. The main downside to disabling the component is that, within the file browser, the “Edit in Office” option may still be shown in the “…” menu option even for files that are locked by other users. (Lockpoint is supposed to hide the Edit in Office link if the file is not available for editing.) In this scenario, clicking the Edit in Office link within the file browser will still display an error indicating that the file is in use (when the Office app opens), so it’s not the end of the world and it should not cause edit conflicts, but it is a less-than-ideal UI.

            However, Confluence will still revert back to its double-opening behavior after the user leaves the file browser, and there are no Lockpoint workarounds for this core Confluence behavior.

            Scott Dudley [Inactive] added a comment - - edited We (at Arsenale Support) are working with Roger offline regarding the issue he mentioned with Lockpoint locks getting stuck (we can't reproduce the issue), but in terms of the Lockpoint and the double-opening issue described here: It is true that Lockpoint exacerbates the double-opening problem because Lockpoint 1.6 includes a dependency on the Office Connector, and this dependency causes this double-opening behavior to occur for every page, as opposed to happening only after the user has used the Confluence file browser. We do, however, have a partial workaround that can reduce the frequency of this issue for Lockpoint 1.6. ( UPDATE : the core Confluence workaround in the next comment below is probably more appropriate for most users than this one.) Go to Toolgear->Add-ons, click on Lockpoint, expand the “68 of 68 modules enabled” section, and disable the module named "Office Connector Transitive Dependency”. You then need to re-load the page containing the attachments. This should prevent the document from being launched twice with Edit in Office, at least until a user accesses the file browser. The main downside to disabling the component is that, within the file browser, the “Edit in Office” option may still be shown in the “…” menu option even for files that are locked by other users. (Lockpoint is supposed to hide the Edit in Office link if the file is not available for editing.) In this scenario, clicking the Edit in Office link within the file browser will still display an error indicating that the file is in use (when the Office app opens), so it’s not the end of the world and it should not cause edit conflicts, but it is a less-than-ideal UI. However, Confluence will still revert back to its double-opening behavior after the user leaves the file browser, and there are no Lockpoint workarounds for this core Confluence behavior.

            Roger Oberg added a comment - - edited

            This issue casues problems with the plugin "Arsenale Lockpoint" aswell it seems. Now it cannot detect when the file should be automatically unlocked (when closing word). And doing a manually unlock causes the error msg:

            The following error(s) occurred:
            •The file test2.docx was locked with a WebDAV client (such as an Office application) on 2015-03-06 10:31 and the file remains locked.

            If you are sure that the file is no longer in use (and the Office application is closed), you can force an unlock of this file.

            Roger Oberg added a comment - - edited This issue casues problems with the plugin "Arsenale Lockpoint" aswell it seems. Now it cannot detect when the file should be automatically unlocked (when closing word). And doing a manually unlock causes the error msg: The following error(s) occurred: •The file test2.docx was locked with a WebDAV client (such as an Office application) on 2015-03-06 10:31 and the file remains locked. If you are sure that the file is no longer in use (and the Office application is closed), you can force an unlock of this file.

              rsu raymo
              7c60ab039b09 Scott Dudley [Inactive]
              Affected customers:
              7 This affects my team
              Watchers:
              10 Start watching this issue

                Created:
                Updated:
                Resolved: