Tooltip causing Window to "unfocus" on Windows

[wyhinton]

Moving fltk-rs/fltk-rs#797 to here.

Looks like the Tooltip widget is causing the app window to unfocus.

#include <FL/Fl.H>
#include <FL/Fl_Window.H>
#include <FL/Fl_Button.H>
#include <FL/Fl_Pack.H>

int main() {
  Fl_Window win(400, 300, "Window");
  Fl_Pack pack(160, 20, 80, 300);
  pack.spacing(5);
  for (int i = 0; i < 5; i++) {
    auto btn = new Fl_Button(0, 0, 0, 40, "Button");
    btn->tooltip("Button");
  }
  pack.end();
  win.end();
  win.show();
  win.redraw();
  return Fl::run();
}

CMakeLists.txt

cmake_minimum_required(VERSION 3.15)
project(monitors)

include(FetchContent)

set(FLTK_BUILD_TEST OFF CACHE BOOL " " FORCE)
set(OPTION_USE_GDIPLUS ON CACHE BOOL " " FORCE)

FetchContent_Declare(FLTK
    GIT_REPOSITORY https://github.com/fltk/fltk
    GIT_SHALLOW TRUE
)
FetchContent_MakeAvailable(FLTK)

add_executable(main main.cpp)
target_link_libraries(main PRIVATE fltk gdiplus)
target_include_directories(main PRIVATE ${fltk_SOURCE_DIR} ${fltk_BINARY_DIR})
target_link_libraries(main PRIVATE fltk)

build.bat

cmake -S. -Bbin -DCMAKE_BUILD_TYPE=Release && cmake --build bin --config Release

[Albrecht-S]

@wyhinton Thanks for the report. I'm not sure if this can be changed though.

FTR: @MoAlyousef wrote in fltk-rs/fltk-rs#797 (comment)

I was looking at the fltk source code and it seems to be related to this line:

fltk/src/Fl_Tooltip.cxx

Line 304 in 41b1f1f

// possible fix for the Windows titlebar, it seems to want the

Thanks for looking into it.

[wyhinton]

I'm not sure if this can be changed though.

By this do you mean that this kind of "unfocusing" in the toolbar is something that can not be changed on Windows?

[Albrecht-S]

I don't know. Fact is that the tooltip is a window and that "switching" windows is likely to "unfocus" one window because the other window gets the focus. I have no idea what exactly is happening and if any Windows properties can be changed (in FLTK code) to suppress this or ... whatever. I don't know, and that's all I wanted to say. This needs investigation.

Of course, patches and pull requests would be appreciated.

[wyhinton]

I'm guessing what's going has something to do with the tooltip being "outside of" the window. That is, I'm assuming, the tooltip is not a child of the window whose widgets are causing the tooltip to appear. Putting a window inside of a window does not cause a new window to show up in the taskbar, or cause the un-focusing effect.

Simple example in rust:

fn main(){
    let app = App::default();
    let mut win = Window::new(200, 200, 500, 300, "Event Trickle");
    let win2 = Window::new(100,50, 200, 200, "WINDOW IN WINDOW");
    let mut button= Button::new(0,0,250,200,"button in window 2");
    button.set_color(Color::Red);
    win2.end();
    win.end();
    win.show();
    app.run().unwrap();
}

I think for a design perspective however, this "window in a window" approach might not be great because our tooltip will be clipped off at the boundaries of the parent window.

[fire-eggs]

I poked at this a little bit, with only negative results. The issue is "limited" to a transit between two widgets with an active tooltip.

See my screen cap:

Initially, hovering the mouse over a button and then away causes the tooltip to appear and vanish without any focus change.

But when moving between two buttons with the tooltip open, that is when a focus change may happen. [i.e. hover over button A, tooltip A appears; move the mouse to button B, tooltip B appears]. It also appears to be related to the speed of the transit.

I think this eliminates the hypothesis of the tooltip being "outside of" the window being the problem. If that was the problem, then a simple "tooltip appears, tooltip vanishes" would also cause a focus change.

I also tried disabling the "possible fix for the Windows titlebar" code. Doing so had no effect.

I believe the problem is at a lower level, i.e. with window transitions. When the mouse leaves button A, the tooltip window is hidden. The mouse enters button B, and the tooltip window is shown. Depending on the speed of the transition, the mouse may be over the parent window for long enough to register a focus change.

[erco77]

IIRC tooltips are separate windows just like popup menus, and although I'm only familiar with the X11 side of things, I'm thinking there's a window attribute flag FLTK isn't setting for tooltips that needs to be set so the window manager doesn't keep moving focus around. I'm not sure what that is, and did try to look into it once by looking at other toolkits, but couldn't quite figure it out.

I can confirm the OP's behavior even on Windows 7 with my own commercial app.. I never noticed it. (Wish I had more to offer; I don't have a patch or know what to fix in this case.. win32 is not my specialty at all.)

[wyhinton]

@erco77 @fire-eggs thanks for lending your thought's on the issue.

Looks like our experts are stumped. If it's something as simple as providing the windows manager with the correct flags, then maybe it would be worth reaching out to the devs of some other cross platform GUI kits who have been able to figure it out?

[Albrecht-S]

@fire-eggs and @erco77 Thanks for looking into this, I'd been distracted by other work.

I seem to have made some progress. Commenting out this line:

fltk/src/Fl_Tooltip.cxx

Line 303 in 6ac305a

Fl::add_timeout(Fl_Tooltip::hoverdelay(), tooltip_timeout);

seems to "fix" the issue.

I'm just testing and making educated guesses so far, but this line seems to be unnecessary at a first glance. If you look close at what happens when you enter a button - at least when another tooltip is already displayed - you'll notice that the tooltip gets displayed twice with a very short delay. To see that better, move the mouse upwards from, say, button2 to button1. And to see it even better, you can increase the hoverdelay from 0.2 to (e.g.) 0.8 seconds. Here's my working patch with test and debug statements:
tooltip.diff.txt

This is not yet a final solution, it's just a little progress I made. I'm also attaching my test program here: issue-261.cxx.txt

I'd be interested in any insights and test results. Are there any negative side effects?

[Albrecht-S]

PS: so far I only tested on Linux (which doesn't exhibit the issue) and with wine and the demo program cross-compiled on Linux (which DOES exhibit the issue). Would be interesting to see what native Windows looks like with this patch...

[fire-eggs]

Albrecht - That is absolutely amazing! Yes, that change addresses the issue - tested on both Windows7 and Windows 10!

I can't see any negative side effects. Before-and-after behavior appears to be the same except for the focus flash.

For completeness, I'm attaching my test source and the two x64 windows exes.
fltk261.cpp.txt
fltk261_fix.zip
fltk261_nofix.zip

[Albrecht-S]

@fire-eggs Thanks for testing and for the source code - however ...

Meanwhile I found another - very likely more appropriate - fix. The real (?) cause of the issue was AFAICT a regression introduced when switching to the FLTK 1.4 driver model. You can verify that this is a regression by building the respective demo programs with FLTK 1.3. Does it work for you in 1.3?

You and others are invited to test the following tiny patch which fixes the regression. I'm about to commit it but for now only in my private fork (for testing on Windows).

index 220e4603d..2d2eb2021 100644
--- a/src/Fl_Tooltip.cxx
+++ b/src/Fl_Tooltip.cxx
@@ -301,6 +301,7 @@ void Fl_Tooltip::enter_area(Fl_Widget* wid, int x,int y,int w,int h, const char*
       Fl::remove_timeout(tooltip_hide_timeout);
     }
     Fl::add_timeout(Fl_Tooltip::hoverdelay(), tooltip_timeout);
+  } else if (Fl_Tooltip::delay() < .1) {
     // possible fix for the Windows titlebar, it seems to want the
     // window to be destroyed, moving it messes up the parenting:
     if (Fl::system_driver()->use_recent_tooltip_fix() && window && window->visible()) {

I'll let you know about my Windows tests ASAP. I'd appreciate to see your test results with my new patch (above, in this comment). TIA.

PS: I'll look at your code later...

Edit: done. Good idea to use an Fl_Pack for this demo. I didn't think of using an Fl_Pack, but anyway: my version was intended to be easily configurable using different button sizes and widget spacing.

[Albrecht-S]

OK, I tested the new patch on my Windows 10 VM and it looks good. I could also see the issue with the unpatched code, hence I'm now very confident that the "new patch" is correct.

I decided to commit the patch for easier testing by others, it's now in FLTK master (29a56f8).

I'd like to see confirmation by anybody though, particularly by the OP @wyhinton. Thanks in advance.

[erco77]

I'll give this a spin.. building now, will follow up.

Are we still interested in reporting compiler warnings? I've got 93 warnings in VS 2017 from the 1.4.x current. Mostly double->float conversions, and a few ulong->char, time_t -> int, etc.

[erco77]

Looks good to me!

• Tooltips no longer flash the title bar
• Tooltip timeouts seem to work (~10 secs)
• Doesn'taffect keyboard focus when tips appear/disappear, etc.

Tested on Win8 and Win7, built with VS2017 with cmake + Release mode.

[Albrecht-S]

@erco77 Thanks, Greg, for testing and feedback. BTW: Tooltip timeout default value is 12 sec.

I'll wait for confirmation from the OP @wyhinton and/or @MoAlyousef (the fltk-rs maintainer) and close this issue then.

This commit should also fix fltk-rs/fltk-rs#797 once it is applied to fltk-rs.

[Albrecht-S]

Are we still interested in reporting compiler warnings? I've got 93 warnings in VS 2017 from the 1.4.x current.

Our CI build logs show lots of these warnings (go to the FLTK GitHub page, click on Actions and follow the links to the latest builds, e.g. this one). There's no need to report any warnings we can see in these build logs. See also #109.

[MoAlyousef]

Thank you. I pulled latest master and built on my Windows 10 machine, using both msvc and mingw and I can confirm it's fixed. Same with the Rust bindings with the example provided by @wyhinton

[Albrecht-S]

@MoAlyousef Thanks for confirmation, closing this issue now.