Jorge wrote:
On Sun, Nov 11, 2012 at 09:18:08PM +0000, corvid wrote:
Jorge wrote:
Testing revealed the workaround concealed another problem, which I don't remember whether it was detected before, and this is that viewport mouse events get "through" the panel UI!.
How?, placing the mouse pointer over the panel (e.g. to the right of the Tools button, or even inside the Location), and scrolling a page full of links under it, will make the mouse pointer change to a hand, and the destination link appear in the status bar area.
This bug is revealed by disabling the workaround: just apply the small attached patch.
Clearly there's a viewport offset problem somewhere. Correcting it may save us lots of headaches in the future.
Does anybody know or has a clue of where this may be happening?
TIA.
Does this work for you?
diff -r 8b4259cdc6da dw/fltkviewport.cc --- a/dw/fltkviewport.cc Sat Nov 10 17:55:34 2012 +0000 +++ b/dw/fltkviewport.cc Sun Nov 11 21:14:40 2012 +0000 @@ -318,6 +318,10 @@ mouse_y = Fl::event_y(); positionChanged(); break; + + case FL_LEAVE: + mouse_x = mouse_y = -1; + break; }
return FltkWidgetView::handle (event);
Yes! It works.
Please elaborate a bit.
Some history: FLTK2 had widget coordinates relative to the parent. When we ported dillo to FLTK-1.3 which has absolute coords, a bunch of offset problems sprung here and there. I remember hunting/fixing most of them.
I thought this bug could be related to widget offsets, although that's just one possibility, not a certainty.
I had removed that code in the recent text selection / scrolling changes because I no longer thought I had any need for it, but: FltkViewport::scrollTo() calls positionChanged(), and it still remembered old mouse_x,mouse_y values from when the pointer was in the viewport.