[Bug 41062] New: Evernote 6.1.x: search box loses focus due to tooltips
https://bugs.winehq.org/show_bug.cgi?id=41062 Bug ID: 41062 Summary: Evernote 6.1.x: search box loses focus due to tooltips Product: Wine Version: 1.9.15 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: robert.munteanu(a)gmail.com Distribution: --- Created attachment 55243 --> https://bugs.winehq.org/attachment.cgi?id=55243 Video capture of the issue Running Evernote 6.1.2 in a fresh 32-bit prefix, with winetricks ie8 ( otherwise notes don't display ). $ sha1sum Evernote_6.1.2.2292.exe f7ace795f0444ab8d29a6823b845da3a4687d247 Evernote_6.1.2.2292.exe The search box field loses focus when I start typing and the mouse is on top of the search box, making it impossible to type more than 1-2 characters. Clicking the search box and moving the mouse quickly away seems to be a workaround. -- 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=41062 Robert Munteanu <robert.munteanu(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download URL| |https://cdn1.evernote.com/w | |in6/public/Evernote_6.1.2.2 | |292.exe -- 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=41062 winetaste(a)gmx.net changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |winetaste(a)gmx.net --- Comment #1 from winetaste(a)gmx.net --- Confirming $ sha1sum Evernote_6.4.2.3788.exe 36e0a49ddfc12cd098780abcded881f0a4a6bb46 Evernote_6.4.2.3788.exe 32-bit & 64-bit prefix - wine 2.0-rc4 (with or without ie8) -- 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=41062 --- Comment #2 from winetaste(a)gmx.net --- It is the same, if your try to change the note title. -- 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=41062 Guillaume R <guillaumeraffin(a)free.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |guillaumeraffin(a)free.fr --- Comment #3 from Guillaume R <guillaumeraffin(a)free.fr> --- I've got this problem for note title and notebook renaming field, but I regain focus automatically (that is, without doing anything) after 1/2 seconds. And after regaining focus I can type normally in the field. -- 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=41062 --- Comment #4 from winetaste(a)gmx.net --- Yes, when the yellow key tip pop-up is gone. But it needs several seconds. That is different for the search box. Losing focus with this yellow pop-up and when it is gone(also several seconds) the focus is on the first search result. -- 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=41062 --- Comment #5 from Guillaume R <guillaumeraffin(a)free.fr> --- (In reply to winetaste from comment #4)
Yes, when the yellow key tip pop-up is gone. But it needs several seconds.
You're right! It's 1 OR 2 seconds not 1/2 seconds, my mistake. -- 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=41062 --- Comment #6 from winetaste(a)gmx.net --- As you write in AppDB test result virtual dekstop fixes this(is this obvious?). -- 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=41062 --- Comment #7 from Guillaume R <guillaumeraffin(a)free.fr> --- I've just re-tested Evernote 6.4.2.3788 with wine 2.0, and every tooltip make the entire Evernote windows lose focus. For me, now, the tooltips don't disappear after a few seconds on their own, I have to click or to move the cursor :( Using a virtual desktop still works and it seems to be the only solution so far. -- 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=41062 winetest(a)luukku.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |winetest(a)luukku.com --- Comment #8 from winetest(a)luukku.com --- (In reply to Guillaume R from comment #7)
I've just re-tested Evernote 6.4.2.3788 with wine 2.0, and every tooltip make the entire Evernote windows lose focus. For me, now, the tooltips don't disappear after a few seconds on their own, I have to click or to move the cursor :(
Using a virtual desktop still works and it seems to be the only solution so far.
Since you are familiar with the software and gave recent reply here could you also test even some of the other open evernote bugs? That would help a lot. -- 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=41062 --- Comment #9 from Guillaume R <guillaumeraffin(a)free.fr> --- > Since you are familiar with the software and gave recent reply here could > you also test even some of the other open evernote bugs? That would help a > lot. I think I've already done it? - https://bugs.winehq.org/show_bug.cgi?id=37015#c6 - https://bugs.winehq.org/show_bug.cgi?id=38880#c6 - https://bugs.winehq.org/show_bug.cgi?id=39335#c16 - and more I will retest everything as soon as wine 2.5 will be available in the Fedora 25 repository. -- 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=41062 --- Comment #10 from Alexandre Julliard <julliard(a)winehq.org> --- What window manager are you using? Do other apps that show tooltips also lose focus when the tooltip appears? -- 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=41062 --- Comment #11 from Robert Munteanu <robert.munteanu(a)gmail.com> --- (In reply to comment #10)
What window manager are you using? Do other apps that show tooltips also lose focus when the tooltip appears?
I'm using Gnome 3 ( gnome-shell 3.24.0 ) . I don't recall a time when this did not happen. I see a similar issue with Photoshop CS6 - bug #37929 . Lightroom 5 does not seem to have this issue. This does not happen at all for Linux-native apps. -- 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=41062 Jactry Zeng <jactry92(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jactry92(a)gmail.com --- Comment #12 from Jactry Zeng <jactry92(a)gmail.com> --- Created attachment 58027 --> https://bugs.winehq.org/attachment.cgi?id=58027 QQ's emoticon completion. Hi, (In reply to Alexandre Julliard from comment #10)
What window manager are you using? Do other apps that show tooltips also lose focus when the tooltip appears?
Wine QQ also has a similar bug. (I'm using GNOME3 with X11.) There is a popup window for emoticon completion when typing '/' in QQ's chat dialog. And this popup window will take the input focus from the text editor. It seems that this is a bug of winex11.drv, because these two bugs (QQ's and evernote's) can't be reproduced on macOS with winemac.drv. -- 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=41062 --- Comment #13 from winetaste(a)gmx.net --- Still happens with wine 4.8. Ubuntu 19.04 - default desktop (gnome) -- 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=41062 S. Christian Collins <s_chriscollins(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |s_chriscollins(a)hotmail.com --- Comment #14 from S. Christian Collins <s_chriscollins(a)hotmail.com> --- If you use the KDE Plasma 5 desktop environment, you can set a window rule to avoid the tooltip stealing application focus: 1. Start the affected Wine application. 2. Click the app icon in the titlebar and go to More Actions -> Configure Special Application Settings..., then go to the "Appearance & Fixes" tab, tick the box for "Focus stealing prevention", and to the right of that select "Force" and "Extreme", then click OK. This completely solves the issue for me with Endless WAV. I am running Plasma Desktop 5.18.4 in KDE neon. -- 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=41062 Esme Povirk <madewokherd(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |madewokherd(a)gmail.com --- Comment #15 from Esme Povirk <madewokherd(a)gmail.com> --- Created attachment 70482 --> https://bugs.winehq.org/attachment.cgi?id=70482 testcase A similar issue was reported to Wine Mono here: https://github.com/madewokherd/wine-mono/issues/108 Bug 39547 may also be the same bug. It happens that winforms tooltips are based on the builtin tooltip class from comctl32, so this affects winforms in Wine Mono and all versions of .NET. I wrote a quick testcase (attached) that shows the tooltips being incorrectly focused in Wine. It seems that the usage in Wine's tests results in a default window style of WS_CAPTION being applied, which causes winex11.drv's is_window_managed heuristic to return TRUE. I assume we don't want to change that heuristic. That means that either we need to prevent that window mode from being set in comctl32 (which is something the application could observe and we could test for), or we need is_window_managed to give special treatment to the builtin tooltip classes. Am I missing anything? -- 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=41062 Esme Povirk <madewokherd(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |source, testcase -- 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=41062 --- Comment #16 from Esme Povirk <madewokherd(a)gmail.com> --- FWIW the affected application from the Wine Mono report was AutoWikiBrowser. -- 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=41062 --- Comment #17 from Esme Povirk <madewokherd(a)gmail.com> --- I thought of one other possibility: maybe WM_TAKE_FOCUS should be ignored (or should focus a different window) for tooltip windows. This needs more research to determine if there's some way that winex11.drv can determine that it shouldn't focus the window. If it is possible, it would mean we don't have to check the class name so it could theoretically work with a custom tooltip class or a subclass. -- 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=41062 --- Comment #18 from Esme Povirk <madewokherd(a)gmail.com> --- Created attachment 70494 --> https://bugs.winehq.org/attachment.cgi?id=70494 possible fix Looking at WM_TAKE_FOCUS code, it will ignore the request if WM_MOUSEACTIVATE returns MA_NOACTIVATE. That means handling the message is a possible fix. Is it acceptable for Wine's tooltip control to do this? Under normal circumstances on Windows, this message should never be sent to a tooltip, so it's likely that native does not do this. -- 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=41062 --- Comment #19 from Esme Povirk <madewokherd(a)gmail.com> --- On second thought, yes it would be sent under normal circumstances on Windows, when a tooltip is clicked (though not with HTMENU). We handle the click by hiding the tooltip. Messing with window focus when clicking on a tooltip would be not ideal, so now I'm thinking native probably does this. -- 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=41062 --- Comment #20 from Esme Povirk <madewokherd(a)gmail.com> --- Oh, but it's probably not possible to click a tooltip normally because it'd hide when it gets WM_MOUSEMOVE. -- 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=41062 --- Comment #21 from Esme Povirk <madewokherd(a)gmail.com> --- I guess we could have winex11.drv try to detect when it gets a WM_TAKE_FOCUS from the WM because of mapping a window shown with SWP_NOACTIVATE. The only way I can think of to do that is to ping the WM after calling XMapWindow and ignore anything before getting a reply to the ping. I could imagine a WM breaking that though, or it might break something else that currently works with winex11.drv by coincidence. -- 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=41062 --- Comment #22 from Esme Povirk <madewokherd(a)gmail.com> --- There's still something going on here that I don't understand. The default WM_NCCREATE handler is supposed to remove the WS_DLGFRAME style from the window. WS_CAPTION is defined as a combination of WS_DLGRAME and WS_BORDER. So why does is_window_managed in winex11.drv observe a mode of WS_CAPTION and create the window as managed? -- 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=41062 --- Comment #23 from Esme Povirk <madewokherd(a)gmail.com> --- By "default WM_NCCREATE handler" I mean the one on the builtin tooltip class. -- 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 (2)
-
wine-bugs＠winehq.org -
WineHQ Bugzilla