click-hold in headers pane shouldn't immediately put message in message pane

NEW
Unassigned

Status

SeaMonkey
MailNews: Message Display
16 years ago
8 years ago

People

(Reporter: xolaware.llc, Unassigned)

Tracking

Trunk
All
Mac OS X

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

16 years ago
From Bugzilla Helper:
User-Agent: Mozilla/4.79 (Macintosh; U; PPC)
BuildID:    2002041603

click-hold (or mousebutton-down) on a line in the headers pane should not trigger 
the event that causes the corresponding message to appear in the message pane.  
it should allow time for the context-menu to pop-forward, and thus allow deletion 
of a message without opening it.  i.e. the message should really not appear until 
a mousebutton-up event with the context-menu not having been opened.

this feature is good for deleting messages that the user determines are spam 
simply from the headers, allowing it to be thrown away without opening it.  
(ns4.79 allows this.)  also good for moving unread msgs to other folders and 
leaving them unread.

Reproducible: Always
Steps to Reproduce:
1. open "Mail & Newsgroups" (cmd-2)
2. click on an unread message and hold waiting for the contextual menu


Actual Results:  message is brought up in the message pane and marked read

Expected Results:  contextual menu should appear without a message, allowing 
operations on the message without reading it in the message pane.

Comment 1

16 years ago
*** Bug 154817 has been marked as a duplicate of this bug. ***

Comment 2

15 years ago
Confirmed using Mac/2002072203. Click+hold selects the header, displays the contextual menu, and 
loads the message body, while control+click only selects the header and displays the contextual menu; 
message body is not displayed.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 3

14 years ago
This bug is targeted at a Mac classic platform/OS, which is no longer supported
by mozilla.org. Please re-target it to another platform/OS if this bug applies
there as well or resolve this bug.

I will resolve this bug as WONTFIX in four weeks if no action has been taken.
To filter this and similar messages out, please filter for "mac_cla_reorg".
(Reporter)

Comment 4

14 years ago
still a bug in macos X

workaround is 'right-button' click to get the context menu ... if you have a
multiple button mouse.  no workaround for shipped one-button macOS mouses (mice?).
OS: Mac System 9.x → MacOS X
Product: Browser → Seamonkey

Updated

13 years ago
Assignee: sspitzer → mail
Assignee: mail → nobody
QA Contact: olgam → message-display

Comment 5

9 years ago
MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
(Reporter)

Comment 6

9 years ago
i can reproduce this problem with thunderbird version 2.0.0.21 (20090302).

the reproducible steps are only a tiny bit different:
1) Open "Mail & NewsGroups" Cmd-1
2) click-drag a message

i think this is buggy behavior.  i think it's worth implementing, because i think it's worth being able to click-hold move a message without loading it to another folder so that it remains in unread state or so that if it is suspected spam, it can be moved without loading javascript.  i think it would be easy to implement by having the load behavior dependent un the "buttonUp" event as opposed to on the "buttonDown" event, as appears to be the case now.

i would like to set this back to NEW as requested in Comment #5 from Robert Kaiser, but my only choices are leaving it "UNCOFNIRMED" or marking "RESOLVED".  Perhaps your "mass-UNCONFIRM-20090614" needs to take into account that some reporters do not have the privileges to mark items as anything other than "UNCONFIRMED" or "RESOLVED"

Comment 7

8 years ago
still see this on Mac?
right-click on windows is fine
Ever confirmed: false
(Reporter)

Comment 8

8 years ago
i haven't been getting nightly lately ...

but in version 2.0.0.22 (20090605), i still see this behavior ...

... and it still bugs the **** out of me.

Comment 9

8 years ago
(In reply to comment #7)
> still see this on Mac?
yep

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1pre) Gecko/20090718 SeaMonkey/2.0b1  on  MacBook Pro, OS X 10.5.8

> right-click on windows is fine
Seems to be here too.  

Setting to NEW and changing platform to ALL.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Hardware: PowerPC → All
You need to log in before you can comment on or make changes to this bug.