Closed Bug 302804 Opened 20 years ago Closed 20 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: 20 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: