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

RESOLVED FIXED

Status

Core Graveyard
Widget: BeOS
--
minor
RESOLVED FIXED
13 years ago
4 years ago

People

(Reporter: tqh, Assigned: tqh)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment, 1 obsolete attachment)

4.24 KB, patch
Sergei Dolgov
: review+
Details | Diff | Splinter Review
(Assignee)

Description

13 years ago
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..
(Assignee)

Comment 1

13 years ago
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.
Attachment #186742 - Flags: review?(sergei_d)
(Assignee)

Comment 2

13 years ago
> ... only the mouse that ...
Should be:
... only the view that ...

(Assignee)

Updated

13 years ago
Blocks: 266252
(Assignee)

Comment 3

13 years ago
IMO, scrolling is much nicer.
(Assignee)

Comment 4

13 years ago
Comment on attachment 186742 [details] [diff] [review]
Suggested patch

Oops, better patch coming.
Attachment #186742 - Flags: review?(sergei_d)
(Assignee)

Comment 5

13 years ago
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
(Assignee)

Comment 6

13 years ago
*** Bug 296849 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 7

13 years ago
Comment on attachment 186745 [details] [diff] [review]
Improved patch

r?
Attachment #186745 - Flags: review?(sergei_d)
(Assignee)

Comment 8

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

Comment 9

13 years ago
Comment on attachment 186745 [details] [diff] [review]
Improved patch

r=sergei_d
Attachment #186745 - Flags: review?(sergei_d) → review+
(Assignee)

Updated

13 years ago
Attachment #186745 - Flags: approval1.8b3?

Updated

13 years ago
Attachment #186745 - Flags: approval1.8b3? → approval1.8b3+

Comment 10

13 years ago
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
(Assignee)

Updated

13 years ago
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED

Comment 11

13 years ago
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?
(Assignee)

Comment 12

13 years ago
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. 
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.