Closed Bug 400691 Opened 12 years ago Closed 11 years ago

Word added to personal dictionary from Composer are not saved

Categories

(SeaMonkey :: Composer, defect)

SeaMonkey 1.1 Branch
x86
All
defect
Not set

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 345852

People

(Reporter: paulm, Unassigned)

Details

User-Agent:       Mozilla/5.0 (OS/2; U; Warp 4.5; en-GB; rv:1.8.1.8) Gecko/20071012 SeaMonkey/1.1.5 (PmW)
Build Identifier: Mozilla/5.0 (OS/2; U; Warp 4.5; en-GB; rv:1.8.1.8) Gecko/20071012 SeaMonkey/1.1.5 (PmW)

When using spell checking from Composer, selecting 'add to dictionary' does not add the word to the personal dictionary. It is saved only until all Seamonkey processes are closed. Next time Composer is used, the word must be saved again. If the word is saved from the Mail & News client, it is added to the dictionary.

Reproducible: Always

Steps to Reproduce:
1.Open Composer
2.Select Edit > Spellcheck as you type (why is this setting not saved??)
3.Enter a word not in the normal dictionary (eg Zenwalk)
4.Right click over word, select 'add to dictionary'
5.Close all Seamonkey processes
6.Open Composer and repear steps 2 and 3. Word comes up as misspelt. 
Actual Results:  
Any word added to the dictionary while using Spellcheck as you type from Composer is not saved to the personal dictionary.

Expected Results:  
Words added during a Composer session should be saved to the personal dictionary

This occurs in the OS/2 and Linux versions (tested using Seamonkey 1.1.5 on Zenwalk, 1.1.4 on Vector Linux).
I don't see this on Linux trunk [Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a9pre) Gecko/2007101802 SeaMonkey/2.0a1pre] so this might be branch specific.

Paul, can you check, if the word is actually written to persdict.dat in the profile directory? Also, can you open the Error Console (under Tools -> Web Development), and see if an error message appears when you try to add the word to the dictionary?
OS: OS/2 → All
Version: unspecified → 1.8 Branch
OK, with SeaMonkey 1.1.5 on Linux I see this, too. But only in my normal work profile, not in a different one or a new one. In those, the word appears in persdict.dat when shutting down. In the profile with the problem, the menu item just has no effect, no error message on the Error Console and the word indeed does not appears in persdict.dat.
My normal profile does have the Mnenhy extension installed (version 0.7.4.10005 apparently).
Sorry for the slow response - away for a few days....

I've checked (under both Linux and OS/2). If persdict.dat doesn't exist, it is not created. If it does exist, it is not modified. Composer will use an existing persdict.dat file, but seems unable to modify it. No errors are reported.

I've 1.1.5 under OS/2 and under Zenwalk 4.6.1, 1.1.4 under Vector Linux 4.9beta2. Behaviour is the same in all instances, and in both the normal user account and an extra account created just to test.

Only tried very quickly under Windows (don't run XP unlesss I _really_ have to), but from that brief experiment, the problem didn't seem to exist in the Windows branch. I'll try that a bit more extensively in the next day or so.
"In the next days or so", he said, then almost six months went by.

Paul, what is the present state of this bug? Are you still seeing it on current builds (and which ones)?
I still see this with SM 1.1.9 (just tested again on OS/2) but still not with trunk. No messages on the error console. persdict.dat is definitely updated, if it already exists, but only flushed to disk on shutdown. (As that seems to be the case, it would also be difficult to see errors about writing it in the error console). Until then the added words are available in memory, even if persdict.dat isn't created.

But I don't see what could be different between trunk and 1.8 branch, in both cases persdict.dat is accessed only (apart from migrators) from extensions/spellcheck/src/mozPersonalDictionary.cpp, look for MOZ_PERSONAL_DICT_NAME, and those calls are unchanged. In fact, there were only three unrelated changes to that file between trunk and branch...

As it works on trunk (can anybody confirm?) and branch is in security-fixes-only mode I guess we could also mark this WONTFIX.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Sorry. I've been using other tools for what small amount of web work I do.

Situation seems unchanged. I'm running 1.1.9 under several platforms (Zenwalk Linux, Vector Linux, OS/2). Still have the same problem. If the personal dictionary exists, words in it will be used. If it doesn't, it doesn't get created, and either way, if I add a word from Composer, it does not get added to the dictionary.

I will try a trunk build (I think I can create a Zenwalk install package from on of the nightly builds) and see if I can confirm the bug is squashed there...

Build identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008041601 SeaMonkey/2.0a1pre
MandrakeLinux-2008 2.6.22.18-desktop-1mdv #1 SMP Mon Feb 11 13:53:50 EST 2008 i686 Intel(R) Pentium(R) 4 CPU 2.53GHz GNU/Linux
Composer+spellchecker EN-US, for local HTML-files. Added words retain perfectly from day to day, spellchecking whole-page daily.
Nightly-Composer = unusable 2008-04-23 + 2008-04-24, so latest is unknown. Barry
Assignee: composer → nobody
QA Contact: composer
Version: 1.8 Branch → SeaMonkey 1.1 Branch
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 345852
Wayne, this Bug 400691 does not lose the added-word-after-a-crash (bug 345852).
It simply does not retain the word after SM is shutdown, if the word is entered from SM-Composer.

I apologise for losing track of this bug during the protracted unusable-Composer
Bug 395345 -  <editor> should stay editable after loading a document
, however, on checking tonight's nightly Composer, entered-words are being-saved-OK in Composer-spellchecker, even after SM is shut-down and restarted.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b2pre) Gecko/20081110 Lightning/1.0pre SeaMonkey/2.0a2pre ID:20081110000446.
You need to log in before you can comment on or make changes to this bug.