Open Bug 38114 Opened 25 years ago Updated 14 years ago

News: Should display "not allow" sign when users trying to copy the message from Mail to News/Newsgroup

Categories

(SeaMonkey :: MailNews: Message Display, enhancement)

Product:
SeaMonkey
Component:
MailNews: Message Display
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

People

(Reporter: huang, Unassigned)

Details

(Whiteboard: see comment 14 why this is still open) 

Used 05-03-09-M16 commercial build:

News: Should display "not allow" sign when users trying to copy the message 
from Mail to News/Newsgroup

(We should display "not allow" sign (same as 4.7)instead of nothing happened 
when users trying to copy the messages from Mail to News/Newsgroup)

1) Login to a Mail Account.
2) Select subscribed newsgroup
3) Tried to copy Inbox messages to the subscribed newsgroup.
4) Actual Results: Nothing happened and didn't display "not allow" sign when 
users trying to copy the message from Mail to News/Newsgroup since it not 
allowed to copy mail to newsgroup.

Expected results: Should display "not allow" sign (same as 4.7), so users will 
know it is not allowed.
reassigning to sspitzer.  Shouldn't we just not allow the ability to copy to a 
newsgroup?  I thought we were doing that.

HOw did you try to do the copy?
Assignee: putterman → sspitzer
To clarify:  I take it you mean copy via Drag & Drop.
All platforms
OS: Windows NT → All
QA Contact: lchiang → esther
Hardware: PC → All
4.x treats a drag&drop to an invalid place differently among platforms:
Win32 changes cursor to circle with slash
Linux displays a status bar text "Cannot drop into the targeted destination
folder" upon the drop
Mac does a "snap back" to origination folder 

We probably need to figure out a common treatment here for all platforms for
invalid drop locations.
Yes, I agree.  Unless that is the platform way for doing drag and drop.  In this 
case I would think we would prevent the drop on a newsgroup. cc'ing chuang.
I was trying to update the comments this afternoon... but it seemed that the 
bugzilla had problem at that time....Laurel is right, I was using drag & drop 
for copying the messages.
FYI: M. Pinkerton said we won't make a consistent invalid drop cursor across
platforms, each platform will be independent like it was in 4.x.
moving to m18.
Target Milestone: --- → M18
Couldn't we enable this behavior to open the message as new addressed to the 
newsgroup? However this is done it's an enhancement and I expect this bug will 
be futured
Severity: normal → enhancement
Keywords: 4xp, ui
Seth is in sabbatical.
Ccing putterman to decide whether this will be future or not?
reassigning to chuang. I'm pretty sure Candice had a patch for this.
Assignee: sspitzer → chuang
Taking bug.
QA Contact: esther → stephend
Target Milestone: M18 → ---
reassigning to racham
Assignee: chuang → racham
This was fixed. User is not allowed to copy mail to a newsgroup, via any mode
(D&D or copy via menus etc).
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Since the original bug was for us displaying the 'no target/not allowed' sign
and it addresses all platforms, this is truly only occuring currently as filed
on Windows platforms.  My standard OS 9.1 trunk and RedHat 7.2 with GNOME/GTK
trunk builds give absolutely no feedback when over the drop target. 
Linux: doesn't highlight the newsgroup, but the cursor doesn't change.  Upon
release, the message's trail goes back to the origination.
Macintosh: highlights the newsgroup _and_ server, as if it was a normal drop
target.  Upon release, the message's trail goes back to the origination.

If this bug's summary was 'shouldn't be allowed to copy to newsgroup from
IMAP/POP3', then the resolution as it stands is fine.

However, since this bug addresses the drop target feedback, I'm re-opening until
I hear what our stand is on feedback for the different OS drag and drop services.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
mass re-assign.
Assignee: racham → sspitzer
Status: REOPENED → NEW
Product: Browser → Seamonkey
Assignee: sspitzer → mail
Assignee: mail → nobody
Priority: P3 → --
QA Contact: stephend → message-display
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
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
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
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
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
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
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
MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago → 15 years ago
Resolution: --- → EXPIRED
Still an issue on Linux at least.
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: EXPIRED → ---
Whiteboard: see comment 14 why this is still open
Status: REOPENED → NEW
You need to log in before you can comment on or make changes to this bug.