Closed Bug 1763027 Opened 3 years ago Closed 3 years ago

outlook.office.com - drag and drop attachments not working

Categories

(Web Compatibility :: Site Reports, defect)

Product:
Web Compatibility
Component:
Site Reports
Version:
Firefox 98
Platform:
Desktop
All
Type:
defect

Tracking

(Webcompat Priority:P1, firefox99 wontfix, firefox100 wontfix, firefox101 affected)

Status:
RESOLVED FIXED
Project Flags:
Webcompat Priority P1
Tracking Flags:
Tracking Status
firefox99 --- wontfix
firefox100 --- wontfix
firefox101 --- affected

People

(Reporter: amandaveenhuis, Unassigned)

References

Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:98.0) Gecko/20100101 Firefox/98.0

Steps to reproduce:

Using Outlook in browser. Create a new message, drag attachment into message.

Actual results:

Attachment can only be attached through attach button

Expected results:

Able to drag and drop attachments into the draft email message.
Actual behavior

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Copy & Paste and Drag & Drop' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → DOM: Copy & Paste and Drag & Drop
Product: Firefox → Core

There seem to be several browser-specific handling in various places if I search "userAgent" in the source code. So I wonder if outlook does something differently for firefox in this case.

Karl, can we have your team member to look into a bit to understand what's up here? Thank you.

Flags: needinfo?(kdubost)

To maybe put a time frame on this:

I can confirm the bug from linux Firefox Developer edition v 100.0b2 (64 bit):
UA: Mozilla/5.0 (X11; Linux x86_64; rv:100.0) Gecko/20100101 Firefox/100.0.

Managed to reproduce this on macOS 11.06, Windows 10 x64 and on Ubuntu 20.04 x64.

Severity: -- → S3
Status: UNCONFIRMED → NEW
status-firefox100: --- → affected
status-firefox101: --- → affected
status-firefox99: --- → affected
Ever confirmed: true
OS: Unspecified → All
Hardware: Unspecified → Desktop

When I put over the message I get

13:58:24.290 dragenter 2 react-dom.production.min.js:73:408
13:58:25.820 dragover 434 react-dom.production.min.js:73:408
13:58:25.822 dragleave 2 react-dom.production.min.js:73:408

There is specific code for Firefox in their onDrop

    // OnDrop event handler
    onDrop = (dragEvent: React.DragEvent<HTMLElement>) => {
        if (this.props.preventBubblingDragEvents) {
            dragEvent.stopPropagation();
        }

        let dragData = this.getDragData(dragEvent);

        // Need this, otherwise FireFox gets redirected.
        if (dragData?.itemType != DEFAULT_ITEM_TYPE) {
            dragEvent.preventDefault();
        }

        if (this.getDesiredDropEffect(dragData) == 'none') {
            return;
        }

        this.props.onDrop(dragData, dragEvent.pageX, dragEvent.pageY, dragEvent.currentTarget);

        // TODO VSO 13903: Some times components need extra info to determine if the dropping action is on the component itself
        // or another component which shares the same store object
        // We call this callback here to allow the component do some extra work.
        if (this.props.onDragLeave) {
            this.props.onDragLeave(dragData, dragEvent.currentTarget);
        }

        this.cancelPendingDragLeaveHandler();
        // Strict mode was enabled in this package. See aka.ms/client-web-strict-mode for details.
        // -> Error TS2345 (232,28): Argument of type 'null' is not assignable to parameter of type 'string'.
        // @ts-expect-error
        setDragItemDetails(null, null);
        // Strict mode was enabled in this package. See aka.ms/client-web-strict-mode for details.
        // -> Error TS2345 (236,70): Argument of type 'null' is not assignable to parameter of type 'string'.
        // @ts-expect-error
        setDropState(this.props.dropViewState, false /*isDragOver*/, null /*draggableItemType*/);
    };

Interesting thing I can drop an image in the To: field.

I haven't found yet why it was failing.

Flags: needinfo?(kdubost)

The severity field for this bug is relatively low, S3. However, the bug has 3 duplicates.
:hsinyi, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(htsai)

Copied the keyword "webcompat:site-wait " from bug 1763535

Keywords: webcompat:site-wait

The severity is not so low for someone using drag and drop attachments on everyday, every few minutes basis.
I work with Ubuntu Firefox on company-imposed outlook webmail and all my mail has to go through it.
Please consider raising the severity. Many thanks.

The serverity is not low at all ... Many users in my compagny use firefox with OWA every day and all day long ... this bug is very penalizing for them.

Severity: S3 → S2
Webcompat Priority: --- → ?
Flags: needinfo?(htsai)

Agreed. This is not inconsequential. Waste a huge amount of time finding files within deep folder structures. Hopefully fixed soon.

Karl / Dennis,
Sorry for the ping again.
I am thinking if there's anything we can do while we're waiting for responses from the microsoft/outlook team? Thank you.

Flags: needinfo?(kdubost)
Flags: needinfo?(dschubert)

(In reply to Marc Ferandin from comment #13)

The serverity is not low at all ... Many users in my compagny use firefox with OWA every day and all day long ... this bug is very penalizing for them.

I agree with Marc Ferandin and kieradoolabh, I always use Outlook OWA and this bug is a complete waste of time. I hope the solve it soon just no to change to a different browser.

If it is of any help, I create a question on the Microsoft Forum about this issue and other 12 people have marked that they have this problem too.

https://answers.microsoft.com/es-es/outlook_com/forum/all/arrastrar-y-soltar-archivos/5403f92a-2cd1-471a-a8aa-8061111e961f

(It is in spanish though)

Folks, we know that this is broken. :) And while I understand that this is frustrating, posting "me-too" comments isn't the way to go, it sadly won't make anything faster.

I've just heard back from Microsoft, and they are actively working on a fix that might be ready next week. I'll update this bug as soon as we know more!

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #16)

Sorry for the ping again.
I am thinking if there's anything we can do while we're waiting for responses from the microsoft/outlook team? Thank you.

Given Microsoft is actively working here, the best thing is probably to wait for them. I'll keep my needinfo active, hoping I can dig a bit deeper into their code and maybe figure out what's actually causing this (i.e. if there is an underlying Firefox bug we should fix), but debugging events inside React sources has been proven surprisingly difficult in previous cases, so no promises here.

Thank you Dennis for following this up with microsoft. I wasn't clearly sure if they have been working on it. :)

Flags: needinfo?(kdubost)

Setting WebCompat P1 for now, Microsoft is actively working on it.

Webcompat Priority: ? → P1
Flags: needinfo?(dschubert)
Severity: S2 → --
Component: DOM: Copy & Paste and Drag & Drop → Desktop
Product: Core → Web Compatibility

Related report/discussion:

The latest Firefox update (100.0.1) resolved the issue for me. I tested on 3 different machines and confirmed it to not work on v100.0 and then working on v100.0.1 We only tested using PDF files.

Its working again yay!!! tested it on firefox version 78 through 98 with .txt, pdf, jpg, and many other common file types. . Thank you all for fixing this!!!

YEAH BABY!!! Works for me in Nightly!!! ;-))

Can we get a peek at the RCA?! I'm serious! ;-))

Status: NEW → RESOLVED
Closed: 3 years ago
Keywords: webcompat:site-wait
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.