1730361 - Unclear "Not implemented" error when using a file dialog to open word file stored on OneDrive which is open in word

Status: RESOLVED FIXED

(Core :: Widget: Win32, defect, P3)

Description

[miner.harry567]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:92.0) Gecko/20100101 Firefox/92.0

Steps to reproduce:

Works with many websites with file upload; for example: have a word document open in word desktop app, open Google Drive, import file, navigate to the open document, and click okay.

Actual results:

An error dialog box opens that says "Error: Not Implemented" with a blank description

Expected results:

In other browsers this says "Error: file open in another program. please close the file and try again." When I close the open word document the error does not occur

Comment 1

[Clara Guerrero ( Need Info Brindusa Tot Please)]

Attachment: word.webm

Comment 2

[Clara Guerrero ( Need Info Brindusa Tot Please)]

Hi,

I am not able to replicate the issue. I've tried on windows 10 pro, latest nightly build
Can you confirm I followed the steps to reproduce accurately on my video above?
I've assigned a component in order to get the dev team involved.

Thanks for the report.
Best regards, Clara.

Comment 3

[miner.harry567]

Interesting, it seems to only happen when trying to upload a file from a onedrive folder. (I keep basically everything in onedrive, so all my tests reproduced the error). When I upload an open file from an offline location, I see the behavior in the video; when I'm uploading an open file from a onedrive folder, it gives the 'not implemented' error.

Comment 4

[Clara Guerrero ( Need Info Brindusa Tot Please)]

Attachment: drive.webm

Comment 5

[Clara Guerrero ( Need Info Brindusa Tot Please)]

Attachment: drive2.webm

Comment 6

[Clara Guerrero ( Need Info Brindusa Tot Please)]

What about now?
(feel free to submit your own video for me to try replicate the issue on my end)
Best,
Clara

Comment 7

[miner.harry567]

Attachment: bandicam 2021-10-25 13-22-10-914.mp4

Sorry, I think I was unclear. I've attached a recording of the problem - first, I show that a document stored locally works correctly, and then that a document from onedrive gives the 'not implemented' error.

Comment 8

[Clara Guerrero ( Need Info Brindusa Tot Please)]

Attachment: drive.webm

Got it now!
I still cannot reproduce on my end.
1- Does this issue happen with a new profile? Here is a link on how to create a new profile: https://support.mozilla.org/en-US/kb/profile-manager-create-remove-switch-firefox-profiles
2- Are you using add-ons? (you can try the issue while in Safe Mode. You can find helpful info here : https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode .) Can you attach your about:support information?

Best,
Clara

Comment 9

[miner.harry567]

Attachment: about:support raw data

Comment 10

[miner.harry567]

-happens with new profile
-happens in safe mode (my only add-on is an external password manager, just reads & fills passwords)
-support information attached

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:Gijs, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 12

[:Gijs (he/him)]

Without being able to reproduce (I don't have a OneDrive, and just now Windows told me it couldn't log in to my MS account when I started the machine, so that's... fun.) it's hard to be 100% sure, but I expect that the error dialog is coming from Windows. We show a Windows filepicker (IFileDialog, with CLSID_FileOpenDialog). Perhaps the difference in message is because the other browsers handle OnShareViolation callbacks (cf this doc) and we don't? It's hard to tell, especially because the message shown by the other browsers (see comment 0) is also a standard Windows message, and a quick search in the Chromium codebase also does not show a meaningful OnShareViolation implementation (but maybe I missed it, I'm not that familiar with their code; or maybe it lives in the non-open-source bits...).

Anyway, this is an issue in our Windows widget layer implementation, so moving over there.

Comment 13

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:jimm, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 14

[Leon]

We ran into this issue today, at first I was not able to reproduce it (did not have an OneDrive sync setup), but I have found a reproduction path using a PowerShell script:

$filePath = "C:\path/to/file.ext"
$fileStream = [System.IO.File]::Open($filePath, 'Open', 'Read', 'None')
Write-Host "File $filePath is now locked. Press Enter to release the lock."
Read-Host
$fileStream.Close()

This script will lock the file until you manually unlock it. With this, you can consistently reproduce file locking and follow the steps from the original bug report.

Comment 15

[Ray Kraesig [:rkraesig]]

As suggested in comment 12, the error is indeed coming from Windows... but it appears to still be our fault: https://searchfox.org/mozilla-central/rev/f09e3f9603a08b5b51bf504846091579bc2ff531/widget/windows/nsFilePicker.cpp#625

    fos |= FOS_SHAREAWARE | FOS_OVERWRITEPROMPT | FOS_FORCEFILESYSTEM;

We're providing the FOS_SHAREAWARE flag, but not supplying an IFileDialogEvents object. (Use of this flag seems to date back to the original Vista-era implementation of the IFileDialog-based file-picker in bug 661991.) Thus, when a sharing violation occurs, we don't handle it despite telling Windows that we'll handle it; and Windows then dutifully reports that we didn't implement the thing we said we would implement.

The obvious solution is, of course, to stop saying that. Patch incoming.

---

(In reply to Leon from comment #14)

This script will lock the file until you manually unlock it. With this, you can consistently reproduce file locking and follow the steps from the original bug report.

Thanks!

Comment 16

[Ray Kraesig [:rkraesig]]

Attachment: Bug 1730361 - [1/1] remove unnecessary flag from IFileDialog r?#win-reviewers!

Remove the FOS_SHAREAWARE flag, which tells Windows that we'll be
providing it with an IFileDialogEvents object with .OnShareViolation()
implemented. (We do no such thing, nor ever have.)

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/9fcec695f4cb
[1/1] remove unnecessary flag from IFileDialog  r=win-reviewers,handyman

Comment 18

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/9fcec695f4cb