43348 - Spell check: Using "Remove" or "Replace" buttons don't work in personal dictionary dialog

Status: VERIFIED INVALID

(Core :: DOM: Editor, defect, P4)

Description

[rubydoo123]

Selected added word in the personal dictionary, selected delete and the word was 
not deleted.

Steps to reproduce:
1. open either an existing page or new page. If a new page, enter several lines 
of text, making sure to add some unique words such as Netscape or AOL.
2. select spelling from toolbar or menu
3. when the unique word os found and is displayed in the text field of the spell 
check dialog, select add. Complete the spell check session.
4. Relaunch spell check and select Edit from the dialog
5. In the edit personal dictionary dialog, select the word you just added and 
select delete.

What happens: the word is not deleted

Comment 1

[rubydoo123]

setting to m17

Comment 2

[kinmoz]

Accepting bug.

Comment 3

[rubydoo123]

needs to be fixed for beta3

Comment 4

[rubydoo123]

setting to nsbeta3+

Comment 5

[rubydoo123]

setting priority in status whiteboard

Comment 6

[leger]

PDT downloading to [nsbeta2-]

Comment 7

[rubydoo123]

hopefully the user will be able to edit the personal dictionary with another 
application

setting to minus, moving to future and adding helpwanted

Comment 8

[Charles Manske]

*** Bug 73268 has been marked as a duplicate of this bug. ***

Comment 9

[Charles Manske]

Changed Summary for better searching.
I think this should be reevaluated for 0.9.1

Comment 10

[TucsonTester1]

Confirming Spell`s User Dictionary behaviour still exists in Composer build
20010903.

While testing Spell Check feature using a rather long pre-saved document,
created a new Personal Dictionary list by adding approximately 145 odd
words--some mispelled, even.  Could empty, though not permanently delete, the
Personal Dictionary list, just as described above.  After seemingly have
unloadeded the entire list under ``Words in dictionary:,'' by navigating
[Spell], [Edit] Personal Dictionary, highlighting the first word in the list
[Remove], [Remove], [Remove], ... [Close], the list will return every time.

Completely exiting the software altogether has no additional effect.  The list
persists.


Note: Please see also, where the exact issue appears in (Mail) Composer Spell
Check User Dictionary, as originally indicated in Bug 58901.  The identical
list, apparently ``emptied,'' magically appears untouched when Personal
Dictionary is reopened.

Comment 11

[Jean-Francois Ducarroz]

*** Bug 58901 has been marked as a duplicate of this bug. ***

Comment 12

[kinmoz]

Bulk move of mozilla1.0 bugs to mozilla.1.0.1. I will try to pull some of these
back in if I can.

Comment 13

[Andrew Hagen]

Shouldn't Platform/OS be set to all/all on this bug?

Comment 14

[Charles Manske]

*** Bug 152546 has been marked as a duplicate of this bug. ***

Comment 15

[Charles Manske]

I think this should get some attention! Marking editorbase.

Comment 16

[Charles Manske]

The reason this hasn't been fixed a long time ago is explained by kin:
"It's a bug in the INSO codethere's a bit that's preventing things from being
removed I don't see how (in the INSO API)to cause that bit to get set/unset"

Comment 17

[Charles Manske]

Attachment: Workaround patch v1 for NS spellcheck module

This patch is contingent on adding ResetPersonalDictionary to NS spellcheck
code 
as well (see bugzilla bug 127704).
But to do this right in mozilla space, we probably should have an overlay that
uses code in this patch only when using the INSO spell checker.
I hope the mozdev spellchecker doesn't have this problem and doesn't have to
use this hack.

Comment 18

[Charles Manske]

In last comment, adding "ResetPersonalDictionary()" to NS code is
http://bugscape.netscape.com/show_bug.cgi?id=16869 for NS people to look at.

Comment 19

[Gayatri Rimola]

Nominating for Buffy. Workaround is to close and re-open Netscape and deleted
items will no longer show. 

Comment 20

[Kevin McCluskey (gone)]

Syd: Can someone on the composer team take this one? Kin's overloaded. Thanks.

Comment 21

[Charles Manske]

i'll look at this a bit

Comment 22

[Kathleen :Brade]

-->kin

Comment 23

[kinmoz]

This turned out to be a bug in the 3rd party spellchecker Netscape uses.
(bugscape id 13713)

Resolving this bug as invalid since it's not front end related.

Comment 24

[rubydoo123]

verified