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@winehq.org Reporter: robert.munteanu@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.
https://bugs.winehq.org/show_bug.cgi?id=41062
Robert Munteanu robert.munteanu@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download URL| |https://cdn1.evernote.com/w | |in6/public/Evernote_6.1.2.2 | |292.exe
https://bugs.winehq.org/show_bug.cgi?id=41062
winetaste@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winetaste@gmx.net
--- Comment #1 from winetaste@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)
https://bugs.winehq.org/show_bug.cgi?id=41062
--- Comment #2 from winetaste@gmx.net --- It is the same, if your try to change the note title.
https://bugs.winehq.org/show_bug.cgi?id=41062
Guillaume R guillaumeraffin@free.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |guillaumeraffin@free.fr
--- Comment #3 from Guillaume R guillaumeraffin@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.
https://bugs.winehq.org/show_bug.cgi?id=41062
--- Comment #4 from winetaste@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.
https://bugs.winehq.org/show_bug.cgi?id=41062
--- Comment #5 from Guillaume R guillaumeraffin@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.
https://bugs.winehq.org/show_bug.cgi?id=41062
--- Comment #6 from winetaste@gmx.net --- As you write in AppDB test result virtual dekstop fixes this(is this obvious?).
https://bugs.winehq.org/show_bug.cgi?id=41062
--- Comment #7 from Guillaume R guillaumeraffin@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.
https://bugs.winehq.org/show_bug.cgi?id=41062
winetest@luukku.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winetest@luukku.com
--- Comment #8 from winetest@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.
https://bugs.winehq.org/show_bug.cgi?id=41062
--- Comment #9 from Guillaume R guillaumeraffin@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.
https://bugs.winehq.org/show_bug.cgi?id=41062
--- Comment #10 from Alexandre Julliard julliard@winehq.org --- What window manager are you using? Do other apps that show tooltips also lose focus when the tooltip appears?
https://bugs.winehq.org/show_bug.cgi?id=41062
--- Comment #11 from Robert Munteanu robert.munteanu@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.
https://bugs.winehq.org/show_bug.cgi?id=41062
Jactry Zeng jactry92@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jactry92@gmail.com
--- Comment #12 from Jactry Zeng jactry92@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.
https://bugs.winehq.org/show_bug.cgi?id=41062
--- Comment #13 from winetaste@gmx.net --- Still happens with wine 4.8.
Ubuntu 19.04 - default desktop (gnome)
https://bugs.winehq.org/show_bug.cgi?id=41062
S. Christian Collins s_chriscollins@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |s_chriscollins@hotmail.com
--- Comment #14 from S. Christian Collins s_chriscollins@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.
https://bugs.winehq.org/show_bug.cgi?id=41062
Esme Povirk madewokherd@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |madewokherd@gmail.com
--- Comment #15 from Esme Povirk madewokherd@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?
https://bugs.winehq.org/show_bug.cgi?id=41062
Esme Povirk madewokherd@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |source, testcase
https://bugs.winehq.org/show_bug.cgi?id=41062
--- Comment #16 from Esme Povirk madewokherd@gmail.com --- FWIW the affected application from the Wine Mono report was AutoWikiBrowser.
https://bugs.winehq.org/show_bug.cgi?id=41062
--- Comment #17 from Esme Povirk madewokherd@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.
https://bugs.winehq.org/show_bug.cgi?id=41062
--- Comment #18 from Esme Povirk madewokherd@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.
https://bugs.winehq.org/show_bug.cgi?id=41062
--- Comment #19 from Esme Povirk madewokherd@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.
https://bugs.winehq.org/show_bug.cgi?id=41062
--- Comment #20 from Esme Povirk madewokherd@gmail.com --- Oh, but it's probably not possible to click a tooltip normally because it'd hide when it gets WM_MOUSEMOVE.
https://bugs.winehq.org/show_bug.cgi?id=41062
--- Comment #21 from Esme Povirk madewokherd@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.
https://bugs.winehq.org/show_bug.cgi?id=41062
--- Comment #22 from Esme Povirk madewokherd@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?
https://bugs.winehq.org/show_bug.cgi?id=41062
--- Comment #23 from Esme Povirk madewokherd@gmail.com --- By "default WM_NCCREATE handler" I mean the one on the builtin tooltip class.
-
wine-bugs＠winehq.org -
WineHQ Bugzilla