[Bug 56911] New: System.Windows.Forms: ContextMenuStrip -> SourceControl property is null
https://bugs.winehq.org/show_bug.cgi?id=56911 Bug ID: 56911 Summary: System.Windows.Forms: ContextMenuStrip -> SourceControl property is null Product: Mono Version: main Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: System.Windows.Forms Assignee: wine-bugs(a)winehq.org Reporter: maxmueller485(a)web.de CC: madewokherd(a)gmail.com Distribution: --- Created attachment 76732 --> https://bugs.winehq.org/attachment.cgi?id=76732 A small sample project containing nothing else but a cs source file, a csproj file and the sln file for this project Hello, I've stumbled over an issue in your current System.Windows.Forms implementation which did not affect the official version of Mono from the Mono Project. The problem affects the ContextMenuStrip class which usually has a SourceControl property. In WinForms there is a PictureBox widget which can have a context menu (ContextMenuStrip) with its elements (ToolStripMenuItem). The property SourceControl would normally provide you with information about the element that actually owns this context menu (useful if you have multiple PictureBoxes) - it actually did until upstream version 6.12.0.200 (the final release I could get from Mono's official repository for Ubuntu). Now when I take the mono implementation from your repository and compile it locally to run my project, the SourceControl will always be null which is really annoying. To better understand my problem, I've attached a zip compressed archive of a sample project I created to demonstrate the issue. The program consists of a small WinForms window with a single PictureBox in it. Right-click on the picture box will open up a ContextMenuStrip with a single ToolStripMenuItem in it ("Get underlying control"). When you click on this item, the method ToolStripMenuItem_Click will be executed and runs GetUnderlyingControl to determine the type of the control. On Windows .NET Framework and the old Mono implementations, the behavior is consistent (MessageBox shows "Underlying Control: pictureBox"). In your current Mono build, the MessageBox will show "No underlying control found" -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=56911 --- Comment #1 from Nikolay Sivov <bunglehead(a)gmail.com> --- Could you check if winforms from .net 5+ show the same behavior as current wine-mono? This might be a difference between framework logic and current one. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=56911 --- Comment #2 from David Bitterlich <maxmueller485(a)web.de> --- If you mean the Windows-platform implementation of WinForms in dotnet 5+, yes I tested this too in a Windows VM. The behavior their is still the same (underlying control will be found). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=56911 --- Comment #3 from David Bitterlich <maxmueller485(a)web.de> --- Hi, I just compiled the current main branch from Mono's GitHub repository and the same issue happens here, too. It is also on version 6.13.0, just like the code here in gitlab and yes, the issue happens there too... I took my time now to test different versions of Mono by checking out different commits from the past (changes in WinForms have mostly been done until 2022).
From what I have seen, the first commit which introduced the issue, seems to be this one: https://gitlab.winehq.org/wine-mono/mono/-/commit/60da71f05fa149dc6402c96725... from 13th of April 2021
The build before did not have this problem... -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=56911 --- Comment #4 from Nikolay Sivov <bunglehead(a)gmail.com> --- I don't think we are using winforms code from Mono, so testing that is not useful. What is useful is to compare dotnet winforms 5+ behavior on windows with dotnet 4.x behavior, also on windows. For wine-mono we need to match 4.x. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=56911 --- Comment #5 from David Bitterlich <maxmueller485(a)web.de> --- I don't know if we are talking about the same... So my question is: The Mono repository you are hosting here on Wine's Gitlab, is it supposed to work on Wine/Windows only, or is it intended to be usable on Linux, too (compiled from source of course)? The official Mono GitHub repository seems to be dead and in this repository there is atleast a little bit of activity. So... my issue does happen with Mono on Linux directly without using Mono compiled for Wine. The last official Mono build, based on 2020 6.12.0 branch did not have this issue and commit 60da71f0 seems to have introduced this issue. This commit is included in your Gitlab version of the Mono repository - and I can reproduce this issue with both the latest GitHub version from Mono (6.13) and the latest GitLab version from here (also 6.13). This Bugzilla tracker is for the Mono project you are hosting on GitLab. I have been able to select Mono as affected product, System.Windows.Forms as affected component, main as the current repository and Linux x86-64 as hardware/os platform. My problem clearly comes from a component of Mono running on Linux x86-64. In my opinion it is useful to compare mono versions to find out the guilty commit that introduced an issue into a component of mono - atleast if you are developing on the codebase of Mono in all its glory. Btw when I throw my compilated application to windows, it simply works and I cannot reproduce the issue there... So right click on a PictureBox -> click on the contextMenuItem works and the ContextMenuItemStrip has a SourceControl that is not null. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=56911 --- Comment #6 from Esme Povirk <madewokherd(a)gmail.com> --- Yep, the Mono component is for the main branch on gitlab which is a fork of cross-platform Mono, not Wine or Wine Mono. That does indeed use System.Windows.Forms from the Mono codebase. I do plan to look into this, just haven't gotten around to it yet. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=56911 --- Comment #7 from Esme Povirk <madewokherd(a)gmail.com> --- Looks like the source control is being unset when the menu is dismissed, before the Click handler is called. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=56911 --- Comment #8 from Esme Povirk <madewokherd(a)gmail.com> --- This is unset by the SetOwnerControl(null) call in ToolStripDropDown.Close. Unfortunately, moving the call to the end doesn't fix this, and I found in testing on Wine (which probably matches Windows) that it is unset later. So I'm not sure where the unset call should be. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=56911 --- Comment #9 from Esme Povirk <madewokherd(a)gmail.com> --- Possibly this should go in ToolStripMenuItem.OnClick, but we still need ToolStripDropDown.Close to unset this in other cases. Checking reason seems wrong. Application can detect whether Dismiss is called (by subclassing), so we can't just go through an internal method instead. Maybe some internal flag to delay this until ToolStripMenuItem.OnClick can handle it after the Click handler? But that feels messy. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=56911 --- Comment #10 from David Bitterlich <maxmueller485(a)web.de> --- Hello Esme, I'm not sure how far you came but I just built the most recent version of Mono from GitLab and was able to verify that the underlying control is now found. Was your fix temporary and maybe a workaround or final? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=56911 --- Comment #11 from Esme Povirk <madewokherd(a)gmail.com> --- I didn't commit anything to fix it. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=56911 --- Comment #12 from David Bitterlich <maxmueller485(a)web.de> --- Ah sorry, my fault. I forgot to clean my build artifacts... Yes, issue still persists unfortunately. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla