Open Bug 205846 Opened 21 years ago Updated 2 years ago

caret eventually gets stuck when trying to scroll with PageDown / PageUp keys

Categories

(Core :: DOM: Selection, defect)

x86
All
defect

Tracking

()

People

(Reporter: bugzilla, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: orca:normal)

spun off from bug 202157 comment 12. this occurs in both the browser with caret
mode ON, and in the editor --so this might be a selection bug.

this occurs under win2k and linux rh8.0. this is not a problem on mac (see bug
205845 for a separate mac issue with scrolling the web page).

1. load http://mozilla.org.
2. either turn on caret mode (F7 key) in the browser, or load this page in the
editor (control+E).
3. mouseclick the pointer near the top, eg, in the "Mozilla News" section, to
the left of "Mozilla 1.4 Beta Released..."
4. scroll down to the bottom of the page using the PageDown key.
5. scroll back up to the top using the PageUp key.
6. once again, try to scroll downwards with PageDown.

results:

* on win2k (but using shift-right arrow), the caret is stuck at the beginning of
the "Search" text.

* on linux, the caret is stuck at the end of the "Search" text.
hrm, looks like this has been a problem since (at least) september 2002. the
only variation i've seen was the builds before march 2003 (2003.03.20-ish?) take
more iterations of steps 4-6, but eventually it does fail (esp if you hold down
the key) at the same location on http://mozilla.org.
This works for me on my system. Tried with 1.4 branch and 7/2/03 trunk.
I should mention that I'm on WinXP.
> This works for me on my system. Tried with 1.4 branch and 7/2/03 trunk.
Blocks: caretnav
Verified.  I first saw this with
http://www.salon.com/tech/feature/2004/09/23/ethanol/index1.html
As you page down, you'll never reach the bottom.  You just get a weird flash.
Turning off Caret mode fixes things.

Tested with 1.0PR on Windows 2000, and Linux RedHat 7.3.
I'll add that i've been experiencing this behavior since i switched full-time to
Firefox a month or so ago. This was an upgrade from Firebird vers 1.5.20031.717,
i don't remember being in caret mode with that version. Maybe prefs changed
between versions or something?

I didn't know what 'caret mode' was before i saw this bug, am happy now that i
know how to turn it off... I may have hit F7 accidentally, but didn't see the
dialog indicating until just now when i started messing with it. You can witness
the behavior quite readily all over the place at http://www.nytimes.com
Assignee: mjudge → ginn.chen
Actually, it is caused by a very thin table cell, the height of it is above
screen's height.
e.g. in source of www.nytime.com
<td width="6"><IMG src="http://graphics8.nytimes.com/images/misc/spacer.gif"
width="6" height="900"/></td>
So if pagedown gets caret init the cell, it'll scroll back.
Caret gets stuck.

It can be reproduced with
http://www.salon.com/tech/feature/2004/09/23/ethanol/index_np.html
and nytime.com.

But I don't know what we can do on mozilla side.
*** Bug 264284 has been marked as a duplicate of this bug. ***
*** Bug 310967 has been marked as a duplicate of this bug. ***
IMO, this represents one of the worst of the problems I've seen with caret navigation in Firefox.  The impact of it is that you are just never sure quite where the caret is going to end up, and it is impossible to arrow up/down through the text.  Here's some samples of issues I see when going to http://www.mozilla.org/news.html, and I experienced them in this sequence of operations:

1) Go to http://www.mozilla.org/news.html
2) Press down arrow.  Ended up at the bottom of the page.  You should be at the top.
3) Press page up.  The page seems stuck at the bottom and page up will merely flicker the page.
4) Press arrow up.  You jump to the top of the page.  You should go up only one line..
5) If you arrow right enough, you can eventually move the caret to the "Press Releases and Announcements" section and arrow up/down in it.
6) Press page down once you're in the "Press Releases and Announcements" section.  It will jump you to the top of the page.  Press page down repeatedly once you're there.  You cannot scroll the page.

Fixing caret navigation to provide reliable and predictable arrow up/down and page up/down behavior on this page is likely to solve a number of problems.
Will, consider we have two columns, left column has only one character in it, right column has dozens of paragraphs, theses columns are displayed in several pages.
Now I place caret in the left column, what's your expect caret position after pressing page down?

If it's placed in right column, page 2, do you expect pressing page up put it back to left column?
If not, we have a bi-direction inconsistent, don't we?
> Will, consider we have two columns, left column has only one character in it,
> right column has dozens of paragraphs, theses columns are displayed in several
> pages.
> Now I place caret in the left column, what's your expect caret position after
> pressing page down?

This is a good question, and a higher level question might be "Is paging different from arrowing?"  I'm not sure of the right answer.  My gut feeling is that page up/down has more to do with moving the scroll bar and arrowing has more to do with moving the caret.  Moving the scrollbar should also move the caret into something reasonable on the new page location when you do so.  Moving the arrows should traverse the content in a linear fashion.
(In reply to comment #9)

There seem to be at least three distinct issues here:

1. (steps #1-#2) Pressing down-arrow right after loading the page takes you to the bottom of the page. This happens on any page, and turns out to be a direct result from the fact that the caret isn't positioned /anywhere/ when you first load the page. This is bug 144000.

In the mozilla.org page the main content is contained within a floated block (<div id="mainContent">). This, I'm pretty sure is what causes the other problems you're seeing:

2. (step #4): up/down arrow keys do not enter floats. So pressing up arrow in the footer takes you to the header, and vice versa. I'll file a separate bug on that.

3. (steps #3 and #6), Page up/down don't work correctly in the presence of tall floats. This is apparently the issue for which the current bug was reported (although at least one of the examples here involves a tall table cell, not a float).

I'll try to look into these three issues, as time permits me.
(In reply to comment #12)
> There seem to be at least three distinct issues here:
> 
> 1. (steps #1-#2) Pressing down-arrow right after loading the page takes you to
> the bottom of the page. This happens on any page, and turns out to be a direct
> result from the fact that the caret isn't positioned /anywhere/ when you first
> load the page. This is bug 144000.
Right, it was backed out due to regressions.
Press Ctrl+Home after loading a page can workaround it.

> 2. (step #4): up/down arrow keys do not enter floats. So pressing up arrow in
> the footer takes you to the header, and vice versa. I'll file a separate bug on
> that.
I guess left/right arrow doesn't like float either.

(In reply to comment #13)
>
> I guess left/right arrow doesn't like float either.
> 

I thought I fixed that in bug 334626. Do you still see a problem on trunk?
Blocks: orca
Whiteboard: orca:normal
QA Contact: pmac → selection
Hello,

Does anyone could explain why this bug is related to Orca? What are the side effects? I tryed to manipulate the test cases with the keyboard but I don't understand the user impact.

Regards

The bug assignee didn't login in Bugzilla in the last 7 months, so the assignee is being reset.

Assignee: ginnchen+exoracle → nobody
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.