63663 - can't scroll in a document using fixed position layout with keyboard/mousewheel

Status: RESOLVED FIXED

(Core :: Layout: Positioned, defect, P3)

Description

[David Taylor]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001223
BuildID:    2000122308

In the viewer demos test #12, when the window is small enough to cause a
scrollbar, it is impossible to scroll using either the keyboard keys
(up/down/pgup/pgdown/home/end/etc), or the mouse wheel.  Scrolling using the
scrollbar does work as expected.

Reproducible: Always
Steps to Reproduce:
1. Load Debug -> Viewer Demos -> #12 More Fixed Pos.
2. Attempt to scroll using up/down keys.
3. Attempt to scroll using mousewheel, if you have one.
4. Attempt to scroll using scrollbar.

Actual Results:  Document only scrolls when using scrollbar.

Expected Results:  Document should scroll using all three methods.

Comment 1

[David Taylor]

Attachment: testcase (slightly simplified version of viewer demo #12)

Comment 2

[Duncan Findlay]

I can reproduce this with 2000122320 on win98.  confirming.  sending to XP T/W.

Comment 3

[Peter Trudelle]

->saari for triage

Comment 4

[saari (gone)]

unrelated to viewer, happens in Mozilla too. Ducky.

Comment 5

[Peter Trudelle]

putting access keyword where it belongs, ->bryner

Comment 6

[John Morrison]

Still a bug with the new, new, viewmanager, too.
user_pref("nglayout.debug.enable_scary_view_manager", true);

Comment 7

[John Morrison]

So, roc. This is another event related bug with fixed positioning. Do you know 
what's up with this one too?

(adjusting severity, since we are pushing for access).

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Nothing springs to mind.

Comment 9

[Peter Trudelle]

->0.9.1

Comment 10

[Jacob Kjome]

I vote for this to get fixed ASAP.  position: fixed can't replace frames until
it has all the usability of frames which includes scrolling with keyboard/mousewheel

jake

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I don't have a mousewheel but I suspect this is related to event targeting in
the view manager.

Comment 12

[Peter Trudelle]

->moz1.1 because this is little bang for lots of bucks, could possibly still
make MachV dep. on when that ships, cc aaronl for input.

Comment 13

[Brian Ryner (not reading)]

*** Bug 68372 has been marked as a duplicate of this bug. ***

Comment 14

[Peter Trudelle]

Nav triage team needs info: Aaron- what is the impact of this bug on our section
508 compliance?

Comment 15

[Aaron Leventhal]

Not many documents are using fixed positioning yet, otherwise this would be more
important.

It's a Section 508 issue in that you cannot view all of the contents of these
documents, if you are a keyboard-only user.

Comment 16

[Peter Trudelle]

nsbeta1- per Nav triage team, ->1.2

Comment 17

[Boris Zbarsky [:bzbarsky]]

*** Bug 132258 has been marked as a duplicate of this bug. ***

Comment 18

[Arnoud Berendsen]

1.2a is long past.

Comment 19

[Robert Kaiser]

I have a real-world website where this is happening (OK, I did this website
myself). On http://jvp.kairo.at/, Whenever I get enough content into the main
content "pane" (a div with position: fixed and position: absolute), I can't
scroll with the mouse wheel (though the scroll bar works).
This is disturbing, and I heard this from a bunch of this site's users.

BTW, I've heard there are also problems with IE6/WinXP with mouse wheel
scrolling in this case. Would be another feature that puts us in front of them ;-)

Anyways, bryner, the target milestone should be changed - it still point to 1.2
alpha...

Comment 20

[Jakub Narebski]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030314
also exhibits this behavior. Mousewheel scrolling works fine with regular
frames, even without clicking (it scrolls the frame the mouse is over) and with
inline frames (the same).

Comment 21

[Robert Kaiser]

hmm, anyone who can fix this?
or anyone who can at least fix target milestone and keywords (nsbeta1- might be
outdated, it was minussed a year ago)

Comment 22

[sairuh (rarely reading bugmail)]

renominating. also affect embedded apps like camino --btw, is the 'embed' kw
used these days? i don't know if this bug would be considered a topembed issue,
though...

Comment 23

[Samir Gehani]

adt: nsbeta1-

Comment 24

[mg8]

I have another testcase: when you shrink the width of the window of
<http://perceco2.chem.upenn.edu/~glodde/test/publications.html> quite a lot,
a scrollbar appears in the position:fixed <DIV> element that acts as a menu on
the top of that page. I am not able to scroll this top menu part with the cursor
keys, even if I click into the menu with the mouse. What happens is that it's
always the bottom, "main" part of the window that scrolls.

Comment 25

[Theblueman]

also experiencing the same mouse scrolling problem with
http://unixcode.org/capistro/
I not complaining just commenting that this bug is 3 years old.  

Comment 26

[Aaron Leventhal]

Note that overflow: auto is a problem on it's own - see bug 97283

Perhaps these are both caused by the same problem?

Comment 27

[Mitja Kleider]

Attachment: extended testcase - mousewheel trick

My description is in the testcase

Comment 28

[Asa Dotzler [:asa]]

*** Bug 168332 has been marked as a duplicate of this bug. ***

Comment 29

[Aaron Leventhal]

Mats says that his fix for bug 251986 may take care of this.

Comment 30

[Aaron Leventhal]

Very weird behavior when you try to tab into the testcase, not sure when it
regressed. As you tab in, part of the content just disappears.

I can scroll the testcase now, but only if I click into the content instead of
tabbing there, because of the problem described above.

Comment 31

[Aaron Leventhal]

I can click in there and then scroll, but there are 3 problems:

1. I can't tab to focus the entire position: fixed element
2. Focus is not shown via a dotted outline on the position: fixed element
3. Tabbing to a link in there hides some of the content

Other than problem 3 the current behavior is very similar to what we have with
overflow: auto now that bug 251986 is fixed.

Comment 32

[Mats Palmgren (inactive)]

(In reply to comment #30)
> Very weird behavior when you try to tab into the testcase, not sure when it
> regressed. As you tab in, part of the content just disappears.

I have spawned off bug 254746 for this problem (it regressed before my changes)

Comment 33

[Mats Palmgren (inactive)]

(In reply to comment #31)
> 1. I can't tab to focus the entire position: fixed element
> 2. Focus is not shown via a dotted outline on the position: fixed element

I commented on this at 251986 comment 20.  A fixed pos. element is no different
from any other element with overflow:scroll IMO.

Comment 34

[Aaron Leventhal]

This appears to be fixed. I can scroll now.

Filed bug 254966 for focus/tabbing/sec508 issues.

Comment 35

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1527381