1829187 - Images copied from Slack are treated as binary data of unknown type

Status: RESOLVED DUPLICATE of bug 1690532

(Core :: DOM: Copy & Paste and Drag & Drop, defect)

Description

[Chris Peterson [:cpeterson]]

Attachment: screenshot.png

Tom, this bug is a regression from file pasting bug 1810795, though this bug is about copying files, not pasting them. I bisected this regression to the following pushlog for bug 1810795:

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=4fd5e3f3d87b4dcc74c3620e32d29965a9ba3b9f&tochange=7ced852017511c07ddc57d42cf99939430d77978

Steps to reproduce

1. Log into Slack using Firefox Nightly >= 112.
2. Right-click on an image in a Slack message.
3. Select "Copy Image" from the context menu.
4. Paste the copied image somewhere, such as in a new Slack message or another application like the Windows File Explorer.

Expected behavior

The pasted image should show up as an image.

Actual behavior

The pasted image is treated as binary data of unknown type. If I paste the image in a new Slack message, Slack shows an error message about "type of file is not supported". If I paste the image into the Windows File Explorer, it is not an image file.

Comment 1

[Tom S. (please needinfo tschuster)]

Doesn't seem to reproduce on Linux, so maybe Windows only.

Comment 2

[Chris Peterson [:cpeterson]]

(In reply to Tom S [:evilpie] from comment #1)

Doesn't seem to reproduce on Linux, so maybe Windows only.

I can't reproduce on macOS, so this does seem to be Windows only.

I'm using Windows 11 Insider Preview (10.0.22624 Build 22624), in case the Windows version matters.

Comment 3

[Tom S. (please needinfo tschuster)]

I can reproduce this on Slack with Windows. Copying from other pages seems to work fine though. However setting dom.events.dataTransfer.mozFile.enabled to false doesn't actually fix the issue, so I am not sure if bug 1810795 is the correct regressor. Chris can you double check?

Comment 4

[Chris Peterson [:cpeterson]]

(In reply to Tom S [:evilpie] from comment #3)

setting dom.events.dataTransfer.mozFile.enabled to false doesn't actually fix the issue, so I am not sure if bug 1810795 is the correct regressor.

Setting dom.events.dataTransfer.mozFile.enabled to false fixes the issue for me, in both a clean profile and my regular profile.

Is there a different pref or STR I should test instead?

Comment 5

[Tom S. (please needinfo tschuster)]

Okay weird, I just can't get it to work with dom.events.dataTransfer.mozFile.enabled with true or false.

When looking in the Browser Toolbox (parent process only) in the Network tab, the image request is being aborted by ORB. After disabling ORB (browser.opaqueResponseBlocking) I then see that instead of the image we downloaded a login HTML page. That points to bug 1690532, because we are doing the image download without cookies on Windows.

Comment 6

[Tom S. (please needinfo tschuster)]

Please try a build from https://treeherder.mozilla.org/jobs?repo=try&revision=f31b5e1e06160d541b8b3806578c6cb3a0aa0a82 when it's ready.

Comment 7

[Tom S. (please needinfo tschuster)]

I tested it myself on Windows now and it seems to work fine.

Comment 8

[Chris Peterson [:cpeterson]]

(In reply to Tom S [:evilpie] from comment #6)

Please try a build from https://treeherder.mozilla.org/jobs?repo=try&revision=f31b5e1e06160d541b8b3806578c6cb3a0aa0a82 when it's ready.

LGTM! Copying and pasting images in Slack works correctly for me with your Try build.

Comment 9

[Tom S. (please needinfo tschuster)]

Thanks for trying. So this is just a dupe of bug 1690532, even though it's not clear to me why the mozFile pref makes a difference for you.