> Yes, the general problem seems to be that there is a bug in the > emulation that makes it work differently and, more importantly, in a > way that is error prone and confuses the user. > > Let's take that pretty picture here:
Glad it came in handy (and I do appreciate the explanation, because w/o yours, I indeed had a different understanding of which problem was being discussed) > +---------------------------------------+ > | |^| > | |-| > | |-| > | 1 |2| > | |-| > | |-| > | |-| > | |-| > |_____________________________________/v| > |< 3 >4| > +---------------------------------------+ > > Now let's consider the two scenarios: > > 1) user pushes stylus down on 2 (the thumb) and starts dragging > 2) user misses 2, hitting the dashed area instead and starts dragging > > 1) is fine, works reliably (as long as the touchscreen does) > and so on. > > 2) is where normally nothing but a "jump" in the location towards the > cursor happens (for the record, works like this on this ff3b3 I'm > writing this on). On ITOS2008/microb, the page is not jumping but > instead starts to pan. Gah, I misread this twice. (it's late) Here's what I originally wrote (it's irrelevant): Some of these problems stem from bogus behaviors in the kernel/x-server. And some of them stem from hacks to work around the aforementioned. I believe that some of these problems are resolved in internal builds. Capture to me is only interesting when the user accidentally strays from 2 into 1. If you're only worried about 2 and 2's track, ok. We have some changes for it (but they're useless w/o a new xserver). Right, this is purely a bug introduced by the panning code, and basically it's probably capturing too much (capturing is dangerous) http://timeless.justdave.net/mxr-test/os2008/source/microb-engine-1.0.3/ debian/patches/gtkmozembed/gtkmozembed.diff?raw=1 Is the relevant file as shipped with 2008. The evil code can be seen here: http://timeless.justdave.net/mxr-test/garage/source/browser/mozilla/trun k/microb-engine/microb-engine/debian/patches/gtkmozembed/gtkmozembed.dif f#2043 >From what I can tell, it doesn't think about scrollbar (tracks) and is very brutish. If you can figure out a way to make it behave sanely, I'll commit it tomorrow :). Offhand, it should probably find out the clientRect (?) bounds for the elemnt it's trying to scroll and if the point is outside those bounds it should fall through to the normal behavior. Perhaps dolske (irc.mozilla.org) or someone else there w/ a device would be able to help (I'm reviewing about 600 bugs right now, and while I'd love to fix this one, I unfortunately need to push those around instead), it's probably ~10 lines of code limited to that one function. > Now, it's normally not an issue (nobody scrolls from the shaft are > anyway) but when it is difficult to hit the thumb due to it's size > (those huge pages you talked about) Indeed, please feel free to create some nice testcases and file a user interface feedback bug against the ui designers explaining that tiny thumbs don't work for big thumbed users. (sorry, I've given up, I'm hoping they listen to customers.) Actually, w/ about:config, whether I'm zoomed to 80% or 240%, the scrollbar thumb size doesn't change, it's about 1/4th the size of any of my fingers (which upon reflection is clearly fairly unreasonable as targets go...). > and the fact that the touchscreen is a shotgun instead of a sniper rifle, > it confuses the user when scrolling actually goes to the opposite > direction than what was intended. Sure, personally I blame the ui designers for this too. They introduced panning which is 180 degrees reversed from scrolling and wow, users get confused when bad things happen. I'm sorry. I'd love to fix this (and I have a fix: disabling panning), and my fix happens to solve a number of other problems too. But really, in order to do this, we'd need to make the scrollbars much more finger friendly (by we, I mean you+ui designers, I want no part in it, as long as whatever is done doesn't make web browser interaction worse than it is in firefox or microb today). > Usually you end up multiple pages in the wrong direction, Hrm, panning should never let you go more than 1.5 pages away from where you are ... (clicking repeatedly in the track otoh...) > and *poof* went your mental context of what you were doing (something > considered harmful to the user experience). This was the issue raised > originally, AFAICT. If the browser gets sent a mouse up event and then a mouse down event in the track, you'd have this problem. We're pretty much at the mercy of the x-server. Second guessing it leads to bugs (some of which you're suffering from in the track, especially one strange thing where the browser will jump one page away from top or something...) > Lots of words can be placed in a row but it doesn't mean they make a > really good sentence. > > Or was that just a elaborate version of the notorious WONTFIX? No. just a "don't assume it's simple". Some work has been done, some work may be done, and some work is stuck waiting for other groups to save the world. _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
