Created attachment 61181 [details] [review]
maemo-gtk pseudo patch, stripped of irrelevant stuff

this patch adds a focus-out handler that calls stop_scrolling() which is provided by gtkrange.c and stops the timer and removes the grab.

Created attachment 61183 [details]
testcase that pops up a dialog for adjustment values >75%

this test case will pop up a window with a scrollbar. when the slider moves to >75%, a new dialog is popped up that gets the focus. the right arrow of the scrollbar can be used in conjunction with auto-repeat scrolling to create the described scenrio (auto-repeat continues across the new dialog popping up).

If we decide to do this, we should do it unconditionally (looking at the
"hildonlike" bits)

And if we do it, we probably want to treat other places in the same way,
like the button-repeat in the spinbutton, calendar, pathbar

yeah, forget the hildonlike stuff, that is just uncleaned patch cruft. the question is more if this is really something worth fixing in head...

well, you proposed to fix it in the first place, so you probably have some interest in fixing it... its fine with me. As I said, I think the same principle should apply to spinbutton, calendar and pathbar, but we can treat them separately.

well, initially i said "it is not entirely sure that this is a good idea", and it turns out it's in fact not. ;)
at least not with the patch in its current form.

mitch points out that a focus_out handler only gets triggered for CAN_FOCUS() widgets, and scrollbars/ranges are by default !CAN_FOCUS(). so the logic added by the patch isn't actually triggered.
running the test with --gdk-debug=events and described as above, you can observe that the toplevel window does indeed get a focus_out event (toplevels get this unconditionally) when the new dialog pops up.

i think if we really want to fix this kind of behaviour, we probably should do this:
- once toplevels get !NotifyInferior focus_out events during grabs, cancel the currently active X grab and emit ::grab_broken_event appropriately.
- add cleanup logic like stop_scrolling() in the above patch to the grab_broken_event() event handler of ranges, spinbuttons, etc.

You intend to leave this open for further musings, Tim ?

re comment #8, no, i'm not leaving this open, because:
a) scrollbars/ranges which are CAN_FOCUS are exceptionally rare, so the original patch won't have much effect anyway;
b) if we want abort logic to be triggered when new dialogs pop up, something like the ::grab-borken-event logic is needed as outlined in comment #7;
c) i am not even convinced that gtk really needs the ::grab-borken-event logic outlined, i'm inclined to wait for a reasonable usecase description or accessibility reason before actually working on this.

so i'll close the bug as WONTFIX for now, we can reopen it at any point later anyway.