WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
72400
Scrollbar uiStateTransitionProgress requires tracking the mouse all the time
https://bugs.webkit.org/show_bug.cgi?id=72400
Summary
Scrollbar uiStateTransitionProgress requires tracking the mouse all the time
Beth Dakin
Reported
2011-11-15 11:01:24 PST
With
https://bugs.webkit.org/show_bug.cgi?id=71490
and
http://trac.webkit.org/changeset/99493
I added support for uiStateTransitionProgress on scrollbars. To properly animate uiStateTransitionProgress, we keep track of whenever the mouse enters or exits a scrollbar. However, to fully support the feature, we have to keep track of that information even when the window is not key. Currently, we only track mouseMoved events when the window is key, so this needs to change to fully support uiStateTransitionProgress. <
rdar://problem/10409328
>
Attachments
Patch
(28.74 KB, patch)
2011-11-15 11:35 PST
,
Beth Dakin
gustavo
: commit-queue-
Details
Formatted Diff
Diff
Patch that probably won't break builds
(28.77 KB, patch)
2011-11-15 13:45 PST
,
Beth Dakin
no flags
Details
Formatted Diff
Diff
Smaller patch that does less
(4.35 KB, patch)
2011-11-15 16:42 PST
,
Beth Dakin
no flags
Details
Formatted Diff
Diff
Now with WebCore
(13.18 KB, patch)
2011-11-15 16:46 PST
,
Beth Dakin
darin
: review+
Details
Formatted Diff
Diff
Show Obsolete
(3)
View All
Add attachment
proposed patch, testcase, etc.
Beth Dakin
Comment 1
2011-11-15 11:35:39 PST
Created
attachment 115209
[details]
Patch
Gustavo Noronha (kov)
Comment 2
2011-11-15 11:52:16 PST
Comment on
attachment 115209
[details]
Patch
Attachment 115209
[details]
did not pass gtk-ews (gtk): Output:
http://queues.webkit.org/results/10372632
Beth Dakin
Comment 3
2011-11-15 13:45:04 PST
Created
attachment 115235
[details]
Patch that probably won't break builds
Beth Dakin
Comment 4
2011-11-15 16:42:32 PST
Created
attachment 115279
[details]
Smaller patch that does less I decided to break this up into two bugs so that the patches will be less intimidating. This patch makes is so we track the mouse all of the time when (at the time the WKView is constructed) the recommended scrollbar style is the legacy style. The rest of the work in my initial patch was to update this dynamically whenever the scrollbar style changes, but I will do that in a second patch instead.
Beth Dakin
Comment 5
2011-11-15 16:46:02 PST
Created
attachment 115280
[details]
Now with WebCore Oops, forgot to include WebCore changes in that one.
Darin Adler
Comment 6
2011-11-15 22:54:16 PST
Comment on
attachment 115280
[details]
Now with WebCore View in context:
https://bugs.webkit.org/attachment.cgi?id=115280&action=review
> Source/WebCore/platform/Scrollbar.h:97 > + bool mouseEntered();
Why does this have a return value? The only caller doesn’t use it.
Beth Dakin
Comment 7
2011-11-16 11:36:43 PST
(In reply to
comment #6
)
> (From update of
attachment 115280
[details]
) > View in context:
https://bugs.webkit.org/attachment.cgi?id=115280&action=review
> > > Source/WebCore/platform/Scrollbar.h:97 > > + bool mouseEntered(); > > Why does this have a return value? The only caller doesn’t use it.
Thanks for the review! I gave it a return value so that it would be like mouseExited() which has a return value. But ultimately, I think that you are right; it's silly to give something a totally unused return value. I'll remove it.
Beth Dakin
Comment 8
2011-11-16 11:53:33 PST
Committed change with revision 100483.
Simon Fraser (smfr)
Comment 9
2011-11-18 11:21:49 PST
This is in the blame list for this API test failure:
http://build.webkit.org/builders/SnowLeopard%20Intel%20Release%20%28Tests%29/builds/34756/steps/run-api-tests/logs/stdio
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug