2
votes

Ok, this is a tricky one because it involves so many variables:

  • a webdav server. I used the webdav .net server:http://www.webdavsystem.com/server
  • browsers: chrome 28.0.1500.95 m, firefox 23, IE 9
  • the office authorization plug-in for NPAPI browsers. I have MS Office 2010 SP2 14.0.7015.1000 (32-bit). The versions of the plugin dlls are: C:\Program Files (x86)\Microsoft Office\Office14\NPAUTHZ.DLL - 14.0.4730.1010, C:\Program Files (x86)\Microsoft Office\Office14\NPSPWRAP.DLL: 14.0.4761.1000

Using the software from IT Hit, I created a simple C# project with a webdav server that shows files from the file system. You can download the project here: https://dl.dropboxusercontent.com/u/35370420/TestPlugin.zip . The files available through the webdav interface are stored under App_Data\WebDav\Storage.

When I try to edit documents using the JavaScript ajax browser (http://www.webdavsystem.com/ajaxfilebrowser), the edit document menu fails for certain files. You need to open the TestPlugin project in VS2010, run it, and click on the Browse using Ajax File Browser. I know that their JavaScript client uses the ms office plugin in Chrome and FireFox.

Here are my notes:

  • originally, I had the issue in my real app and I thought the plugin had a limit of 111 characters, i.e. when I tried to open files whose urls had more than 111 chars the plugin would fail. During the testing using the real application, I've also seen some weird stuff, where I would try to open a file, didn't work, open a second file that I knew it worked but the warning dialog would show a name made up of the second file's name to which it was appended a suffix from the previous file name.
  • I decided to start from scratch and I created the C# project based on the webdav.net software. I added files of different lengths in the webdav storage and here is what I noticed when I used the Browse Ajax File browser (I right-clicked on each file and I selected Edit Document):

  • FF 23 works fine, IE 9 works fine, no problem there

  • Chrome (when I said it fails to open I meant the browser shows the message: Current file cannot be opened for editing)
    • 01234567890123456789012345678901234567890123456789012345678901234567890123456789012.docx fails to open
    • 012345678901234567890123456789012345678901234567890123456789012345678901234567890123.docx opens fine
    • 0123456789012345678901234567890123456789012345678901234567890123456789012345678901234.docx fails to open
    • 01234567890123456789012345678901234567890123456789012345678901234567890123456789012345.docx fails to open
    • 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456.docx fails to open
    • 0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567.docx fails to open
    • 01234567890123456789012345678901234567890123456789012345678901234567890123456789012345678.docx opens fine
    • test.xlsx doesn't open even though I am presented the warning dialog but then the library reports back that it can't edit file

The length of the first url is 110 chars:

http://localhost:9658/01234567890123456789012345678901234567890123456789012345678901234567890123456789012.docx

So, my question is this: why is the behavior in chrome so inconsistent? In the end I am not too sure what the patterns are. Is there a problem with the ms plugin? I would think so but I am not 100% sure.

The project contains other files displayed in the webdav interface, You could try and see if they work.

Update:

Interesting enough, FF 22 behaved the same as Chrome, then I upgraded to version 23 and it works fine now, it opens all the files.

1

1 Answers

2
votes

OK, thanks to Stuart's explanations in this issue, things started to make more sense. Basically I think the problem lies into the way the Microsoft plugin has been implemented when it comes to handling the strings that are passed from JavaScript. Stuart posted a question that shows the problem. The plugin code expects the strings to be null terminated when in fact that's not guaranteed.

I did a test in my real app and I added the null character to url, i.e I passed url + '\0', and now the bloody thing works in Chrome.

The question remains, is Microsoft going to fix their plugin?