Closed Bug 302804 Opened 19 years ago Closed 19 years ago

'Page up/down' keys do not work properly in MailNews Composer window

Categories

(Core :: DOM: Editor, defect)

x86
All
defect
Not set
major

Tracking

()

VERIFIED FIXED

People

(Reporter: thomas.ts.schade, Assigned: mrbkap)

References

Details

(Keywords: access, regression)

Attachments

(1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050729 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050730 SeaMonkey/1.0a

When editing (replying to) a mail which is longer than one window screen the
<page up/down> keys on the keyboard start a strange behaviour:
- on first monitor screen everything works fine:
  <page up> does not work at all (expected)
  <page down> scrolls down one screen page (expected)
- starting from the second monitor screen it's getting weired:
  <page down> increases scrolling with every hit, 1 page, 2 pages, 4 pages etc.
  <page up> behaves same like page down, scrolling down(!) and incresing accordingly
- also the scroll keys <arrow up/down> do not work as expected from second
monitor screen onwards. They also increase scrolling by two with every hit. 

Reproducible: Always

Steps to Reproduce:
1. Open a mail longer than one screen page in the editor (compose) window (plain
text)
2. Scroll down to screen page 2 (<page down> or <arrow down>)
3. Hit <page up>

Actual Results:  
Hitting <page up> actually scrolls down(!), scroll 'speed' increasing with every
hit.
Hitting <page down> actually scrolls down, scroll 'speed' increasing with every hit.

Expected Results:  
<page up> should result in scrolling upwards (towards begin of the text).
<page down> should result in scrolling down (towards end of the text) only by
one screen page with every hit.

In de.comm.software.mozilla.nightly-builds also reported for: 
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050730 SeaMonkey/1.0a
WFM with SeaMonkey/20050727, the Page Up/Down and arrow keys work as expected
when I compose a very long message.
Component: Composer → General
I can see this bug on my self-compiled Linux builds since 2005072902. The build
before this one, 2005072816, was without this bug.

Note that my Build-ID shows the time in CEST.
Same behaviour can also be noticed with actual Thunderbird trunk build:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050803
Thunderbird/1.0+ Mnenhy/0.7.2.10005
Version: unspecified → Trunk
I can confirm this wrong behaviour mostly using: 
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b4) Gecko/20050803
SeaMonkey/1.0a Mnenhy/0.7.2.10005 {Build ID: 2005080320}

But in difference to the reporter, at the second screen page/monitor screen the
"page up" Button will work well, curor and screen page will go up.

Starting with the third page/monitor screen, the wrong behaviour occours, "page
up" will move the Cursor and screen page down. 

"Page down" and scrolling with the arrow-keys works fine. 

Status: UNCONFIRMED → NEW
Ever confirmed: true
Component: General → Editor
Product: Mozilla Application Suite → Core
*** Bug 303515 has been marked as a duplicate of this bug. ***
Assignee: composer → mozeditor
*** Bug 303967 has been marked as a duplicate of this bug. ***
GTK1 2005072805 works, 2005072906 doesn't, but I can't spot relevant checkins.
Typo, 2005072905 (not 6) is the first GTK1 build that does not work.
OS: Windows XP → All
I'm almost positive this was caused by bug 292581.
This also affects caret browsing.
Keywords: access, regression
Assignee: mozeditor → mrbkap
Flags: blocking1.8b4? → blocking1.8b4+
Attached patch Patch v1 (obsolete) — Splinter Review
Simple fix: the scroll code was passing in the wrong coordinates.

Backing out Bug 292581 is also a possibility, but I don't think it's necessary.
Comment on attachment 192159 [details] [diff] [review]
Patch v1

Never mind.  I've realized that the patch for Bug 292581 was wrong.  I'll get
it backed out.
Attachment #192159 - Attachment is obsolete: true
Gavin backed out the offending patch, marking this as FIXED.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Verified FIXED using build 2005-08-10-05 on Windows XP SeaMonkey trunk.
Status: RESOLVED → VERIFIED
Flags: blocking1.8b5+ → blocking1.8b4+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: