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)
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.
Reporter | ||
Updated•20 years ago
|
Component: Composer → General
Comment 2•20 years ago
|
||
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.
Reporter | ||
Comment 3•20 years ago
|
||
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
Comment 4•20 years ago
|
||
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
Reporter | ||
Updated•20 years ago
|
Component: General → Editor
Product: Mozilla Application Suite → Core
Comment 5•20 years ago
|
||
*** Bug 303515 has been marked as a duplicate of this bug. ***
Comment 6•20 years ago
|
||
*** Bug 303967 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Flags: blocking1.8b4?
Comment 7•20 years ago
|
||
GTK1 2005072805 works, 2005072906 doesn't, but I can't spot relevant checkins.
Comment 8•20 years ago
|
||
Typo, 2005072905 (not 6) is the first GTK1 build that does not work.
OS: Windows XP → All
Comment 9•20 years ago
|
||
I'm almost positive this was caused by bug 292581.
Updated•20 years ago
|
Assignee: mozeditor → mrbkap
Updated•20 years ago
|
Flags: blocking1.8b4? → blocking1.8b4+
Comment 11•20 years ago
|
||
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 12•20 years ago
|
||
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
Assignee | ||
Comment 13•20 years ago
|
||
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
Updated•20 years ago
|
Flags: blocking1.8b5+ → blocking1.8b4+
You need to log in
before you can comment on or make changes to this bug.
Description
•