Closed Bug 57510 Opened 24 years ago Closed 18 years ago

`Del' key does not delete the message

Categories

(SeaMonkey :: MailNews: Message Display, defect, P3)

PowerPC
macOS
defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: mpt, Assigned: mnyromyr)

References

Details

Attachments

(2 files, 2 obsolete files)

Build: 2000102008, Mac OS 9.0

To reproduce:
* Select an e-mail message.
* Press the Delete key.

What should happen:
* The message is deleted.

What actually happens:
* Nothing.

Backspace (labelled as `delete' on Mac keyboards) currently works to delete a
message, but Delete (labelled as `del' on Mac keyboards) does not. The only
occasion when the Backspace and Delete keys should ever do different things is
when editing text; this isn't editing text, so the Backspace and Delete keys
should do exactly the same thing.
Keywords: 4xp
QA Contact: esther → sheelar
Matthew,
Do you still see this problem on recent builds?  Can you download the new builds
and try again.  I have build from 2000122606 on my mac and deleted a message
using the delete key and was able to delete the message.
qawanted -- I will be unable to run Mozilla for the forseeable future, so someone 
else will have to check this.
Keywords: qawanted
changing resolution to worksforme.  Verified on today's build on mac 8.6 and mac
9.0. buildid:2001-01-16-08.  Reopen if seen again
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
Status: RESOLVED → VERIFIED
verifying worksforme
Reproduced on build 2001011912, Mac OS 9.0. Reopening.

If it helps, the keyboard is an AppleDesign keyboard, model no. M2980.
Status: VERIFIED → REOPENED
Keywords: qawanted
OS: Mac System 8.5 → Mac System 9.x
Resolution: WORKSFORME → ---
I do have a different key board and Model number is M2452 and I see that delete
key still works for me.  (buildid-2001-01-22-08 - on Mac)
Reproduced on build 2001033004, Mac OS 9.1, with a bog-standard iMac Pro keyboard 
(model no. M7803). Backspace (`delete') deletes the message, but Delete (`del') does 
not.

The reason this is annoying is that the Delete key is closer to the arrow keys than the 
Backspace key is, so I prefer using Delete rather than Backspace.
adding self to cc: list

!wfm

macos 9.1, build 2001060508, iBook using fn-Delete (which is mapped to Del at the 
underlying (os?) level).
Matthew, this works for me. Is this still a problem for you?
Reproduced in build 2001062905, Mac OS 9.1.
note, my mac keyboard (iMac) doesn't have backspace.

but on windows, I have a backspace and like mpt's, it doesn't do a delete.

note, if I'm already in the 3 pane, 4.x backspace take me to the netscape 
message center and it selects the folder the message came frome.  

if I'm in a stand alone msg window, 4.x backspaces opens the 3 pane and selects 
the message in the right folder.

mpt, what happens on your mac when you hit backspace in 4.x?  (I'm hoping you 
get the message center too.)
Nope, in 4.x both Backspace and Delete delete the message. Which is as it should
be (see the last paragraph of the original bug report).

Just so we're absolutely clear:

                            This button worked in 4.x,
                            and still works now. (Good.)
      ____  ____  _________/      ____  ____  ____
     | __ || +  ||          |    |    ||    ||page|
     |_-__||_=__||delete____|    |help||home||up__|
      _  _ __  ____  _______      ____  ____  ____
       || {  || }  || |     |    |del ||    ||page|
       ||_[__||_]__||_\_____|    |X>__||end_||down|
                                /
              This button worked in 4.x,
              but doesn't work now. (Bad.)
4xp [w32], I expect backspace on windows to get me to the message folder (and 
if we had a message center i'd expect to get from message folder to there).

So this is really an event handling thing, no? [tread carefully, don't break 
the w32 behavior]

mpt: do delete and delete right behave correctly in input boxes?
This bug is not about the Backspace key. Backspace works fine.

And yes, the two delete keys do behave properly (modulo non-event-handling 
bugs, e.g. caret bugs) in text fields.
it sounds like on certain macs, we have two delete keys.

delete and del.  

del isn't working.  is that right?
note, on my imac keyboard, that's a "num lock / clear", and in 4.x it doesn't do
a delete.

I'll have to find a machine with a "Del X>" key.  hangas / ducarroz, does your
have that?
This happens to me also. Windows 2000 Pro (en) MSDN version SP2 applied + 
IE5.0, build 2001073103, Portuguese keyboard and regional settings with 
microsoft internet keyboard without any special driver/software for it 
installed (using standard 101/102-key or Microsoft Natural PS/2 Keyboard).
In my computer, the first time it works and deletes the message(s). The next 
time i try, it won't work neither for one message nor for a group of messages. 
(delete key used on top of the arrow keys, not the backspace key or the del key 
in numeric keyboard)...
Have the same bug here. Win2k. Build: 2001081108.
Note: worked properly in build 2001080110

To answer Seth: The new standard Mac extended keyboard that ships with all new
Macs has this key. This is the keyboard with the CD eject button in the top
right hand corner of the numeric keypad. Just to confirm it doesn't delete a
message when hit.
*** Bug 120749 has been marked as a duplicate of this bug. ***
reassigning to ssu.
Assignee: putterman → ssu
Status: REOPENED → NEW
reporter,
Is this still a problem in the recent builds?
i'm not the original reporter, but this is still a problem for me.
Not corrected for build 2002072103
*** Bug 134669 has been marked as a duplicate of this bug. ***
QA Contact: sheelar → stephend
problem still exists in Mozilla 1.2.1.
Problem also in W2K 1.3b (Build ID: 2003021008).  This works in Mozilla 1.1, but
not since then (I've also tried 1.2b and 1.2.1).
I Can delete first message, but second, thrirty,... not.
Very, very estrange.
When I select for messages for the first delete is OK, but next delete will be fail.
I have mozilla Mozilla 1.3b 
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210
Thanks a lot
happens on all operating systems (confirmed for mac classic and windows)
OS: Mac System 9.x → All
Hardware: Macintosh → All
fwiw, this is also a bug in thunderbird on macos x (10.2.8) in build 0.4a (20031111).  it has been a 
bug here for some time as well.  and to confirm, this is the 'del' key, sometimes also called the 
'forward delete' key.
*** Bug 240958 has been marked as a duplicate of this bug. ***
(In reply to comment #28)
> happens on all operating systems (confirmed for mac classic and windows)

Simon Paquet, can this possibly be true?  The initial report is strictly Mac 
because only Mac has Del and Delete keys; the other reports are overwhelmingly 
for Mac systems (and see bug 242864); I've never seen this on Windows.

The one Windows "won't delete" bug that I have seen is a state problem,
bug 122854.
Product: Browser → Seamonkey
I think the problem is more fundamental and that is that both Thunderbird and
Firefox completely ignore keyboard mapping from OSX. The mappings on OSX are
flexible and can be redefined entirely. This is very flexible and makes it
possible to make keys like home and end on extended usb keyboards behave like on
Windows. Both FF and Th ignore these mappings and stick to defaults. Which is
wrong. If implemented well, then the system event for the delete key should work
with any keyboard. Even if I set F11 to have the Delete behavior.
It is extremely annoying not to move the cursor using home/end keys in the way
I've set OSX to behave.
Perhaps, but implementing that would be much harder than just fixing this bug.
Thunderbird 1.0.6 on MacOS X (10.4.2 Tiger) doesn't delete messages when the
message is selected and the Delete key is pressed.  Not sure if related to this
bug, but it seems very annoying.
WFM Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050917
SeaMonkey/1.1a

so (mac users), if this still fails on MAC should this be changed back to MAC
only?  (and if id doesn't, then closed WFM)
Assignee: ssu0262 → mail
QA Contact: stephend
(In reply to comment #35)

should be left open for mac ... or at least for mac os x.  (using thunderbird
version 1.6a1 (20050913)).
Is there more information that's needed here? Like the keycode sent on delete or something? This bug has been open for 4 years! I will bake cookies for the person who fixes this... It makes me crazy that delete does not delete messages, instead I have to use backspace (which apple lables delete for some wacky reason). Makes no sense... And thunderbird 1.5 RC2 on OSX still does this. 
Resetting to a Mac-only bug, as discussed comment 28, 31, 35, 36.
OS: All → MacOS X
Hardware: All → Macintosh
Did _anyone_ at least look into the code lately? I guess not.
Since 2001-12-03, when Ben fixed bug 104485, the key definition is this:

<http://lxr.mozilla.org/mozilla/source/xpfe/communicator/resources/content/mac/platformCommunicatorOverlay.xul>:
 37   <!-- Delete Key -->
 38   <key id="key_delete" keycode="VK_BACK"     command="cmd_delete"/>

That's why "Backspace-Delete" works and "Del-Delete" doesn't.

(This actual key definition came into code here in 2000: <http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=mozilla%2Fxpfe%2Fglobal%2Fresources%2Fcontent%2Fmac%2F&file=platformGlobalOverlay.xul&filetype=regexp&who=hangas&whotype=regexp&sortby=Date&hours=2&date=explicit&mindate=2000-01-01&maxdate=2001-01-01&cvsroot=%2Fcvsroot>.)

So, the questions are:
1. Do we want to keep VK_BACK as the "primary delete key" on Mac or do we want to switch this to VK_DELETE (and thus be consistent over most platforms)?
2. Regardless of (1), we need to define the other key as a "secondary delete key" on Mac and use it in MailNews/History/Bookmarks/Download Manager/whereever.

I'd prefer making VK_DELETE the primary/only delete key on Mac/Unix/Win, thus moving it out of the platformCommunicatorOverlay files, and providing a secondary delete key VK_BACK for Mac only, incl. repective code for MailNews/History/Bookmarks/Download Manager/whatever.

Does this sound reasonable to longtime Mac users? ;-)
Sounds OK to me (as long as both keys work on mac I'm happy). As a side-note: In BM both keys work on all platforms, see bug 26543.
Thank you, Karsten. Unfortunately, iBooks and PowerBooks don't *have* a Del key. So while VK_DELETE is (starting from the arrow keys) much easier to reach on Mac desktops, VK_BACK is much easier to type on Mac laptops.
I'd have to agree, to be consistent with other OS X applications I think both need to be used as a delete key. Most OS X apps regard both the backspace and delete as the same thing for everything except text editing, so to be consistent with the platform this would be best.
Re comment #41:
> iBooks and PowerBooks don't *have* a Del key.

I know, I checked with my PowerBook before writing comment 39. ;-)
VK_DELETE = Fn + VK_BACK (See also the keyboard test page in attachment 55849 [details].)

> So while VK_DELETE is (starting from the arrow keys) much easier to reach
> on Mac desktops, VK_BACK is much easier to type on Mac laptops.

That's why I two <key>s are required here - the distinction between primary and secondary is only needed, because we can't assign the same XUL id to two <key>s...

Taking.
Assignee: mail → mnyromyr
This patch does the following:
*  implement a global "secondary delete key" key_delete2 next to the primary one "key_delete", which is, too, tied to a real key in a platform-aware way
*  let VK_DELETE be the primary key on Win and Unix and secondary be empty there
*  on Mac, use VK_BACK as primary and VK_DELETE as secondary key
*  add the key_delete2 everywhere where we use key_delete
*  make bookmark manager behave again: we don't want anyone to redefine global keys! (I really doubt that this was necessary, but I only touched the bookmark code as far as needed for it using the global keys.)
*  make the bookmark sidebar panel use the bookmark manager keys where possible
*  correct inconsistent id of <key id=cmd_shiftDelete> to key_shiftDelete and implement key_shiftDelete and key_shiftDelete2 along key_delete and key_delete2

Places I verified on Win and Mac that they do work as intended (two delete keys for Mac, one for Win):
- textboxes/textareas
- bookmark manager, bookmark sidebar panel
- history manager, history sidebar panel
- download manager
- addressbook.xul
- message editor incl. attachment pane
- mail window (wrt message deletion, folder deletion), both with and without shift key
- mail search dialog, both with and without shift key

Addressbook search doesn't currently allow deletion; in fact, almost all other keys are missing there, too, so I left that out here.
Attachment #207323 - Flags: superreview?(jag)
Attachment #207323 - Flags: review?(db48x)
Comment on attachment 207323 [details] [diff] [review]
Mac-aware key_delete2 implementation, v1


>+  if (key.getAttribute("command"))
>+    key.setAttribute("command", "cmd_remove");
>+  key = document.getElementById("key_delete2");
>+  if (key.getAttribute("command"))
>+    key.setAttribute("command", "cmd_remove");

Use |if (key.hasAttribute("command"))| instead, unless there really are keys with their command attribute set to an empty string. Same thing elsewhere as well.

Everything else looks ok, but since the patch was more involved than I expected (not a bad thing), I'll test before I r+ it.
I am having the same annoying issue on OS X 10.4.4/Thunderbird 1.5 with Microsoft Wireless Keyboard. Backspace works Del does not. I'd like to be able to use Delete key again. 

thanks
Comment on attachment 207323 [details] [diff] [review]
Mac-aware key_delete2 implementation, v1

looks good, didn't break anything that I noticed, and it worked with my keyboard at any rate :)
Attachment #207323 - Flags: review?(db48x) → review+
bookmarksOverlay.xul should have all the keys in a new keyset to avoid having bookmarksManager.xul and bm-panel.xul duplicate them.

For download manager, I can't see why it uses cmd_remove instead of cmd_delete.
Comment on attachment 207323 [details] [diff] [review]
Mac-aware key_delete2 implementation, v1

Please attach a new patch implementing Neil's suggestion.
Attachment #207323 - Flags: superreview?(jag) → superreview-
Attached patch factor out bookmark keys, v2 (obsolete) — Splinter Review
Factoring out the bookmark keys, but leaving download manager stuff as is - rearranging the download manager is really out of scope here.
Attachment #207323 - Attachment is obsolete: true
Attachment #221238 - Flags: superreview?
Attachment #221238 - Flags: review+
Attachment #221238 - Flags: superreview? → superreview?(jag)
Hmmm... I'm a bit puzzled by that <stringbundleset/> in bookmarksOverlay.xul. It currently overlays into bm-panel.xul, bookmarksManager.xul (removed in your patch) and navigator.xul. I couldn't find any evidence of bookmarksManager.xul using either of the bundles, so removing that set is fine. But I couldn't find any evidence of bm-panel.xul using either bundle_bookmark or bundle_brand. And navigator.xul already has bundle_brand, and I can't see it referring to bundle_bookmark either, so ... is that <stringbundleset/> still needed?

Why are you hiding the edit menu in navigatorOverlay.xul? I'm probably missing something, but I don't see where it gets unhidden.
The hidden menuitem and the stringbundle removal were fallout from other patches - sorry for the inconvenience. :-(
I, too, can't find real uses of bundle_bookmarks, but actually I don't think that this bug should be burdened with (undoubtly needed) bookmark clean-up...
Attachment #221238 - Attachment is obsolete: true
Attachment #221379 - Flags: superreview?
Attachment #221379 - Flags: review+
Attachment #221238 - Flags: superreview?(jag)
Attachment #221379 - Flags: superreview? → superreview?(jag)
Comment on attachment 221379 [details] [diff] [review]
corrected version, v3 (checked in)

sr=jag

File a bug (if there isn't one already) on cleaning up the string bundle stuff. Can we replace some of the JS string bundle code with XUL stringbundle elements, or should we just remove that set?
Attachment #221379 - Flags: superreview?(jag) → superreview+
Comment on attachment 221379 [details] [diff] [review]
corrected version, v3 (checked in)

>+  var key = document.getElementById("key_delete");
>+  if (key.getAttribute("command"))
>+    key.setAttribute("command", "cmd_bm_delete");
>+  key = document.getElementById("key_delete2");
>+  if (key.getAttribute("command"))
>+    key.setAttribute("command", "cmd_bm_delete");
You should use hasAttribute here and in all the duplicates.

>+  <keyset id="tasksKeys"/>
This one doesn't belong in the panel, surely?
Doh, I just checked in before I got your comments. :(
I'll do a follow-up patch, if you want me to...
Attachment #221379 - Attachment description: corrected version, v3 → corrected version, v3 (checked in)
Oops. r+sr=jag on removing that line.
> >+  if (key.getAttribute("command"))
> >+    key.setAttribute("command", "cmd_bm_delete");
> You should use hasAttribute here and in all the duplicates.

I disagree. Using "hasAttribute" would result in overwriting the command attribute if someone set it explicitly to "", but I only want to overrule command handlers that really do something.

I'll remove the erroneous line tonight, if noone else has done it by then. ;-)
Since there are currently no useable Mac nightlies, I'll leave the bug open for now.
Attachment #221836 - Flags: superreview+
Attachment #221836 - Flags: review+
We've got tinderbox (universal) builds again: http://ftp.mozilla.org/pub/mozilla.org/seamonkey/tinderbox-builds/bm-xserve01-trunk/
Status: NEW → RESOLVED
Closed: 24 years ago18 years ago
Resolution: --- → FIXED
Thank you Karsten. (Does this apply to Thunderbird too?)
No.
(The same problem was fixed for Thunderbird in bug 242864.)
I'm running SeaMonkey 1.1 on Mac, and this problem still exists.  What product is this bug for?  What is the Mozilla Suite if it isn't SeaMonkey?
(In reply to comment #63)
> I'm running SeaMonkey 1.1 on Mac, and this problem still exists.  What product
> is this bug for?  What is the Mozilla Suite if it isn't SeaMonkey?

This bug is for SeaMonkey. The reason you don't see the fix in 1.1 is that it was never checked in to the 1.8 branch. This is fixed on trunk, though. So you'll see it in the forthcoming 1.5 (2.0?) release.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: