Closed Bug 256538 Opened 19 years ago Closed 18 years ago

Can't scroll window with scroll wheel if a position: fixed element covers the top-left corner of the viewport.

Categories

(Camino Graveyard :: General, defect)

PowerPC
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
Camino0.9

People

(Reporter: moz, Assigned: mikepinkerton)

References

()

Details

(Keywords: regression, testcase)

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a3) Gecko/20040820 Camino/0.8+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a3) Gecko/20040820 Camino/0.8+

Scrolling works fine for me with Camino builds before 2004-08-07 (incidentally
the day that the fix for Bug 97283 was checked in). This does not affect
Firefox. I have had a few people check under 10.3, but they were able to scroll
just fine, so I'm guessing it's a 10.2-only occurrence (it could be my machine,
too, but I'd rather play it safe).

Other test URL: http://weblogs.mozillazine.org/hyatt/ with one of the "Clean"
stylesheets selected.

Reproducible: Always
Steps to Reproduce:
1. Navigate to a page with a position: fixed; element that covers the top-left
corner of the viewport.
2. Attempt to scroll with a scroll wheel.

Actual Results:  
Page did not scroll.

Expected Results:  
Page should scroll.
It reproduced.
And there is no problem in Mozilla.

Mac OS X 10.3.5
-- Camino 2004081919 (v0.8+)
-- Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a3) Gecko/20040822
is this different from the scrollwheel-<div> bug that affects all mozilla platforms?
I believe so, since this doesn't occur in Mozilla or Firefox. Were you referring
to Bug 237962? I've seen that one also, in Camino, Firefox, and Mozilla for
quite a while, but this one is fairly recent and seems to be Camino-only. If I
move the fixed div on either the sample page or Hyatt's weblog right or down by
1px, the scroll wheel functions properly.
I can take a look if I can dig up a Mac with a mouse-wheel...
-> mats
Assignee: pinkerton → mats.palmgren
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
Target Milestone: --- → Camino0.9
Attached file Testcase
There are two separate problems:

1. The new code in ESM::DoScrollText (bug 97283) is expecting that
   |aTargetFrame| is set to the frame that is under the mouse.
   In Camino this is not the case.
   For the testcase it's set to the text frame at position 0,0 regardless
   of the mouse position. (The |aEvent| is also at 0,0).
   This is a deeper platform-specific problem that I would prefer someone
   else have a look at.
   
2. Mouse-wheel scrolling over fixed pos. elements does not propagate so that
   it can affect the viewport scrollbar (occurs on all platforms).

This bug is about problem 1. I have spawned off bug 258006 for problem 2.

-> default owner
Assignee: mats.palmgren → pinkerton
Keywords: testcase
*** Bug 260341 has been marked as a duplicate of this bug. ***
Removing "under OS X 10.2" as this has apparently been verified under 10.3.x also.
Summary: Can't scroll window with scroll wheel under OS X 10.2 if a position: fixed element covers the top-left corner of the viewport. → Can't scroll window with scroll wheel if a position: fixed element covers the top-left corner of the viewport.
the problem is that we set the location of scroll events to 0,0, and fixed
elements don't pass scroll events. So a position:fixed element at 0,0 stops
camino from scrolling a page at all.

the original reason for doing this was performance. this patch removes the code
that sets the location to 0,0, no longer seems to impact performance, and makes
scrolling work again.
Attachment #160364 - Flags: review?(mozilla)
Comment on attachment 160364 [details] [diff] [review]
this solves the scrolling problem for all test cases i've seen

Marking r+; seems to fix a few other mild annoyances as well.
Attachment #160364 - Flags: review?(mozilla) → review+
Comment on attachment 160364 [details] [diff] [review]
this solves the scrolling problem for all test cases i've seen

should this maybe go to the branch as well?
Attachment #160364 - Flags: superreview?(pinkerton)
Attachment #160364 - Flags: superreview?(pinkerton) → superreview+
landed on trunk, dunno if we need this on the branch. i don't think so.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.