> [snip observations that the web widget is catching mouse events
> outside the thumb but inside the scrollbar]

I wrote:
> Unfortunately, this isn't really how things work. Either a 
> widget asks to capture input, in which case it can get events
> outside its boundaries, or it doesn't.

> If a widget does ask to capture events outside its boundaries, it then
> needs to have some idea about what to do with them.

> And that's hard (and each group will implement it differently, but
> poorly)....

Kalle wrote:
> I don't understand this, why would the browser widget be interested in
> events that happen on the scrollbar widget?

Pictures required:

Browser Widget
+---------------------------------------+
|This is a web page. It's a bit wide..|^|
|This is web content, it isn't interes| |
|Sometimes there might be /^%$TRER^Y\ | |
|Other times you might    HSDfkjl435H |X|
|have a <link> or <button>DSFGDFGDR$T | |
|there are other objects  SDFDSFDSFDS | |
|but most people forget   SDFDSFSDFSD | |
|about them.              sDFSDFDSFDS | |
|_____________________________________/v|
|<XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX     >x|
+---------------------------------------+

We have two thumbs (labeled X and XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX for
vertical and horizontal scrolling in their respective tracks).

If you click on X, and then drag over the button or link, or any other
part of the page, then X gets the events and has to decide what that
means. If you happen to reach all the way to the <link> in my picture,
something has /probably/ gone wrong. That said, the exact algorithm that
Gtk uses is to my knowledge not exposed (unlike Gtk Widget theming which
is exposed). The windows algorithm seems to involve the thumb halting
movement when the distance from the track is >~60px, offhand, I don't
believe there's an API available to find out this information either.

+---------------------------------------+
|                                     |^|
|                                     | |
|                                     | |
|                  1                  |2|
|                                     | |
|                                     | |
|                                     | |
|                                     | |
|_____________________________________/v|
|<                 3                  >4|
+---------------------------------------+

1 - browser content
2 - browser widget emulating vertical scrollbar
3 - browser widget emulating horizontal scrollbar
4 - browser unhappy

More detailed pictures are of course available, but usually the
interesting ones involve much more complicated pages. For example, pages
that are 200,000 pixels tall (historically some widgets especially
related to X toolkits had issues with 16bit limits). if you think that
your toolkit can really handle such widgets correctly, I have a number
of crashing bugs involving X and images that are e.g. 1x200,000 in
dimension [you're of course welcome to volunteer to fix them].

You will not find a properly functioning css3 capable web browser which
actually uses native widgets. They *all* synthesize them (some do more
synthesis, and some less, but all widgets are synthetic).

> That's what happens
> anyway, I start a drag over the scrollbar outside the thumb and the
> page is panned as if I dragged on the page.
> 
> Unless of course (and I guess this is the case) it's not really two
> widgets but one widget doing funny things.

It's not not two widgets, but it isn't a browser widget and a gtk
scrollbar widget. It's a browser content area and a browser scrollbar
widget emulating a gtk scrollbar widget, both inside a browser widget.

I'm glad you figured out the general problem.

> I don't see this with any
> other application, the scrollbar will "jump" to the direction of the
> stylus as expected if I start a drag outside the thumb.

> So I suppose this particular bug can and should be fixed in the
> browser UI / browser engine...

Lots of things can be done in lots of places, some things can't be done
correctly in any one place. Some things shouldn't be done. And some
things might never be done.
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Reply via email to