Visible scrollbar won't scroll vertically with keyboard

NEW
Assigned to

Status

()

--
enhancement
14 years ago
7 years ago

People

(Reporter: psychonaut, Assigned: mats)

Tracking

({testcase})

Trunk
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

14 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041220
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041220

The web page <http://www.seasip.info/VintagePC/cga.html> displays normally, but
I cannot scroll using any of the following:

1. Up arrow
2. Down arrow
3. Home key
4. End key
5. Mouse scroll wheel

The following does work, however:

1. Clicking on the scroll bar
2. Find text as you type
3. Ctrl+F
4. Ctrl+G after #2 or #3

I'm not sure what's causing this.

Reproducible: Always

Steps to Reproduce:
(Reporter)

Comment 1

14 years ago
After further testing, it seems the window can be scrolled, but only when there
is an active link.  For example, one must first middle-click on a hyperlink to
open in it in a new tab.  The page can now be scrolled as long as the link is
active.  If one clicks anywhere else on the page to deactivate the link, the
page returns to its non-scrollable state.
(Assignee)

Comment 2

14 years ago
Mouse-wheel scrolling has been fixed in newer builds (bug 97283).

Keyboard scrolling does not work because there is no overflow of the root
element to scroll to (the page consists of two fixed pos. DIVs).
(focus the one with the scrollbar and keyboard scrolling works fine).

As an enhancement, maybe we could look for a fixed pos. frame that is
scrollable for the keyboard case? (when nothing is focused)
Assignee: general → jag
Severity: normal → enhancement
Component: General → XP Toolkit/Widgets
OS: Linux → All
Product: Mozilla Application Suite → Core
QA Contact: general → jrgmorrison
Hardware: PC → All
Summary: Page won't scroll vertically, either with keyboard or mouse scroll wheel → Visible scrollbar won't scroll vertically with keyboard
Version: unspecified → Trunk
(Assignee)

Comment 3

14 years ago
Created attachment 176418 [details]
Testcase #1
(Assignee)

Comment 4

14 years ago
Having a look at this...
Assignee: jag → mats.palmgren
Keywords: testcase
(Assignee)

Comment 5

14 years ago
Created attachment 176423 [details]
Testcase #2
Attachment #176418 - Attachment is obsolete: true
(Assignee)

Comment 6

14 years ago
Created attachment 176424 [details] [diff] [review]
Patch rev. 1
Attachment #176424 - Flags: superreview?(bzbarsky)
Attachment #176424 - Flags: review?(aaronleventhal)

Comment 7

14 years ago
Comment on attachment 176424 [details] [diff] [review]
Patch rev. 1

+  return ((aDirection == nsLayoutUtils::eHorizontal ||
+	    aDirection == nsLayoutUtils::eEither) &&
+	   portRect.width < scrolledSize.width) ||
+	  ((aDirection == nsLayoutUtils::eVertical ||
+	    aDirection == nsLayoutUtils::eEither) && 
+	   portRect.height < scrolledSize.height);

How about a slight simplification like:
+  return (aDirection != nsLayoutUtils::eVertical &&
+	   portRect.width < scrolledSize.width) ||
+	  (aDirection != nsLayoutUtils::eHorizontal && 
+	   portRect.height < scrolledSize.height);

Also, what if there is nothing with position: fixed, but there is something
with overflow:scroll or overflow:auto
Should we be able to scroll those children if the main doc has no scrollbars?

Anyway, r=aaronlev
Nice improvment.
Attachment #176424 - Flags: review?(aaronleventhal) → review+
(Assignee)

Comment 8

14 years ago
(In reply to comment #7)

> Also, what if there is nothing with position: fixed, but there is something
> with overflow:scroll or overflow:auto

I guess the intention here is to catch "frame like" designs where one of the
positioned elements is used instead of the viewport to scroll the main
portion of the content (like the URL).
I don't think we should look at normal flow.
Maybe we should look in the root 'absoluteList' also though...
> I guess the intention here is to catch "frame like" designs 

Those can use a non-positioned div with overflow set for the main content,
though.  For example, see http://web.mit.edu/bzbarsky/www/index.shtml (and
change overflow on the ContentHolder to "auto" while setting a fixed height for it).

I'm really not sure what the right behavior here is...  Note that for a "framed"
design we would need a click in (or tab to) the frame to scroll it.  That
already works, doesn't it?

Comment 10

14 years ago
Can confirmed this bug on my machine and patch is already ready to go...

Status --> New
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 11

14 years ago
>>patch is already ready to go...
Mistyped the word "already" for "almost"...  Sorry about that...
Again, I'm still not quite sure why this patch is what we want...
Comment on attachment 176424 [details] [diff] [review]
Patch rev. 1

I'm not convinced this is right.
Attachment #176424 - Flags: superreview?(bzbarsky) → superreview-

Updated

8 years ago
QA Contact: jrgmorrison → xptoolkit.widgets
(Reporter)

Comment 14

8 years ago
This bug seems to be fixed.  Scrolling works fine with the original page I reported, as long as with the test case.

I'm using Mozilla/5.0 (X11; U; Linux x86_64; en-GB; rv:1.9.1.16) Gecko/20101124 SUSE/2.0.11-2.2 SeaMonkey/2.0.11.

Is it OK to close this as FIXED?
(Assignee)

Comment 15

8 years ago
(In reply to comment #14)
> This bug seems to be fixed.  Scrolling works fine with the original page I
> reported,

I suspect that the URL has changed since the "main" div is now position:relative
and that's why keyboard scrolling now works there.

> as long as with the test case.

The testcase still shows the reported problem.

Fwiw, I still think my suggested fix makes sense:  when there is no element
focused and the viewport is unscrollable, then look for a position:fixed
element that is scrollable and scroll that.

It would make keyboard scrolling work for "frame-like presentations" using
position:fixed envisioned in CSS2:
http://www.w3.org/TR/CSS2/visuren.html#fixed-positioning

Comment 16

7 years ago
Bug 682763 relates to this bugs: if the "div frame" has @tabindex set, then it becomes impossible to use the SPACE key to scroll the "div frame". Even clicking inside the "div frame" doesn't work then.

@Mats: 

I may not understand your fix correct, but after fiddling with bug 6827763, I have the following questions/issues regarding your fix:

* HTML5: http://dev.w3.org/html5/spec/editing#focus
* HTML5 specifies that it is only when an element has focus that it should answer to key events. It also says that no element might be focused and that, in that case, the "root" element must be the target for keyevents.
* Note as well that HTML5 says that elements that have focus answer to *:focus{}. So, I don't think your fix is correct unless it also causes the element to answer to *:focus{}
You need to log in before you can comment on or make changes to this bug.