Closed Bug 529638 Opened 15 years ago Closed 15 years ago

sidebar tree expands/collapses in response to horizontal scrolling when it shouldn't

Categories

(Core :: Widget: Win32, defect)

1.9.2 Branch
x86
Windows XP
defect
Not set
normal

Tracking

()

VERIFIED FIXED
Tracking Status
status1.9.2 --- beta4-fixed

People

(Reporter: polidobj, Assigned: khuey)

References

Details

(Keywords: regression)

Attachments

(1 file)

When the sidebar (history/bookmark) has focus but the mouse is over the web page area doing horizontal scrolling with the mouse will scroll the page horizontally if it can but the action will also have an effect on the sidebar as if the mouse was over the sidebar.  I have a mouse with a tilt wheel to do horizontal scrolling.  This does affect vertical scrolling.

This is present in 3.7a1pre.  It is not present in 3.5.x.  I have not tried a 3.6 build.  I don't have one handy ATM.

1. open a sidebar and make sure the tree has focus.  
2. move the mouse over the page area
3. scroll horizontally using the mouse 

Actual: The page scrolls and the tree in the sidebar expands/collapses.

Expected: The sidebar should not react to mouse actions when the mouse is not over the control.  Well at least that's how vertical scrolling works.

Maybe this is a result of the focus refactoring??
Summary: sidebar scrolls horizontally when it shouldn't → sidebar tree expands/collapses in response to horizontal scrolling when it shouldn't
This problem does happen in the latest 3.6 build.  I don't have time at the moment to get the regression range there.
Flags: blocking-firefox3.6?
Suspect bug 507222 - can you do a local backout and see if it fixes?

cc'ing kyle and reviewer.
Component: General → Widget: Win32
Flags: blocking-firefox3.6?
Product: Firefox → Core
QA Contact: general → win32
Version: Trunk → 1.9.2 Branch
(carrying over blocking request)
Flags: blocking1.9.2?
Hmm.  Not really sure how to go about reproducing this without the hardware.

You're saying that the page scrolls horizontally and the tree expands simultaneously?  This seems very odd indeed.
(In reply to comment #3)
> Suspect bug 507222 - can you do a local backout and see if it fixes?

On second look, I did change some code (The HandleScrollingPlugins function in nsWindow.cpp) that would get called on a WM_MOUSEHWHEEL message, so there's a good chance I broke this :-)  Accepting the bug.  I'll trace through the logic and see if I can figure out what I broke.
Assignee: nobody → me
Status: NEW → ASSIGNED
Yep, it's me.  Patch in a few.
Attached patch PatchSplinter Review
We need to preserve all of the output of calling ProcessMessage.  Failing to pass back the LRESULT, combined with accidentally continuing to process the message in the event it was passed to another nsWindow caused this.
Attachment #413466 - Flags: review?(roc)
Attachment #413466 - Flags: approval1.9.2?
Attachment #413466 - Flags: review?(roc)
Attachment #413466 - Flags: review+
Attachment #413466 - Flags: approval1.9.2?
Attachment #413466 - Flags: approval1.9.2+
Think we should block on this, despite it being a low user impact, good hygene and such. So now you've permission to check it in via approval and the blocking flag! :)

Thanks for the quick fix, Kyle.
Flags: blocking1.9.2? → blocking1.9.2+
(In reply to comment #9)
> Think we should block on this, despite it being a low user impact, good hygene
> and such. So now you've permission to check it in via approval and the blocking
> flag! :)
> 
> Thanks for the quick fix, Kyle.

No problem at all.
Keywords: checkin-needed
Blocks: 507222
Pushed http://hg.mozilla.org/mozilla-central/rev/b88f32238108
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Whiteboard: [neds 192 landing]
Whiteboard: [neds 192 landing] → [needs 192 landing]
Could the reporter verify this?  I'd feel a bit better if someone with the hardware to test it said it was fixed :-)
It's fixed.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: