Mouse-wheel scroll events does not propagate to viewport from fixed pos. elements

RESOLVED FIXED in mozilla1.9alpha1

Status

()

Core
Event Handling
--
minor
RESOLVED FIXED
13 years ago
2 years ago

People

(Reporter: mats, Assigned: masayuki)

Tracking

({regression, testcase})

Trunk
mozilla1.9alpha1
regression, testcase
Points:
---
Bug Flags:
blocking1.8rc1 -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments, 2 obsolete attachments)

(Reporter)

Description

13 years ago
Mouse-wheel scroll events does not propagate to viewport from fixed pos.
elements.  (This is spawned off from bug 256538).

The reason is that the fixed pos. frame hangs of the "Fixed-list" of the
Viewport frame which means traversing the frame ancestor chain in
nsEventStateManager::DoScrollText "misses" the ScrollPortFrame(html).

STEPS TO REPRODUCE:
1. Load testcase
2. position mouse over the green area
3. mouse-wheel scroll

ACTUAL RESULTS:
Nothing happens.

EXPECTED RESULTS:
Scrolling occurs.
(Reporter)

Comment 1

13 years ago
Created attachment 157878 [details]
Testcase
(Reporter)

Updated

13 years ago
Keywords: testcase

Comment 2

13 years ago
It works for me on Linux firefox 1.0.2.

Comment 3

13 years ago
It works for me on Linux firefox 1.0.2.

Comment 4

13 years ago
I'm currently using Firefox 1.0.3 on Win98se.

The scrolling works fine. It also works as expected in NS 6.2 and NS 7.2.

Comment 5

13 years ago
(In reply to comment #4)
> I'm currently using Firefox 1.0.3 on Win98se.
> 
> The scrolling works fine. It also works as expected in NS 6.2 and NS 7.2.
> 

Are you sure? It's still definitely broken for me.

Comment 6

12 years ago
1.7 -> OK
1.8 -> not scrolling

This is a regression.
Flags: blocking1.8rc1?

Comment 7

12 years ago
it's too late in the release cycle to block on this bug which is over a year old wa s present in 1.0.x.
Flags: blocking1.8rc1? → blocking1.8rc1-

Comment 8

12 years ago
I guess this should have the keyword, though.
Keywords: regression

Comment 9

12 years ago
*** Bug 279964 has been marked as a duplicate of this bug. ***

Comment 10

12 years ago
This still affects FF 1.5 - build 20051111 - Windows XP SP2.

Comment 11

12 years ago
I still experience this problem as well. 

Using latest seamonkey nightly. 

Created attachment 209211 [details] [diff] [review]
Patch rv1.0

On current code, the most ancestor frame of inner fixed positioned frame is not document root frame. Therefore, in this case, the scrollable frame is not found on current document if the fixed positioned context doesn't have scrollable view.

Therefore, my patch processes like as the parent frame of root frame of fixed positioned view is document root frame.
Assignee: mats.palmgren → masayuki
Status: NEW → ASSIGNED
Attachment #209211 - Flags: superreview?(roc)
Attachment #209211 - Flags: review?(roc)
Created attachment 209254 [details] [diff] [review]
Patch rv1.1
Attachment #209211 - Attachment is obsolete: true
Attachment #209254 - Flags: superreview?(roc)
Attachment #209254 - Flags: review?(roc)
Attachment #209211 - Flags: superreview?(roc)
Attachment #209211 - Flags: review?(roc)
(Assignee)

Updated

12 years ago
Attachment #209254 - Flags: branch-1.8.1?(roc)
This approach is a bit complex and hard to understand. I suggest an approach that results in cleaner code:

Define a new helper static function called GetParentFrameToScroll(nsIFrame* aFrame) that returns aFrame's parent, unless aFrame is fixed-pos in which case it returns the root scrollable frame if one exists. Call this method in the 'for' loop instead of using "scrollFrame = scrollFrame->GetParent()".

In GetParentFrameToScroll, detect that aFrame is fixed-pos by checking whether it's in its parent's fixed-pos child list. Not the fastest, but that doesn't matter here. If it is fixed-pos, get the root scroll frame by calling GetRootScrollFrame, which you should move from here
http://lxr.mozilla.org/seamonkey/source/layout/base/nsPresShell.cpp#2662
into a method in nsPresContext that is not virtual and takes no parameters (get the root frame from the frame manager, like here
http://lxr.mozilla.org/seamonkey/source/layout/base/nsPresShell.cpp#4541
Roc:

> In GetParentFrameToScroll, detect that aFrame is fixed-pos by checking whether
> it's in its parent's fixed-pos child list.

What is "fixed-pos child list"?
the list you get when you call parentFrame->GetFirstChild(nsLayoutAtoms::fixedList).
Created attachment 210372 [details] [diff] [review]
Patch rv2.0

Oh, your comment is too late for this patch...
But this patch can fix this bug.
Should we use the list?

# This patch changes pseudo-interface. So, we cannot take this for 1.8 branch...
Attachment #209254 - Attachment is obsolete: true
Attachment #210372 - Flags: superreview?(roc)
Attachment #210372 - Flags: review?(roc)
Attachment #209254 - Flags: superreview?(roc)
Attachment #209254 - Flags: review?(roc)
Attachment #209254 - Flags: branch-1.8.1?(roc)
Created attachment 210376 [details]
testcase2
Comment on attachment 210372 [details] [diff] [review]
Patch rv2.0

That'll do. That looks great.
Attachment #210372 - Flags: superreview?(roc)
Attachment #210372 - Flags: superreview+
Attachment #210372 - Flags: review?(roc)
Attachment #210372 - Flags: review+
checked-in to trunk.
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9alpha
Created attachment 210387 [details] [diff] [review]
fix bustage
Did you request branch approval before? I have a request but it looks like you cancelled it. I would approve this for 1.8.1 branch if requested.
Roc:

The latest patch is changing nsIPresShell pseudo-interface, so the patch cannot go to 1.8 branch. If we want to take it to 1.8 branch, we need another patch...
Ah, right. I don't think it's worth it then.

Comment 25

11 years ago
*** Bug 358044 has been marked as a duplicate of this bug. ***

Comment 26

11 years ago
*** Bug 358945 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.