none
Word 2016 Add-in Linked images using HTML insert not displayed in online Word RRS feed

  • Question

  • I'm developing an add-in for Word 2016 and online Word. 

    In it, on the desktop version of Word, if I insert html content using document.setSelectedDataAsync with an image tag and URL to an image on our server, the image displays on the desktop version of Word.  If I save the same file to OneDrive and show it on the online version of Word, the image does not display.  If I wrap the image in an <a> tag with a link, the link shows up when I hover over the image in the online version of Word, but the image never appears. If I modify the file, save it back to OneDrive, open the file in the desktop version of Word, the image does appear.  

    Since I'd prefer to do html embed with hyperlinks, I also tried creating an <img> tag with a local base64 DataURI for the image, while perfect valid, that failed to display in either the desktop or online version of Word.

    I'd like this functionality to allow for both live updating of images in documents as well as linking to our web app to edit the images.

    If instead I get the actual image, convert it to a Base64 encoded image and insert an image (coercing the type in document.setSelectedDataAsync to image), the image displays on both desktop and online, but we lose the auto-updating and hyperlinking features. 

    Trying the same thing with other add-ins, for example the Wikipedia add-in for Word, I see exactly the same issue. If you use the plug-in on the desktop version of word and add an image from the plugin, then save the file to OneDrive, then open the file on the online version of Word, the image will not display.

    It seems to me that there is a fundamental issue with roundtripping html-based content with external links from the desktop version of Word 2016 to the online version.

    Can anyone verify if they are seeing this as well?

    Wednesday, August 10, 2016 9:56 PM

All replies

  • I'm developing an add-in for Word 2016 and online Word. 

    In it, on the desktop version of Word, if I insert html content using document.setSelectedDataAsync with an image tag and URL to an image on our server, the image displays on the desktop version of Word.  If I save the same file to OneDrive and show it on the online version of Word, the image does not display.  If I wrap the image in an <a> tag with a link, the link shows up when I hover over the image in the online version of Word, but the image never appears. If I modify the file, save it back to OneDrive, open the file in the desktop version of Word, the image does appear.  

    Since I'd prefer to do html embed with hyperlinks, I also tried creating an <img> tag with a local base64 DataURI for the image, while perfect valid, that failed to display in either the desktop or online version of Word.

    I'd like this functionality to allow for both live updating of images in documents as well as linking to our web app to edit the images.

    If instead I get the actual image, convert it to a Base64 encoded image and insert an image (coercing the type in document.setSelectedDataAsync to image), the image displays on both desktop and online, but we lose the auto-updating and hyperlinking features. 

    Trying the same thing with other add-ins, for example the Wikipedia add-in for Word, I see exactly the same issue. If you use the plug-in on the desktop version of word and add an image from the plugin, then save the file to OneDrive, then open the file on the online version of Word, the image will not display.

    It seems to me that there is a fundamental issue with roundtripping html-based content with external links from the desktop version of Word 2016 to the online version.

    Can anyone verify if they are seeing this as well?

    • Merged by David_JunFeng Friday, August 12, 2016 5:56 AM duplicated case
    Wednesday, August 10, 2016 9:58 PM
  • >>>Trying the same thing with other add-ins, for example the Wikipedia add-in for Word, I see exactly the same issue. If you use the plug-in on the desktop version of word and add an image from the plugin, then save the file to OneDrive, then open the file on the online version of Word, the image will not display.<<<

    According to your description, I have tried to reproduced this issue, unfortunately, I am not able. So I suggest that you could provide more detail steps and screenshot, that will help us reproduce and resolve your issue.

    Thanks for your understanding.
    Thursday, August 11, 2016 7:51 AM
  • Hi Seisiuneer,

    I made a test with your description, and I could reproduce your issue.

    For this issue, I would suggest you submit a feedback in the link below:

    http://officespdev.uservoice.com

    Best Regards,

    Edward


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.


    Thursday, August 11, 2016 9:36 AM
  • You can test it right now using Word 2016 on the desktop and the Wikipedia add-in.

    Launch Word 2016 on the desktop and install the Wikipedia add-in from the Store.

    Use the Wikipedia add-in to add a photo to your document.

    Save the document in Microsoft OneDrive.

    Run the online version of Word.

    Open the document from OneDrive.

    What I see on multiple systems, both Windows 7 and 10 as well as Mac is a frame the size of the picture with a "This picture can't be displayed" message. 

    The forum system isn't letting me attach a screenshot
    Thursday, August 11, 2016 3:11 PM
  • I'll submit the bug report. Thanks!
    Thursday, August 11, 2016 3:12 PM
  • Hi Seisiuneer,

    Thanks very much for your detail steps to help us reproduce this issue. I’m able to reproduce this issue now. Based on my testing, this issue happen not only Word 2016 but alse Word 2013, so I suggest that you could submit any feedback to Office Dev UserVoice:

    https://officespdev.uservoice.com/

    Thanks for your understanding. 
    Friday, August 12, 2016 1:23 AM