Scrolling by using the scrollbar, and moving mouse out over other content (iframes?) causes webpages to jump unpredictable. This is because several views sends mouse moved events when only the view which got the mouse down should. Patch on the way..
Created attachment 186742 [details] [diff] [review] Suggested patch When the mouse is held down only the mouse that sent the mouse down event sends mouse moved events. This is not done during DND.
> ... only the mouse that ... Should be: ... only the view that ...
IMO, scrolling is much nicer.
Comment on attachment 186742 [details] [diff] [review] Suggested patch Oops, better patch coming.
Created attachment 186745 [details] [diff] [review] Improved patch This one has another scrolling improvment as it sets the view transparent which means it don't redraws itself in the viewcolor first. Also I corrected the mousemoved part. And as it touches same parts as bug 296849 I will set that one as a duplicate and have whole fix in this.
Attachment #186742 - Attachment is obsolete: true
*** Bug 296849 has been marked as a duplicate of this bug. ***
Comment on attachment 186745 [details] [diff] [review] Improved patch r?
Attachment #186745 - Flags: review?(sergei_d)
Also some minor cleanup in nsWindow.h for things that are either giving warnings (already declared in nsBaseWidget, not needed or faulty)
Comment on attachment 186745 [details] [diff] [review] Improved patch r=sergei_d
Attachment #186745 - Flags: review?(sergei_d) → review+
Attachment #186745 - Flags: approval1.8b3? → approval1.8b3+
Commited: 2005-06-22 14:44 nsWindow.cpp 1.9->1.91 nsWindow.h 1.33->1.34 tqh, close bug if all is OK
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
tqh, digging DnD things i returned to this patch and got confused now. How comment //We didn't start the mouse down ****. corresponds to if(*** && buttons) return; maybe there must be "!buttons" instead?
If the message is null (we're not doing dragging) and we wern't the view that got the mouseDown (restoreMouseMask) and we actually have gone thru mouseDown and buttons are pressed (buttons != 0) Then we shouldn't do anything as only the view that got the mousedown is the view handling it. Most common case scrolling. When there is dragging we want to do things as the view might receive and show that it can recieve drops. When we don't hold a button down, this view is the only view doing things. It all has to do with the fact that we listen to mouseevents when we aren't the active view on mousedowns.
You need to log in before you can comment on or make changes to this bug.