This bug is to track the work need to update wkScrollbarMinimumTotalLengthNeededForThumb() to match the implementation in WebKitSystemInterface.
Created attachment 104139 [details] Patch
Comment on attachment 104139 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=104139&action=review > Source/WebCore/platform/chromium/ScrollbarOverlayUtilitiesChromiumMac.mm:213 > + [painter knobOverlapEndInset] + why are trackOverlapEndInset and knobOverlapEndInset not *2?
Comment on attachment 104139 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=104139&action=review >> Source/WebCore/platform/chromium/ScrollbarOverlayUtilitiesChromiumMac.mm:213 >> + [painter knobOverlapEndInset] + > > why are trackOverlapEndInset and knobOverlapEndInset not *2? I spent some time running this on Lion to see if I could figure out why the various values meant but I still don't understand it. When I run this for opaque scrollbars I get the following values: - knobMinLenth: 20 - knobEndInset: 2 - everything else: 0 For overlay scrollbars I get: - knowMinLength: 26 - trackOverlapEndInset: 3 - trackEndInset: 1 At this point I just gave up and copied the code from the disassembly.
For reference, here's the disassembly: http://code.google.com/p/chromium/issues/detail?id=74057#c35 and here's what I understood from it: 0xf0(%rbp) <- knobMinLength + trackOverlapEndInset + knobOverlapEndInset 0xe8(%rbp) <- trackEndInset movq 0x0010629d(%rip),%rsi trackEndInset movq %rbx,%rdi callq 0x00112d3e -[%rdi trackEndInset] movsd %xmm0,0xe8(%rbp) %xmm0 <- knobEndInset movq 0x00106281(%rip),%rsi knobEndInset movq %rbx,%rdi callq 0x00112d3e -[%rdi knobEndInset] %xmm0 <- knobEndInset + trackEndInset addsd 0xe8(%rbp),%xmm0 %xmm0 <- (knobEndInset + trackEndInset) * 2 addsd %xmm0,%xmm0 %xmm0 <- knobMinLength + trackOverlapEndInset + knobOverlapEndInset + (knobEndInset + trackEndInset) * 2 addsd 0xf0(%rbp),%xmm0
Comment on attachment 104139 [details] Patch LGTM
Comment on attachment 104139 [details] Patch my rubberstamp is quick like a monkey.
Comment on attachment 104139 [details] Patch Rejecting attachment 104139 [details] from commit-queue. Failed to run "['./Tools/Scripts/webkit-patch', '--status-host=queues.webkit.org', '--bot-id=ec2-cq-02', '--port..." exit_code: 1 Last 500 characters of output: it-commit-queue/LayoutTests/ChangeLog neither lists a valid reviewer nor contains the string "Unreviewed" or "Rubber stamp" (case insensitive). Updating OpenSource From git://git.webkit.org/WebKit + 0651a90...54d0520 master -> origin/master (forced update) Current branch master is up to date. Updating chromium port dependencies using gclient... ________ running '/usr/bin/python gyp_webkit' in '/mnt/git/webkit-commit-queue/Source/WebKit/chromium' Updating webkit projects from gyp files... Full output: http://queues.webkit.org/results/9403679
Huh! If you reupload with `land-safely`, the script will hopefully fill in the "reviewed by" line; if not you'll have to do that manually. Weird the commit-queue didn't do that.
Created attachment 104152 [details] Patch for landing
Comment on attachment 104152 [details] Patch for landing Rejecting attachment 104152 [details] from commit-queue. sail@chromium.org does not have committer permissions according to http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/common/config/committers.py. - If you do not have committer rights please read http://webkit.org/coding/contributing.html for instructions on how to use bugzilla flags. - If you have committer rights please correct the error in Tools/Scripts/webkitpy/common/config/committers.py by adding yourself to the file (no review needed). The commit-queue restarts itself every 2 hours. After restart the commit-queue will correctly respect your committer rights.
Comment on attachment 104152 [details] Patch for landing Clearing flags on attachment: 104152 Committed r93202: <http://trac.webkit.org/changeset/93202>
All reviewed patches have been landed. Closing bug.