Closed Bug 629587 Opened 10 years ago Closed 10 years ago

page scroll synchronization with the turn of a mouse wheel is lost when mouse pointer hover over buttons. And scroll width decreases

Categories

(Core :: XUL, defect)

x86
All
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Tracking Status
blocking2.0 --- final+

People

(Reporter: alice0775, Assigned: tnikkel)

References

()

Details

(Keywords: regression, Whiteboard: [softblocker])

Attachments

(3 files)

Build Identifier:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b11pre) Gecko/20110127 Firefox/4.0b11pre ID:20110127030333

Synchronization with the turn of a mouse wheel is lost when mouse pointer hover over buttons. And scroll width decreases.

This is the factor that scroll with the mouse wheel becomes slow.

Reproducible: Always

Steps to Reproduce:
1. Start Minefield with new profile and install much add-ons
2. Enable Smooth Scroll
3. Open Addons Manager (Ctrl+Shift+A) and Select Extensions pane

4. Put a mouse pointer on a button
5. Scroll by mouse wheel one tick

Try to compare it with the following
6. put a mouse pointer on a addon's icon
7. Scroll by mouse wheel one tick

Actual Results:
 Synchronization with the turn of a mouse wheel is lost when mouse pointer hover over buttons. And scroll width decreases

Expected Results:
 It should be scrolled in the same speed
See Also: → 623615
Summary: [Addons manager]Synchronization with the turn of a mouse wheel is lost when mouse pointer hover over buttons. And scroll width decreases → [Addons manager]page scroll synchronization with the turn of a mouse wheel is lost when mouse pointer hover over buttons. And scroll width decreases
Seems about the same for me on my Linux machine.
(In reply to comment #1)
> Seems about the same for me on my Linux machine.

Yes, It does not happen on Linux build.

It happens on Windows build only.
Summary: [Addons manager]page scroll synchronization with the turn of a mouse wheel is lost when mouse pointer hover over buttons. And scroll width decreases → [Addons manager][Win7,WinXP]page scroll synchronization with the turn of a mouse wheel is lost when mouse pointer hover over buttons. And scroll width decreases
I wonder if this is a regression or not.
WORKAROUND: append the following CSS to userContent.css

.addon-control {
  box-shadow: none !important;
}
Attached file sample xul
Try wheel scroll
you should enable smooth scoll

Left side box : wheel scroll is lagged
Right side box: wheel scroll is normal
Attachment #509754 - Attachment mime type: application/octet-stream → text/plain
Attachment #509754 - Attachment mime type: text/plain → text/xml
Component: Add-ons Manager → XUL
Product: Toolkit → Core
QA Contact: add-ons.manager → xptoolkit.widgets
The problem in comment #5 also happens on Linux.
OS: Windows 7 → All
Wow, thats a great test case Alice. I can see the difference on Linux. Has that testcase always acted like that or did it regress sometime I wonder.
Regression window for attachment 509754 [details](cached m-c hourly):
Works:
http://hg.mozilla.org/mozilla-central/rev/aefb8c332502
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b6pre) Gecko/20100910 Firefox/4.0b6pre ID:20100911084458
Fails:
http://hg.mozilla.org/mozilla-central/rev/26bfc0860822
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b6pre) Gecko/20100910 Firefox/4.0b6pre ID:20100911102300
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=aefb8c332502&tochange=26bfc0860822
Candidate:
Bug 590039 - fix blur radius computation and rename -moz-box-shadow to box-shadow
Blocks: 590039
blocking2.0: --- → ?
That's because "box-shadow" will have no effect prior to that change set because it wasn't recognized; only the the prefixed version -moz-box-shadow was recognized.
Regression window(cached m-c hourly):
Works:
http://hg.mozilla.org/mozilla-central/rev/b94cf8147ccd
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20100111 Minefield/3.7a1pre ID:20100111140136
Fails:
http://hg.mozilla.org/mozilla-central/rev/47cd92d616d7
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20100111 Minefield/3.7a1pre ID:20100111150802
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b94cf8147ccd&tochange=47cd92d616d7
Candidate;
Bug 526394 - Move scrolling out of the view system into layout
Blocks: 526394
No longer blocks: 590039
Interesting, thank you very much Alice.
This might be the explanation for the mysterious scrolling bugs (slow scrolling, laggy scrolling, jerky scrolling, amount of scrolling decreased) we have been seeing.
The first bad revision is:
changeset:   37083:4ccff5df452c
user:        Robert O'Callahan <robert@ocallahan.org>
date:        Thu Oct 08 16:01:15 2009 +1300
summary:     Bug 526394. Part 31: Move scroll implementation into nsGfxScrollFrame. r=mats
smooth scroll just makes this more obvious, it happens without it.
Assignee: nobody → tnikkel
blocking2.0: ? → final+
Attached patch patchSplinter Review
We reflow while smooth scrolling and nsGfxScrollFrameInner::CurPosAttributeChanged gets called from the scroll frames ReflowFinished reflow callback. It gets the position information from the scrollbar and then calls ScrollTo(dest, INSTANT) because the scrollbar does not have the smooth attribute (it didn't on 3.6 either). That cancels the inprogress async smooth scroll. dest is actually the current position of the scroll frame anyway, so the scroll call is useless, but it only determines that after cancelling the async scroll. http://hg.mozilla.org/mozilla-central/rev/4ccff5df452c removed a "if (x == curPosX && y == curPosY) return;" check in nsGfxScrollFrameInner::CurPosAttributeChanged. I think we should just restore it.

This patch also improves the behaviour when I scroll down quickly with the mouse wheel and smooth scrolling is turned off.
Attachment #511135 - Flags: review?(roc)
Summary: [Addons manager][Win7,WinXP]page scroll synchronization with the turn of a mouse wheel is lost when mouse pointer hover over buttons. And scroll width decreases → page scroll synchronization with the turn of a mouse wheel is lost when mouse pointer hover over buttons. And scroll width decreases
The reason that non-smooth scrolling is improved is that we still use an async scroll with a timer to do the scrolling, so if we get a couple of nsGfxScrollFrameInner::ScrollTo calls without the async timer happening and then a reflow (off the refresh driver or will paint) it will end up in nsGfxScrollFrameInner::CurPosAttributeChanged and try to scroll INSTANT to the current position even though there is an async scroll object pending for many pixels further down.

The following dump makes it plain.

nsGfxScrollFrameInner::ReflowFinished calling CurPosAttributeChanged
I'm nsGfxScrollFrameInner::CurPosAttributeChanged and i'm calling ScrollTo
nsGfxScrollFrameInner::ScrollTo aScrollPosition 0 0 (0 0) mode INSTANT
nsGfxScrollFrameInner::ScrollTo aScrollPosition 0 51 (0 3060) mode SMOOTH
nsGfxScrollFrameInner::AsyncScrollCallback calling ScrollToImpl with dest 0 51 (0 3060)
nsGfxScrollFrameInner::ScrollTo aScrollPosition 0 102 (0 6120) mode SMOOTH
nsGfxScrollFrameInner::ScrollTo aScrollPosition 0 153 (0 9180) mode SMOOTH
nsGfxScrollFrameInner::ScrollTo aScrollPosition 0 204 (0 12240) mode SMOOTH
nsGfxScrollFrameInner::ScrollTo aScrollPosition 0 255 (0 15300) mode SMOOTH
nsGfxScrollFrameInner::ReflowFinished calling CurPosAttributeChanged
I'm nsGfxScrollFrameInner::CurPosAttributeChanged and i'm calling ScrollTo
nsGfxScrollFrameInner::ScrollTo aScrollPosition 0 51 (0 3060) mode INSTANT
nsGfxScrollFrameInner::ScrollTo aScrollPosition 0 102 (0 6120) mode SMOOTH
nsGfxScrollFrameInner::AsyncScrollCallback calling ScrollToImpl with dest 0 102 (0 6120)
Right. OK. Great!
Whiteboard: [softblocker] → [softblocker][needs landing]
http://hg.mozilla.org/mozilla-central/rev/2ba4709dc2ce
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
I don't think anything still needs landing here.
Whiteboard: [softblocker][needs landing] → [softblocker]
You need to log in before you can comment on or make changes to this bug.