http://hg.mozilla.org/mozilla-central/rev/360ab7771e27 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0 ID:20120821030519 Scrolling by the turn of the mouse wheel does not work sometimes. This happens regardless of HWA. This happens Firefox14, 15Beta, Aurora16.0a2 and Nightly17.0a1. And this makes me annoy. Steps To Reproduce: 1. Start Firefox with clean profile(no add-ons and no plug-ins) 2. Open https://developer.mozilla.org/en-US/docs/Storage 3. Find "nsresult rv = mDBConn->CreateStatement" 4. left Click on the paragraph(Code Syntax highlighter?) 5. Try to scroll with mouse wheel carefully(one tick) 6. Repeat step 4 and 5 Actual Results: Scrolling by the turn of the mouse wheel does not work sometimes. And fonts in the element moves up/down 1 pixel. Expected Results: Scroll the page

Screen capture: http://youtu.be/kHnN3JjBYrI

Err This does not happen in Firefox14.

Regression window(m-i) Good: http://hg.mozilla.org/mozilla-central/rev/6fe7dd2f8f57 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Firefox/15.0a1 ID:20120510021321 Bad: http://hg.mozilla.org/mozilla-central/rev/b7b6565d12a0 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Firefox/15.0a1 ID:20120510050721 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6fe7dd2f8f57&tochange=b7b6565d12a0 Regression window(m-i) Good: http://hg.mozilla.org/integration/mozilla-inbound/rev/b5304fd23df9 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Firefox/15.0a1 ID:20120509222721 Bad: http://hg.mozilla.org/integration/mozilla-inbound/rev/67091352b7d2 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Firefox/15.0a1 ID:20120509223521 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=b5304fd23df9&tochange=67091352b7d2 Last good: c3d3bfb3b68d First bad: 9d9a3edaa0b9 Triggered by 9d9a3edaa0b9 Robert O'Callahan — Bug 681192. Part 11: Don't snap scrollrange endpoints to device pixels anymore. r=matspal

And In Caret Browsing Mode, this problem can see easily Steps To Reproduce: 1. Start Firefox with clean profile(no add-ons and no plug-ins) 2. Open https://developer.mozilla.org/en-US/docs/Storage 3. Turn on "Caret Browsing Mode" (F7) 4. Find "nsresult rv = mDBConn->CreateStatement" 5. left Click on the paragraph 6. Press "Page UP" key Actual Results: the element moves up 1 pixel. Expected Results: Scrolls the document up one screenful.

At this stage in FF15 release, we're too late to track this and it's not a chemspill-worthy issue but we'll track for 16/17.

This is tricky. The text on each line of the code samples actually overflows the line a little bit, I think because the line-height is 1.1em but the font ascenders and descenders stick out of the line a little. So we think the code sample overflows its overflow:auto container a little bit (less than a pixel in this case). If you zoom in a lot, you can see vertical scrollbars on the examples. This content should be using overflow-x:auto overflow-y:hidden, really, or changing its line-height. Having said that, nsHTMLScrollFrame::TryLayout refuses to show the vertical scrollbar in the unzoomed case unless we can scroll by at least one device pixel, and in this case we can't. The code in nsLayoutUtils::GetNearestScrollableFrameForDirection and nsLayoutUtils::GetNearestScrollableFrame should do the same.

Did you forget to include nsLayoutUtils::GetNearestScrollableFrameForDirection in the patch? (comment 8 mentioned it should have the same change) If so, perhaps we should share this code, in say bool nsIScrollableFrame::CanScrollInDirection(Direction aDirection)

Nevermind, I see that this is GetNearestScrollableFrameForDirection actually although the diff says otherwise, and GetNearestScrollableFrame doesn't have this check...

Comment on attachment 654523 [details] [diff] [review] fix Looks fine, r=mats

Comment on attachment 654523 [details] [diff] [review] fix Review of attachment 654523 [details] [diff] [review]: ----------------------------------------------------------------- Annoying user-facing regression. Needs to be fixed ASAP.

(Low risk too)

Comment on attachment 654523 [details] [diff] [review] fix [Triage Comment] Low risk fix for a recent Firefox regression that may cause user pain. Approving for branches.

https://hg.mozilla.org/releases/mozilla-aurora/rev/c896d87bbe70 https://hg.mozilla.org/releases/mozilla-beta/rev/8082d8212064

I tested with STR in comment#0 and attachment 653866 [details] as well, I can still reproduce. It seems nothing changed. http://hg.mozilla.org/mozilla-central/rev/a86b00fa6bc6 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 ID:20120904030512

And I can reproduce the problem in Aurora17.a2 and Beta16. It seems nothing changed. http://hg.mozilla.org/releases/mozilla-aurora/rev/c896d87bbe70 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0 ID:20120905040812 http://hg.mozilla.org/releases/mozilla-beta/rev/8082d8212064 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20120904 Firefox/16.0 ID:20120905041410

I can also reproduce in the following page. http://www.natural-science.or.jp/article/20120220155529.php#h2_1 "サンプル１：tutorial1.html（視点と光源の設定、立方体の描画）"

I fixed scrolling with the keyboard, but not with the mousewheel, which of course is what Alice originally filed this about.

Comment on attachment 660701 [details] [diff] [review] mousewheel fix r=mats

Comment on attachment 660701 [details] [diff] [review] mousewheel fix Review of attachment 660701 [details] [diff] [review]: ----------------------------------------------------------------- Another simple fix for this user-annoying bug.

https://hg.mozilla.org/releases/mozilla-aurora/rev/a728bf11ff1d https://hg.mozilla.org/releases/mozilla-beta/rev/5460444bc681