Closed
Bug 99193
Opened 25 years ago
Closed 12 years ago
In a thread, press Enter on the parent message and multiple actions occur
Categories
(MailNews Core :: Backend, defect)
MailNews Core
Backend
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: nbaca, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(2 files)
|
514 bytes,
patch
|
Details | Diff | Splinter Review | |
|
1.23 KB,
patch
|
Details | Diff | Splinter Review |
Branch build 2001-09-10-03: WinMe
I found this bug while investigating bug# 89702.
Overview: In threaded mode, single click onto a parent message, then press the
Enter key.
Actual Results:
a.If the thread is collapsed then pressing the Enter key
- expands the thread
- opens the selected message in a stand alone window
b. If the thread is collapsed then pressing the Enter key
- collapses the thread
- opens the selected message in a stand alone window
c. If a child message is selected then the state of the thread remains (it
either remains collapsed or remains expanded) and the message appears in a stand
alone window.
Expected Results: In 4.7 pressing the Enter key only opens the message in a
stand alone window, which appears reasonable.
Additional Information:
- Double clicking onto the parent message just opens it in a stand alone window.
| Reporter | ||
Comment 1•25 years ago
|
||
Marking "nsbranch" based on kmurray's comments in bug# 89702.
Keywords: nsbranch
QA Contact: esther → olgam
Comment 2•25 years ago
|
||
I'm assuming 6.1 had the same behavior? We haven't even started to look into
this yet so I'd assert that I wouldn't hold the release for this. however, I
hate to minus kmurray bugs =). So I'll let him over ride me if he really feels
this is important =).
Comment 3•25 years ago
|
||
The reason this bug was filed is because we only half fixed bug 89702 (double
click on a top level thread works fine, but using Enter to open a standalone
message at top level still toggles open state). I wouldn't hold a release for
this either, but we should fix this (89702) in 0.9.5.
Comment 4•25 years ago
|
||
moving to 0.9.7 and reassigning to ssu.
Updated•25 years ago
|
It looks like the fix is to prevent the key event to be picked up by the default
handler in outliner.xml. The threadPane.js patch should do the trick, but it
doesn't seem to be working.
Another fix could be to patch outliner.xml to remove the default handlers in
question. If this is done, I've noticed that it prevents the thread from
expanding/collapsing when simply hitting 'enter' on a selected message in the
thread pane.
It also has the same effect on the folder pane in that if 'enter' is pressed,
the folder (that contains subfolders) will not expand or collapse. This is
consistent behavior with 4.x.
However, I don't know what the side effects of patching outliner.xml are.
I'll need to talk to hyatt about this.
Status: NEW → ASSIGNED
Comment 8•24 years ago
|
||
event.stopPropagation() is what you want I think.
event.stopPropagation() does not fix this problem, but I did notice that if
place this call as follows (just as a test case):
function ThreadPaneKeyPress(event)
{
event.preventBubble();
if (event.keyCode == 13)
{
ThreadPaneDoubleClick();
}
}
it does prevent the the Crtl-Q event from being processed. Which leads me to
believe that the key event (wrt to toggling threads) is being processed either
in parallel or has been caught before entering ThreadPaneKeyPress().
Updated•24 years ago
|
Priority: -- → P2
Updated•24 years ago
|
Target Milestone: mozilla0.9.7 → mozilla0.9.8
Updated•24 years ago
|
Target Milestone: mozilla0.9.9 → mozilla1.2
Comment 10•24 years ago
|
||
Discussed in 2/25 bug mtg w Mktng, PjM and Engineering. Decision was to move to
1.2 and nsbeta minus this bug.
Comment 11•24 years ago
|
||
*** Bug 135484 has been marked as a duplicate of this bug. ***
Comment 12•24 years ago
|
||
*** Bug 131086 has been marked as a duplicate of this bug. ***
Comment 14•24 years ago
|
||
Now I add 'nsbeta1' keyword for Buffy. Sorry, it's faster to edit multiple bugs
at once than manually go to each and remove minus.
Keywords: nsbeta1
Comment 16•23 years ago
|
||
It is a strange thing that this (unsolved) bug bloks a (solved) bug such as
bug 99230 0=)
Comment 17•22 years ago
|
||
*** Bug 230942 has been marked as a duplicate of this bug. ***
Comment 18•22 years ago
|
||
This bug still exists in TBird 0.7, and seems to be languishing.
Any hope of getting this fixed by Aviary 1.0/SM 1.8?
Flags: blocking1.8a3?
Flags: blocking-aviary1.0RC1?
Updated•22 years ago
|
Flags: blocking1.8a3? → blocking1.8a3-
Comment 19•22 years ago
|
||
out of time for this on the aviary 1.0 change list that we are trying to crank
down on.. reassigning to default owner to get consideration for future releases
Assignee: ssu0262 → sspitzer
Status: ASSIGNED → NEW
Flags: blocking1.8a4?
Flags: blocking-aviary1.0PR?
Flags: blocking-aviary1.0PR-
QA Contact: olgam
Updated•22 years ago
|
Flags: blocking1.8a4?
Flags: blocking1.8a4-
Flags: blocking1.8a3-
Updated•21 years ago
|
Product: Browser → Seamonkey
Updated•21 years ago
|
Assignee: sspitzer → mail
Comment 20•21 years ago
|
||
Still present in "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12)
Gecko/20050915" and "Thunderbird version 1.5 Beta 2 (20051006)"
Updated•19 years ago
|
OS: Windows ME → All
Hardware: PC → All
Updated•18 years ago
|
Assignee: mail → nobody
Component: MailNews: Main Mail Window → MailNews: Backend
Priority: P2 → --
Product: Mozilla Application Suite → Core
QA Contact: backend
Target Milestone: mozilla1.2alpha → ---
| Assignee | ||
Updated•18 years ago
|
Product: Core → MailNews Core
Comment 25•12 years ago
|
||
WFM. current nightly
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•