Closed Bug 784410 Opened 12 years ago Closed 12 years ago

Scrolling by the turn of the mouse wheel stops working on certain element

Categories

(Core :: Layout, defect)

15 Branch
x86
All
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla18
Tracking Status
firefox15 - ---
firefox16 + fixed
firefox17 + fixed

People

(Reporter: alice0775, Assigned: roc)

References

Details

(Keywords: regression)

Attachments

(3 files, 1 obsolete file)

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
Attached file reduced html (obsolete) —
Attached file reduced html
Attachment #653852 - Attachment is obsolete: true
Err
This does not happen in Firefox14.
Version: Trunk → 15 Branch
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
Blocks: 681192
Keywords: regression
Component: General → Layout
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.
OS: Windows 7 → All
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.
Attached patch fixSplinter Review
Assignee: nobody → roc
Attachment #654523 - Flags: review?(matspal)
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
Attachment #654523 - Flags: review?(matspal) → review+
Comment on attachment 654523 [details] [diff] [review]
fix

Review of attachment 654523 [details] [diff] [review]:
-----------------------------------------------------------------

Annoying user-facing regression. Needs to be fixed ASAP.
Attachment #654523 - Flags: approval-mozilla-beta?
Attachment #654523 - Flags: approval-mozilla-aurora?
https://hg.mozilla.org/mozilla-central/rev/17b1db7b293f
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla18
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.
Attachment #654523 - Flags: approval-mozilla-beta?
Attachment #654523 - Flags: approval-mozilla-beta+
Attachment #654523 - Flags: approval-mozilla-aurora?
Attachment #654523 - Flags: approval-mozilla-aurora+
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
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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
"サンプル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
Attachment #660701 - Flags: review?(matspal) → review+
Comment on attachment 660701 [details] [diff] [review]
mousewheel fix

Review of attachment 660701 [details] [diff] [review]:
-----------------------------------------------------------------

Another simple fix for this user-annoying bug.
Attachment #660701 - Flags: approval-mozilla-beta?
Attachment #660701 - Flags: approval-mozilla-aurora?
https://hg.mozilla.org/mozilla-central/rev/3ee856aa68d2
Status: REOPENED → RESOLVED
Closed: 12 years ago12 years ago
Resolution: --- → FIXED
Attachment #660701 - Flags: approval-mozilla-beta?
Attachment #660701 - Flags: approval-mozilla-beta+
Attachment #660701 - Flags: approval-mozilla-aurora?
Attachment #660701 - Flags: approval-mozilla-aurora+
You need to log in before you can comment on or make changes to this bug.