BToolBar's "flat" BButtons don't lose their "hover" state sometimes

[jackburton]

With Focus Follows Mouse enabled, there is a glitch in the Tracker Navigator icons mouseover. Move the mouse over a Navigator Icon, then move it slowly on another window placed near the tracker's one. The Icon will remain highlighted, like in the attached screenshot.

[diver]

I've seen it happening with without Focus Follows Mouse enabled.

[Janus]

I can reproduce this with all the buttons in the system.

[waddlesplash]

My prior analysis of the situation is that because BToolBar's BButtons do not have B_FULL_POINTER_HISTORY enabled. This (in practice at least) means that some, but not all of the enter/leave events will reach the button. So if you slowly move the mouse off of the buttons, they will de-hover 100% of the time. But if you move the mouse quickly off of the buttons (easily reproducible by moving another window halfway overtop of one of the buttons, focusing that window, and then moving the mouse on the button and then off onto the other window), the button never is told the mouse isn't on it and so it keeps its "hovering" look.

I couldn't imagine this didn't affect every button in the system -- it's just that most buttons are not flat, and the color change on hover is not very dramatic, so it's not really noticeable. It appears Janus investigated that (above), and confirmed this.

As for how to fix this, I'm not sure. Just enabling B_FULL_POINTER_HISTORY is probably sufficient to fix this, but the question is "where?". I'm unsure of the performance implications of enabling it, and if it's more than a few hundred microseconds it's probably too much to enable it by default for every BButton. We could, however, have BButton enable/disable it when the "flat" state is toggled. Or perhaps this is really a bug somewhere "further up the chain" -- a bug in the event filtering system? I'm not really familiar with any of these things or their implications, so someone more knowledgeable than me will have to handle this one.

[X512]

This bug is probably caused by wrong mouse message dispatching in Interface Kit or app_server. When cursor is moved to another window, previous window (and its views) is probably not notified correctly. B_ENTERED_VIEW/B_EXITED_VIEW message generation should be investigated.

[jackburton]

Replying to waddlesplash:

My prior analysis of the situation is that because BToolBar's BButtons do not have B_FULL_POINTER_HISTORY enabled. This (in practice at least) means that some, but not all of the enter/leave events will reach the button. So if you slowly move the mouse off of the buttons, they will de-hover 100% of the time. But if you move the mouse quickly off of the buttons (easily reproducible by moving another window halfway overtop of one of the buttons, focusing that window, and then moving the mouse on the button and then off onto the other window), the button never is told the mouse isn't on it and so it keeps its "hovering" look.

I don't think this is the case, since B_ENTERED/B_EXITED_VIEW messages should always be dispatched, with or without the B_FULL_POINTER_HISTORY flag. I'd be more inclined to think this is a bug in interface kit or/and app_server, as X512 wrote.

[X512]

I performed some tests and realized that this bug is not always reproduced. It is not reproduced in simple test application and WebPositive toolbar.

[X512]

Bug is probably in BButton::MouseMoved function:

	bool inside = Bounds().Contains(where);
	if (_SetFlag(FLAG_INSIDE, inside))
		Invalidate();

Setting inside variable don't take B_ENTERED_VIEW/B_EXITED_VIEW in account. I didn't find any problems in app_server or core Interface Kit.

[jackburton]

Fixed in hrev49183.