298171 - [BeOS ]Scrolling with mouse over iframe (and maybe other views) jumps around

Status: RESOLVED FIXED

(Core Graveyard :: Widget: BeOS, defect)

Description

[tqh]

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..

Comment 1

[tqh]

Attachment: 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.

Comment 2

[tqh]

> ... only the mouse that ...
Should be:
... only the view that ...

Comment 3

[tqh]

IMO, scrolling is much nicer.

Comment 4

[tqh]

Comment on attachment 186742 [details] [diff] [review]
Suggested patch

Oops, better patch coming.

Comment 5

[tqh]

Attachment: 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.

Comment 6

[tqh]

*** Bug 296849 has been marked as a duplicate of this bug. ***

Comment 7

[tqh]

Comment on attachment 186745 [details] [diff] [review]
Improved patch

r?

Comment 8

[tqh]

Also some minor cleanup in nsWindow.h for things that are either giving warnings
(already declared in nsBaseWidget, not needed or faulty)

Comment 9

[Sergei Dolgov]

Comment on attachment 186745 [details] [diff] [review]
Improved patch

r=sergei_d

Comment 10

[Sergei Dolgov]

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

Comment 11

[Sergei Dolgov]

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?

Comment 12

[tqh]

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.