| | [ Return to Bugs & Features | Roadmap 1.3 | SVN ⇄ GIT ]
STR #3157
| Application: | FLTK Library |
|---|
| Status: | 1 - Closed w/Resolution |
|---|
| Priority: | 3 - Moderate, e.g. unable to compile the software |
|---|
| Scope: | 2 - Specific to an operating system |
|---|
| Subsystem: | Core Library |
|---|
| Summary: | Stray tooltips popping up from stowed FLTK windows (OSX 10.9) |
|---|
| Version: | 1.3.3 |
|---|
| Created By: | greg.ercolano |
|---|
| Assigned To: | greg.ercolano |
|---|
| Fix Version: | 1.3.4 (SVN: v10514) |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
Trouble Report Comments:
| |
| #1 | greg.ercolano
10:54 Nov 20, 2014 |
| Reporting this on behalf of a customer.
He reports that tooltips pop open /after/ the FLTK application
is stowed (yellow button) and remain up over other applications.
He says it doesn't always happen, it's erratic, and isn't sure
what exact steps trigger it.
He's seeing this on OSX 10.9.4 + 10.9.5.
I'm imagining a tooltip timer is being triggered that kicks open
a tooltip even though the window it's associated with is stowed.
Before a tooltip is popped open, perhaps adding a check to see
if the parent window isn't visible would prevent this? | |
| |
| #2 | greg.ercolano
20:04 Nov 20, 2014 |
| Think I figured out replication by studying the FLTK code.
If you hit the yellow "iconify" button for an app, but before
the machine reacts to stowing the window (it takes time for the
'shrink away animation' to begin) you then glide the mouse over
one of the still-visible widgets that has a tooltip, it starts
a tooltip timer running for that button, and then after the window
has iconified, the tooltip for that button pops up and 'grabs'
the screen. It then won't go away because the mouse isn't generating
events in the now-iconified window. | |
| |
| #3 | greg.ercolano
20:24 Nov 20, 2014 |
| I can replicate with e.g. test/valuators (which has tooltips on
some of its sliders).
And the problem becomes particularly annoying if you quickly
select another application before the unwanted tooltip posts.
When that happens, the tooltip posts over the selected app
and remains up and will not go away no matter what interactions
you do with the mouse.
So yeah, this is kinda bad and should be fixed.
I don't think this is a problem with the OSX specific code,
but rather, likely an issue in Fl_Tooltip that allows the timer
to post a tooltip if the top window the widget is associated with
is !visible(). | |
| |
| #4 | greg.ercolano
03:46 Nov 22, 2014 |
| Attaching patch suggestion as a fix. Seems to work, but not 100% sure
it's the best thing to do.
Comments welcome from other devs familiar with Fl_Tooltip. | |
| |
| #5 | greg.ercolano
20:22 Jan 10, 2015 |
| Fixed in Subversion repository. | |
[ Return to Bugs & Features ]
|
| |
