2035190 - Firefox 150 regression: drag and drop upload broken on Synology File Station (DataTransfer present but handler not triggered)

Status: NEW

(Core :: DOM: Core & HTML, defect)

Description

[bdm110]

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

Steps to reproduce:

1. Open Synology DSM File Station in Firefox 150
2. Navigate to any directory in File Station
3. Drag a local file from the OS into the file list area (right panel)
4. Drop the file

Reproducible on:

• macOS (latest)
• Windows (latest)

Tested environments:

• Firefox 149: works correctly
• Firefox 150: upload no longer triggers
• Safari / Chrome: works correctly

Actual results:

• The drop event fires successfully
• DataTransfer.files contains the file (files.length = 1 confirmed via console)
• However, no upload is triggered in Synology File Station

Additional observations:

• The drop target appears to resolve to outer container elements rather than the expected file list container
• File Station upload handler is not triggered
• No visible error message in UI
• Only generic CSP warnings appear in console (likely unrelated)

Expected results:

• The dropped file should be uploaded to the current directory in File Station
• Behavior should match Firefox 149 and other browsers (Safari, Chrome)
• Drop event should be correctly handled by the File Station upload logic

Comment 1

[j.svanda]

Regarding uploads to Synology DSM:

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

• Drag and drop works as expected.
• Upload from context menu works as expected.

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

• Drag and drop does not work.
• Upload from context menu works for files.
• Upload from context menu does not work for folders.

Comment 2

[FloRian-R]

This seems to be a general bug and also effects other websites e.g. Atlassian products.

Comment 3

[bdm110]

Tested on Firefox 150.1 (Windows/macOS).

The issue is still reproducible:

• Drag & drop does not trigger upload.
• Folder upload via context menu still does not work.
• File upload via context menu works.

Same behavior as Firefox 150.0.

Comment 4

[2Play!]

pushlog_url: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=85fa97819aa5346277ef53087ae97e9b39072605&tochange=b75b5f11053dddb3b688e6a4af3ac66e4bec9e6d
repo_name: mozilla-central

2026-04-30T12:48:12.721000: INFO : platform_changeset: c1e6c91577a899befa2539ce49c33221a4593cf5
2026-04-30T12:48:12.721000: INFO : platform_repository: https://hg.mozilla.org/mozilla-central
2026-04-30T12:48:12.722000: INFO : platform_version: 150.0a1
2026-04-30T12:49:04.505000: ERROR : Error while waiting process, consider filing a bug.
2026-04-30T12:49:04.701000: INFO : Narrowed integration regression window from [85fa9781, b75b5f11] (3 builds) to [c1e6c915, b75b5f11] (2 builds) (~1 steps left)
2026-04-30T12:49:04.772000: DEBUG : Starting merge handling...
2026-04-30T12:49:04.773000: DEBUG : Using url: https://hg.mozilla.org/mozilla-central/json-pushes?changeset=b75b5f11053dddb3b688e6a4af3ac66e4bec9e6d&full=1
2026-04-30T12:49:04.775000: DEBUG : redo: attempt 1/3
2026-04-30T12:49:04.777000: DEBUG : redo: retry: calling _default_get with args: ('https://hg.mozilla.org/mozilla-central/json-pushes?changeset=b75b5f11053dddb3b688e6a4af3ac66e4bec9e6d&full=1',), kwargs: {}, attempt #1
2026-04-30T12:49:04.782000: DEBUG : urllib3.connectionpool: Resetting dropped connection: hg.mozilla.org
2026-04-30T12:49:05.573000: DEBUG : urllib3.connectionpool: https://hg.mozilla.org:443 "GET /mozilla-central/json-pushes?changeset=b75b5f11053dddb3b688e6a4af3ac66e4bec9e6d&full=1 HTTP/1.1" 302 0
2026-04-30T12:49:06.447000: DEBUG : urllib3.connectionpool: https://hg-edge.mozilla.org:443 "GET /mozilla-central/json-pushes?changeset=b75b5f11053dddb3b688e6a4af3ac66e4bec9e6d&full=1 HTTP/1.1" 200 None
2026-04-30T12:49:06.490000: DEBUG : Found commit message:
Bug 2022568 - Update WPT expectations for CSS and WebRTC on Windows and Linux. a=testonly

2026-04-30T12:49:06.491000: DEBUG : Did not find a branch, checking all integration branches
2026-04-30T12:49:06.492000: INFO : The bisection is done.
2026-04-30T12:49:06.497000: INFO : Stopped

Comment 5

[Jan Jaeschke [:jjaschke]]

ni? Edgar for visibility

Comment 6

[2Play!]

I can confirm this regression affects Synology DSM/File Station drag‑and‑drop uploads.

Environment:

• Windows 11, Firefox 149 (good), Firefox 150 (bad)
• Synology DSM/File Station web interface
• Drag‑and‑drop worked fine in 149, broken in 150
• Edge/Chrome unaffected

Mozregression results:

• Last good: 85fa97819aa5346277ef53087ae97e9b39072605
• First bad: b75b5f11053dddb3b688e6a4af3ac66e4bec9e6d
• Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=85fa97819aa5346277ef53087ae97e9b39072605&tochange=b75b5f11053dddb3b688e6a4af3ac66e4bec9e6d

Impact:

• DSM/File Station relies on native drag‑and‑drop APIs for file upload.
• Regression prevents drag‑and‑drop entirely, forcing users to use the Upload button or switch browsers.
• This breaks a core workflow for Synology NAS users.

Please confirm and prioritize a fix. Thanks.

Comment 7

[Jan Jaeschke [:jjaschke]]

Thanks for the regression range! Could be bug 1993095? Marking regressed by tentatively.

Comment 8

[Hsin-Yi Tsai (she/her) | away [:hsinyi]]

NI Eden, too, as he was the assignee of bug 1993095.

Comment 9

[Jeff Muizelaar [:jrmuizel]]

FloRian-R, can you give steps to reproduce on other websites?

Comment 10

[Jeff Muizelaar [:jrmuizel]]

Those of you who can reproduce this can you try to investigate what might be going wrong? Are there any errors in the web developer console?

Does it work if you use the ChromeMask addon to spoof as Chrome?

Comment 11

[Jeff Muizelaar [:jrmuizel]]

I just reread the initial comment more carefully. It looks like bdm110 has done some initial investigation. bdm110 are you able to confirm that the drop target is different in Firefox than Chrome?

Comment 12

[2Play!]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #11)

I just reread the initial comment more carefully. It looks like bdm110 has done some initial investigation. bdm110 are you able to confirm that the drop target is different in Firefox than Chrome?

if of any help, my drag location is same (and tried diff but same synology web interface). It works on latest EDGE or as per my info above on the specific Firefox release(s).
correct behavior
https://preview.redd.it/firefox-v149-v150-drag-n-drop-broken-again-v0-ey2v9imemayg1.png?width=333&format=png&auto=webp&s=a3b650955417a6a30ff5e83a7729819ef82912d4

Comment 13

[FloRian-R]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #9)

FloRian-R, can you give steps to reproduce on other websites?

Environment:

• Linux Mint 22.3 - Cinnamon, Firefox 150.0.0.1
• Atlassian Jira / Confluence self-hosted
• Drag‑and‑drop worked fine in 149, broken in 150 onwards
• Edge/Chrome unaffected

Dragging anything into the application windows starts a GET request rather than handling the drag & drop. I hope that helps.

Comment 14

[Jeff Muizelaar [:jrmuizel]]

(In reply to FloRian-R from comment #13)

Dragging anything into the application windows starts a GET request rather than handling the drag & drop. I hope that helps.

FloRian-R, can you try getting a regression window for that using mozregression so that we can confirm it's the same problem?

Comment 15

[bdm110]

I don’t have Chrome available at the moment, but here is what I can confirm in Firefox 150.1:

• The drop event is fired correctly
• e.dataTransfer.files.length is correct
• However, the event target is a child element (e.g. .webfm-file-type-icon), not the expected container

Given that drag & drop works in earlier Firefox versions and other browsers, it seems likely that the drop target behavior may differ from previous expectations.

I did some additional debugging in Firefox 150.1.

The drop event is fired correctly and dataTransfer contains the expected files.

I added a global drop listener to inspect which elements receive the event:

document.querySelectorAll('*').forEach(el => { el.addEventListener('drop', e => { console.log('EL DROP', el.className); }); });
Observed output:
EL DROP <empty string> EL DROP syno-cjk ext-gecko ext-gecko3 EL DROP synohdpack ext-strict

his suggests that the drop event is being delivered to multiple nested elements, including child elements with specific classes, rather than a single expected container.

Given that the drop handler in the application is not triggered, it is possible that the event target differs from what the application logic expects (e.g. container vs child node).

Comment 16

[Jeff Muizelaar [:jrmuizel]]

Can you check what happens in Firefox 149?

Comment 17

[Yann Cochard]

Same problem this morning with Linux Mint 21.3, Firefox 150.0.1 with everything up-to-date (system & Firefox & Synology).

Comment 18

[bdm110]

I tested this using mozregression.

In Firefox 149:

• The drop event does not appear to be delivered to DOM elements via addEventListener.
• The test listener below does not produce any output during drag & drop:

In Firefox 150+:

• The drop event is delivered to multiple DOM elements (as expected via event propagation)
• The same test logs multiple elements, including child nodes

This suggests that the drop event dispatch behavior has changed between 149 and 150, and applications relying on a specific event target (e.g. container vs child) may break.

Comment 19

[Jeff Muizelaar [:jrmuizel]]

The change that the regression window is suggesting should just remove "application/x-moz-file" from the type list.

bdm110, can you search for the string x-moz-file in the debugger to see if it's used in the synology source anywhere?

Comment 20

[bdm110]

I searched again using the Debugger global search and found direct references to "application/x-moz-file".

The most relevant match appears to be:

• webman/3rdparty/FileBrowser/FileUploader.js

This file seems directly related to the file upload logic.

It checks dataTransfer.types for "application/x-moz-file", for example via:

types.contains("application/x-moz-file")
types.indexOf("application/x-moz-file")

There are also matches in:

• synoSDSjslib/dist/sds.bundle.js
• synoSDSjslib/dist/extjs-patch.bundle.js

So Synology File Station appears to rely on "application/x-moz-file" being present in dataTransfer.types. This likely explains why drag-and-drop upload stopped working after Firefox 150 removed/changed this type.

Comment 21

[Jeff Muizelaar [:jrmuizel]]

Can you attach FileUploader.js?

Comment 22

[bdm110]

Attachment: FileUploader.js

Comment 23

[Jeff Muizelaar [:jrmuizel]]

It looks like Synology is hard coding behaviour for Gecko:

  isDragFile: function (e) {
    try {
      if (Ext.isWebKit) {
        return e.dataTransfer.types && e.dataTransfer.types.indexOf("Files") != -1;
      }
      if (Ext.isGecko) {
        return e.dataTransfer.types.contains && e.dataTransfer.types.contains("application/x-moz-file") || e.dataTransfer.types.indexOf("application/x-moz-file") >= 0;
      }
      if (Ext.isIE10 || Ext.isModernIE) {
        return e.dataTransfer.files && e.dataTransfer.types && e.dataTransfer.types.contains("Files");
      }
    } catch (e) {
      SYNO.Debug("Error in isDragFile");
    }
    return false;
  },

Can you try the ChromeMask addon to see if it makes things work?

Comment 24

[bdm110]

I tested with the Chrome Mask add-on enabled for Synology DSM / File Station.

With Chrome Mask enabled, drag-and-drop upload works again.

So this confirms that Synology's Gecko-specific branch is the failing path. It relies on "application/x-moz-file", while the WebKit/Chrome path checks for the standard "Files" type and works correctly.

Comment 25

[Jeff Muizelaar [:jrmuizel]]

The best thing here would be for Synology to fix their code on their side. Has anyone filed a support ticket with them?

Comment 26

[2Play!]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #25)

The best thing here would be for Synology to fix their code on their side. Has anyone filed a support ticket with them?

Dear Jeff good day,

Dont want to be a pain, but...
We can open a ticket with them but I think it will take forever by synology to apply a change.
What about if their reply will be that its working to other major browsers but Firefox so its not a priority.

I think I will also try the Chrome Mask as I have Firefox as my daily browser with sync and all.

Its not convenient to have two browsers to use my Synology web gui.

Wishing all a great day

Comment 27

[2Play!]

I have tested the Chrome Mask. Enabled to my xxx.synology.com page and after few seconds drag drop worked fine again. I like the fact that add-on applies only to specific pages.

Comment 28

[Jeff Muizelaar [:jrmuizel]]

Are there a predictable list of urls for this problem or is it just network local addresses?

Comment 29

[2Play!]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #28)

Are there a predictable list of urls for this problem or is it just network local addresses?

In the synology case, the domain is synology.me and when someone connects to their synology NAS via quickconnect.to to the web gui which will show as per xxx.synology.me and a port. Where xxx is the synology quickconnect name of the remote NAS.
So this is diff to each user and not predictable. The chrome mask add on does not accept wild card domains (*.synology.me)

Comment 30

[Jeff Muizelaar [:jrmuizel]]

If the domain is always *.synology.me than it should be possible for us to add an intervention that adds back "application/x-moz-file" on these domains

Comment 31

[2Play!]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #30)

If the domain is always *.synology.me than it should be possible for us to add an intervention that adds back "application/x-moz-file" on these domains

I m happy to try as soon as you want
I just checked my settings in synology and the usual connect url
https://quickconnect.to/
It asks for the QuickConnect ID (xxx) and then goes to xxx.synology.me

Same goes if a user connects as per settings to http://QuickConnect.to/xxx
It will redirect to xxx.synology.me

Synology.me is the default domain.

In the settings has below all alternative domain options (user can select any of below if not using the default one)

Just for reference and if you guys want to proceed:

DiskStation.me
i234.me
myDS.me

DSCloud.biz
DSCloud.me
DSCloud.biz
DSCloud.mobi

DSmyNAS.com
DSmyNAS.net
DSmyNAS.org

FamilyDS.com
FamilyDS.net
FamilyDS.org

Comment 32

[olaf.seifert]

I don't think this is related to the hostname. We do not work with QuickConnect, but only with dynamic or static DNS records. The same problem everywhere.

Comment 33

[olaf.seifert]

BTW, Firefox > 150 + Chrome Mask works perfectly with several DSM versions (tried 7.1.1 an 7.3.2)

Comment 34

[Hsin-Yi Tsai (she/her) | away [:hsinyi]]

I reported this issue through synology's contact form.

Comment 35

[Klaus Schaper]

This problem appears not limited to synollogy:
I'm just developping an web application.

Drag & Drop in Morzilla 150 creates the error: "Uncaught DOMException: Modifications are not allowed for this document"

In Oracle, Chrome and Edge the same code works.

Klaus

PS: Is there any way to downgrade Morzilla and test with an older version?

Comment 36

[2Play!]

(In reply to Klaus Schaper from comment #35)

This problem appears not limited to synollogy:
I'm just developping an web application.

Drag & Drop in Morzilla 150 creates the error: "Uncaught DOMException: Modifications are not allowed for this document"

In Oracle, Chrome and Edge the same code works.

Klaus

PS: Is there any way to downgrade Morzilla and test with an older version?

Klaus its not related only to Synology. Any drag and drop related site. It just this bug discussion started basis on the synology web gui and drag n drop broken after a specific commit.

See discussion above and see my regression post with last good version and first bad.

There is a tool called Mozregression
https://mozilla.github.io/mozregression/
that downloads versions and you test each version and report good or bad (click on Mozregression). It gives you versions to test and narrows down to last good version and first bad.

Then report here (see mine above) your log and first/last so the devs can have specific info.

Comment 37

[soehme]

Issue was also reported against Atlassian Jira here:
https://jira.atlassian.com/browse/JRASERVER-79389

Very likely same cause (removal of type "application/x-moz-file", but Jira code relies on that being present - it will not check for "Files" when it detects Mozilla browser. If Addon "Chrome Mask" is installed in firefox and activated on the Jira URL, Drag&Drop files to attach works again).

Comment 38

[BugBot [:suhaib / :marco]]

Redirect a needinfo that is pending on an inactive user to the triage owner.
:hsinyi, since the bug has recent activity, could you have a look please?

For more information, please visit BugBot documentation.

Comment 39

[Hsin-Yi Tsai (she/her) | away [:hsinyi]]

(In reply to BugBot [:suhaib / :marco/ :calixte] from comment #38)

Redirect a needinfo that is pending on an inactive user to the triage owner.
:hsinyi, since the bug has recent activity, could you have a look please?

For more information, please visit BugBot documentation.

The information was gathered in other comments.

Comment 40

[2Play!]

FYR
version 152.0.6 (64-bit) still bug remains. only solution so far is the Chrome Mask add-on that saves the day so far

Comment 41

[Daniel Holbert [:dholbert]]

I have a Synology DSM 920+ and can help with further diagnosis/investigation if needed.

At this point, though, based on comment 22 - comment 23, it looks the next action is for Synology to remove a broken Firefox-only codepath. (Spoofing UA string works, but in my case at least -- and I suspect many other folks' case -- I access my Synology NAS's web UI using a local-network ip address; so there's no predictable set of URLs that we could use enable our UA-string-spoofing here and fix this across the board.)