German installer.exe Version's Password-Manager does not populate password-fields

RESOLVED FIXED in seamonkey2.43

Status

defect
--
major
RESOLVED FIXED
4 years ago
3 years ago

People

(Reporter: Alexander_Pircher, Assigned: frg)

Tracking

SeaMonkey 2.38 Branch
seamonkey2.43

SeaMonkey Tracking Flags

(seamonkey2.38 wontfix, seamonkey2.39? wontfix, seamonkey2.40 affected, seamonkey2.41 fixed, seamonkey2.42 fixed, seamonkey2.43 fixed)

Details

User Story

Workaround:
-----------
Menu 'Bearbeiten → Einstellungen → Erscheinungsbild → Rechtschreibung - Generell → Sprache': Leere Auswahl durch eine Sprache ersetzen. Anschließend SeaMonkey schließen und neu starten

Attachments

(2 attachments, 4 obsolete attachments)

(Reporter)

Description

4 years ago
User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0 SeaMonkey/2.38
Build ID: 20150923195647

Steps to reproduce:

1. Upgraded Seamonkey from 2.35 to 2.38
2. Visit a website with a username and password-field
3. Choosed username in username-field


Actual results:

Password-field was not populated


Expected results:

Password-field should be populated

Comment 1

4 years ago
I can confirm this bug for the same environment:
  User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0 SeaMonkey/2.38
  Build-Identifikator: 20150923195647

Comment 2

4 years ago
It concerns the German version of SeaMonkey 2.38! The en-us version works for me.

Comment 3

4 years ago
NOT with  en-US (German language pack) SeaMonkey 2.38  (Windows NT 6.1; WOW64; rv:41.0)  Gecko/20100101 Firefox/41.0 Build 20150923195647  (Classic Theme) on German WIN7 64bit

I will test German Version soon.

@Reporter:
Please tell us
a) Your WIN- version (Windows 8.1 • Windows RT 8.1 • Windows Server 2012 R2?)
b) does auto fill for username work?
c) What do you see in menu 'Extras → PW-Manager'? 
   Any entries for domains for what you saved passwords?

Please answer without citing, simply start your reply like
a): <answer>
Flags: needinfo?(Alexander_Pircher)
Summary: Password-Manager does not populate password-fields after upgrade 2.38 → German Version: Password-Manager does not populate password-fields
(Reporter)

Comment 4

4 years ago
a): Windows 8.1

b): No, e.g. at https://login.yahoo.com/
Neither username or password are auto-filled. When double-clicking in username-field I can choose a username, however password-field is not populated. The username-list consists not only of username stored with the current domain, but also other usernames. It looks like there are no entries from the password-manager only entries from the form-manager matching the fieldname. Checked with https://addons.mozilla.org/seamonkey/addon/form-history-control/
There is no autocomplete=off in any element and password-manager for HTTP-Authentication is working.

c): Yes, all password-entries are still there like before the update.
Flags: needinfo?(Alexander_Pircher)

Comment 5

4 years ago
REPRODUCIBLE with  en-US (German language pack) SeaMonkey 2.38  (Windows NT 6.1; WOW64; rv:41.0)  Gecko/20100101 Firefox/41.0 Build 20150923195647  (Classic Theme) on German WIN7 64bit. I did an additional installation in a folder “ ...\SeaMonkey 2.38 de” parallel to folder “SeaMonkey 2.38 en-us”

Additional info:

d) on some pages also auto-fill for user name does not work (works fine with
   en-us)
e) Manu 'Tools → Password Manage' looks normal, ofr some samples I tried
   user name and password were shown as expected
f) The problem only appears if a German installer.exe has been used.
   SeaMonkey en-US with German Language pack does not show that problem.
g) SeaMonkey form Spanish Language installer.exe is not affected 
h) SeaMonkey form French Language installer.exe is not affected 
i) Strange: the problem has vanished after I have had installed french and
   Spanish SeaMonkey in separate program folders.
k) uninstallation and new installation of SeaMonkey 2.38 de into 
   new folder (after deletion of empty “SeaMonkey 2,38 de” folder for that
   SeaMonkey version did not bring back the problem after reboot
l) even uninstall French and Spanish version and reboot did not bring back
   the problem
m) it would be interesting to know whether error console shows something
   interesting during attempt for username / password entry.
   Can someone please try? I can't because of i … l
n) It would be interesting whether someone can confirm workaroung “install 
   fr version in parallel” after having done test “m”
Summary: German Version: Password-Manager does not populate password-fields → After Update from 2.35: German Version Password-Manager does not populate password-fields

Comment 6

4 years ago
o) also launching 2.35 en-us before new launch of 2.38 de will not bring back the 
   problem.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 7

4 years ago
Rainer, why did you change the bug-subject and wrote so much untestet things?

1) It is independed if you upgrade from an early version to V2.38 German Seamonkey or if you use an new installed V2.38 German SeaMonkey. The problem always occurs

2) It is independed if you use the German installer (.exe) or use SeaMonkey from the German zip-file. The problem always occurs

3) In a new profile, the password-manager have the same problems!

4) "i-l, m": It works only for sites, which you have used in your test! If you try a site the first time after change the SeaMonkey languages (i - l), the problem still exists

Comment 8

4 years ago
(In reply to Rainer Ullrich from comment #7)
> Rainer, why did you change
Because that text represents the knowledge from user story, my own test, de.comm.software.mozilla.misc / SM 2.38 (Release) und 2.39 (Beta): Passwort-Manager defekt at the time I wrote it.  You will understand better when you are no longer "New to Bugzilla" ;-)

1): How did you test that? Please contribute a step by step instruction.
Left registry entries can cause strange effects. "After Update ..." tells that there has been that former SM version on the PC what has been used for the tests. It does not tell "only after an update". 
Generally purpose of such precise limiting descriptions is to describe precisely test conditions and so how to make the effect reproducible reliably, but not necessarily to tell that the effect ONLY can be observed under that test conditions.

2): "... German installer.exe ..." tells that the problem only is reproducible with an native language software package (I only tested .exe, without a test I can't tell anything about a .zip), but not with only that language pack active (as I told under the same point). Please feel free to use more precise term. 

3): currently this seems to conflict with your "4)" - how can e new profile have PW-Manager with unused passwords? I will do my own test.
 
4): This is not in accordance with my tests (of course I did a test for that). After "i" (" ...k") PW-manger for me works perfect with ANY website. How did you get that result? Please contribute a precise step by step instruction.
Flags: needinfo?(rainer)

Comment 9

4 years ago
I'm not "New to Bugzilla". I use Mozilla-products since the beginning of Mozilla.

Sorry, I don't waste my time for more step by step instructions. It should be very clear how you can reproduce the problem. Take a look at the thread <mubooq$iuc$1@dont-email.me>, read all!

topic 3 and 4 are to different things! There is no conflict!

Once again: the bug-subject is wrong! it is independed if you made an update or not!
Flags: needinfo?(rainer)

Comment 10

4 years ago
o) I tested German SeaMonkey 2.41a1 Mozilla/5.0 (Windows NT 6.1; Win64; x64; 
   rv:44.0 from akalla download area)  Gecko/20100101  Firefox/ 44.0  Build 
   20150926114543, SourceStamp=94c804ef40d890b93062826c911755831edb51e4, 
   (Classic Theme) on German WIN7 64bit 
   with a newly created Profile: 
   Passwords will not be saved at all, “Save Password” message does not appear.
   I read about that problem at
   de.comm.software.mozilla.nightly-builds “[SM Aurora] Passwort speichern 
   geht nicht” 06.05.2015 01:15 +0200 by sosanne Jäger for 
   Mozilla/5.0 (X11; Linux x86_64; rv:39.0) Gecko/20100101 Firefox/39.0
   SeaMonkey/2.36a2  Build identifier: 20150504013001
   For me that problem also is limited to German SeaMonkey. Works fine in
   en-US (without German Language pack active for that profile)
   “Bug 1170210 - Password manager does not save passwords” related?
See Also: → 1170210, 1158496

Comment 11

4 years ago
I managed to create a new profile with German SM 2.38 where I stored a Password with en-US SM 2.38 and then changed back to German SM 2.38, and the problem was reproducible with that Profile again.
m): Auto-fill for user name worked, <TAB> to PW-input without reaction in
    Error console. I inserted PW by copy/paste from Password manager,
    also no reaction in error console
p) Something strange: In en-US SM 2.38 after I press <enter> after having 
   copy/paste from above I see an error message in error console:
   Error: NS_ERROR_FAILURE: Couldn't decrypt string
   Source File: resource://gre/components/crypto-SDR.js
   Line: 146
   I do not see this message in German SM 2.38 for the same action.

So far my results for this problem.

Updated

4 years ago
See Also: → 1210443

Updated

4 years ago
See Also: → 1209984

Comment 12

4 years ago
2.38 is being redistributed again and still shows the same problem !!!

Comment 13

4 years ago
If it works in en-US but fails on de the the German translation might be missing one or more strings.

Comment 14

4 years ago
(In reply to Philip Chee from comment #13)
> If it works in en-US but fails on de the the German translation might be
> missing one or more strings.
Or the correct version of the de language pack

Comment 15

4 years ago
(In reply to Philip Chee from comment #14)
My mistake in Comment 5: Version info copy-pase from wrong string :-(

Please see "f)" 
(Due to comment 8 - 2) also German .zip affected)
Summary: After Update from 2.35: German Version Password-Manager does not populate password-fields → After Update from 2.35: German installer.exe Version's Password-Manager does not populate password-fields

Comment 16

4 years ago
Changed summary due to Bug 1213089, where reporter updated from SM 2.33
Summary: After Update from 2.35: German installer.exe Version's Password-Manager does not populate password-fields → German installer.exe Version's Password-Manager does not populate password-fields

Comment 17

4 years ago
Does this also happen if you start SeaMonkey in safe mode?
Are there any relevant error messages in the Error Console?
Flags: needinfo?(RainerBielefeldNG)
Flags: needinfo?(Alexander_Pircher)

Comment 18

4 years ago
same problem in safe mode
same problem with new profile
no related errors in console
(Reporter)

Comment 19

4 years ago
Same error with safe mode, no output in error console.
Flags: needinfo?(Alexander_Pircher)

Comment 20

4 years ago
I confirm  Alex Pircher's obervation with German SeaMonkey 2.38  (Windows NT 6.1; WOW64; rv:41.0)  Gecko/20100101 Firefox/41.0 Build 20150923195647  (Classic Theme) on German WIN7 64bit:

1. Launched seamonkey from console with -ProfileManager -safe-mode
2. Selected special profile from Comment 11
3. in Browser opened https://bugzilla.mozilla.org/  → [Login] 
4. Used autofill to type user name <Tab>
   » Caret moves to PW input
   Bug: PW input line not populated 

As stated in Comment 5 the problem has vanished permanently for my normal profile after having used SM 2.38 from fr-installe, es-installer.
Flags: needinfo?(RainerBielefeldNG)

Comment 21

4 years ago
Still REPRODUCIBLE with  en-US SeaMonkey 2.40a2 Mozilla/5.0 (Windows NT 6.1; x64; rv:43.0 from akalla download area)  Gecko/20100101  Firefox/ 43.0  Build 20151010043152, (Classic Theme) on German WIN7

Comment 22

4 years ago
Correction for Comment 12: observed with GERMAN SeaMonkey 2.40a2

Comment 23

4 years ago
Correction for Comment 21 (not comment 12): observed with GERMAN SeaMonkey 2.40a2
(Reporter)

Comment 24

4 years ago
Compared seamonkey-2.38.de.langpack\chrome\de\locale\de\passwordmgr with seamonkey-2.35.de.langpack\chrome\de\locale\de\passwordmgr. The only difference is in passwordmgr.properties, 2.38 adds the following lines:

# LOCALIZATION NOTE (noUsernamePlaceholder):
# This is displayed in place of the username when it is missing.
noUsernamePlaceholder=Kein Benutzername
# LOCALIZATION NOTE (showPasswordPlaceholder):
# This is displayed in the password field to indicate that the password will be
# shown if focused.
showPasswordPlaceholder=ANZEIGEN

These parameters have also been added in en-US locale. I also compared seamonkey-2.38.source\comm-release\mozilla\toolkit\components\passwordmgr with seamonkey-2.35.source\comm-release\mozilla\toolkit\components\passwordmgr. There have been really many changes in password-manager component from 2.35 to 2.38.
Severity: normal → major

Updated

4 years ago
Duplicate of this bug: 1213089
(Assignee)

Comment 26

4 years ago
Could anyone who has this problem check what is displayed under Rechtschreibung. My Language (Sprache) field was empty. As soon as I choose German the stored passwords were used again. I had to close the browser for this to work after changing the value. 

User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:42.0) Gecko/20100101 Firefox/42.0 SeaMonkey/2.39

Comment 27

4 years ago
(In reply to Frank-Rainer Grahl from comment #26)
> Rechtschreibung. My Language (Sprache) field was empty. As soon as I choose
> German the stored passwords were used again. I had to close the browser for
> this to work after changing the value. 

q) I confirm all details  with  German SeaMonkey 2.38  (Windows NT 6.1; WOW64;
   rv:41.0)  Gecko/20100101 Firefox/41.0 Build 20150923195647  (Classic Theme)
   on German WIN7 64bit
r) I closed and restarted SeaMonkey completely, afterwards the empty language list
   item has vanished.
i): might be result of "somehow" being replaced empty spell check language 
    selector by a language when I installed some other language

Updated

4 years ago
User Story: (updated)

Updated

4 years ago
User Story: (updated)
(Assignee)

Comment 28

4 years ago
The default preference is missing in the file suite-l10n.js. It's present in this file for en-us builds. This patch needs to be pushed to all l10n branches for the password manager to work again.
Attachment #8678435 - Flags: review?

Comment 29

4 years ago
German does not ship a dictionary (due to licensing reasons), so setting this pref probably just makes it point to a different non-existing one. Did you try this patch with a new, default profile that doesn't contain an installed dictionary?
(Assignee)

Comment 30

4 years ago
You are right. I didn't test this. 

>> mk_add_options MOZ_CO_LOCALES="de"
>> ac_add_options --enable-ui-locale=de

I did built my installer using de.dic and de.aff with:

>> mk_add_options MOZ_CO_LOCALES="de"
>> ac_add_options --enable-ui-locale=de

I got both dictionary files from Libreoffice and they are automatically installed. 

The good news is that if I remove the de.* files from the dictionaries directory and create a new profile the password manager still works. The list box in the settings is empty but the default setting in about:config is still set to "de". I also briefly created a newsgroup account and subscribed to mozilla.test. Composing a message works and the spell check does also contain nothing but also does not crash or throws an error.

So I think the patch works but maybe the default preference value should be changed to a blank string?

Shouldn't be maybe a dummy de dictionary shipped with Seamonkey if some code relies on them?

Updated

4 years ago
See Also: 1210443
Duplicate of this bug: 1210443
Comment on attachment 8678348 [details]
Correct setting for German spellchecker

My "Sprache" field is empty as well, because I do not use any "Rechtschreibung". I even haven't downloaded any dictionary at all, and I do not intend to do so. I rely on Brain 1.0.

If this really is the cause of the problem, then something must be very broken.

Comment 33

4 years ago
(In reply to Frank-Rainer Grahl from comment #30)
> Shouldn't be maybe a dummy de dictionary shipped with Seamonkey if some code
> relies on them?

The real bug is that no code should ever rely on them.

Also, there is no "de" dictionary, there are "de-DE", "de-AT" and "de-CH" ones, which are somewhat different (esp. the latter).

That said, we can do that workaround in the locale to add the pref if that helps to not be broken, but a bug has to be filed on the underlying breakage of this not being set causing issues.

Or maybe the right patch is to do what Thunderbird did in http://mxr.mozilla.org/comm-central/source/mail/app/profile/all-thunderbird.js#425

Interestingly, it looks like Firefox gets away with not doing that.

Comment 34

4 years ago
And, actually, I wonder what happens when the code starting in http://mxr.mozilla.org/comm-central/source/suite/common/src/nsSuiteGlue.js#951 find the pref not set at all. Does it error out and make something else not be executed at all, or does it fail with no consequence?
(Assignee)

Comment 35

4 years ago
>> If this really is the cause of the problem, then something must be very broken.

My guess is that because of the missing pref and the throw in nsSuiteGlue.js something is not properly initialized. I didn't analyze this further. Code there maybe should be fixed too.

Comment 36

4 years ago
Yes, I wonder if we throw in nsSuiteGlue and with that, don't initialize things correctly. If that's the case, that could be the whole source of this bug.
(Assignee)

Comment 37

4 years ago
>> Also, there is no "de" dictionary, there are "de-DE", "de-AT" and "de-CH" ones, which are somewhat different (esp. the latter).

Yupp. Was just happy that I managed to compile and make an installer:) de seems to be the just the locale used in the ui. 

>>
That said, we can do that workaround in the locale to add the pref if that helps to not be broken, but a bug has to be filed on the underlying breakage of this not being set causing issues.
<<

I will try it with an empty string which seems to be the better way to do it.

Comment 38

4 years ago
(In reply to Frank-Rainer Grahl from comment #37)
> >> Also, there is no "de" dictionary, there are "de-DE", "de-AT" and "de-CH" ones, which are somewhat different (esp. the latter).
> 
> Yupp. Was just happy that I managed to compile and make an installer:) de
> seems to be the just the locale used in the ui. 

As long as you don't distribute it anywhere, that's fine. A package of the browser with the dictionary can't be distributed due to license incompatibilities. Go complain to Björn Jacke, author of the dictionaries, if that causes you pain.

> I will try it with an empty string which seems to be the better way to do it.

If the throwing in nsSuiteGlue is the issue, I'd prefer we fix it there, to be honest. But it would be good to know if just setting the pref at a general level to empty string is making things work.
(Assignee)

Comment 39

4 years ago
Alternate patch. Initialize the preference in all languages if not present.
(Assignee)

Comment 40

4 years ago
>> If the throwing in nsSuiteGlue is the issue, I'd prefer we fix it there, to be honest. But >> it would be good to know if just setting the pref at a general level to empty string is 
>> making things work.

Works too.

I uploaded an alternate patch. I hope browser-prefs.js is the right file for it.

Verified that it worked in en-US and de x86 builds. I only tried it with comm-beta because trunk is busted today. Compiles but has an xpi error. 

Difference with this patch is that the setting is just always marked in bold as changed and will be set to blank String if reset. Reverts back after next browser start.

Not sure if both patches shouldn't be used. First one to keep the file in sync with the en-US locale and alternate one to always initialize the setting so that nsSuiteGlue never throws an error.

As for fixing nsSuiteGlue. I usually agree that something like this should be fixed. But if a setting or value or whatever is really mandatory I usually prefer a visible error instead of putting lines of code in it to cover all possible code paths.

Comment 41

4 years ago
(In reply to Frank-Rainer Grahl from comment #40)
> I uploaded an alternate patch. I hope browser-prefs.js is the right file for
> it.

Yes, if our solution is to go and set the pref in all cases, that's the place to do it.

> As for fixing nsSuiteGlue. I usually agree that something like this should
> be fixed. But if a setting or value or whatever is really mandatory I
> usually prefer a visible error instead of putting lines of code in it to
> cover all possible code paths.

I don't think it actually is or should be mandatory - even more so as Firefox gets by without setting the pref by default. But I guess we'll need to SeaMonkey code owner, Neil, to decide on that.

Neil, what do you think?
Flags: needinfo?(neil)
(Reporter)

Comment 42

4 years ago
(In reply to Frank-Rainer Grahl from comment #26)
> Rechtschreibung. My Language (Sprache) field was empty. As soon as I choose
> German the stored passwords were used again. I had to close the browser for
> this to work after changing the value. 

The field is empty, I can not choose a language only to download further language packs. After choosing this option but not downloading a dictionary actually and restarting the browser password manager was working again.

spellchecker.dictionary contained "more-cmd" afterwards. When reseting spellchecker.dictionary and restarting password manager was not working again, when setting to " " and restarting password manager was working again.
(Assignee)

Comment 43

4 years ago
Basically if the preference spellchecker.dictionary in about:config is there and has something in it may it be an empty or garbage string the password manager works.
(In reply to Robert Kaiser from comment #41)
> (In reply to Frank-Rainer Grahl from comment #40)
> > I uploaded an alternate patch. I hope browser-prefs.js is the right file for
> > it.
> 
> Yes, if our solution is to go and set the pref in all cases, that's the
> place to do it.

But don't forget to remove it from suite-l10n.js too.

> > As for fixing nsSuiteGlue. I usually agree that something like this should
> > be fixed. But if a setting or value or whatever is really mandatory I
> > usually prefer a visible error instead of putting lines of code in it to
> > cover all possible code paths.
> 
> I don't think it actually is or should be mandatory - even more so as
> Firefox gets by without setting the pref by default.

That's because when the spellchecker.dictionary preference is empty or unset then it uses the locale - which is what suite-l10s.js was trying to do using @AB_CD@ anyway. However setting the preference can still be beneficial, for example:
* British locale is selected
* Installed dictionaries: Australian, Austrian, British, German
* Page Language is American
* If the spellchecker.dictionary preference is set to Australian or British, then that dictionary will be used
* If the spellchecker.dictionary preference is not set or it is set to Austrian or German then the Australian dictionary will probably be chosen arbitrarily (note that the locale is ignored in this case)

Note that the mail composition code would prefer to have the preference set, which is why the code in nsSuiteGlue.js wants to set it. I therefore have a slight preference for allowing localisers to specify the dictionary that they ship, which would mean one of two things:
- Making the code in nsSuiteGlue.js deal with a missing preference; bonus marks for trying the selected locale
- Defining the spellchecker.dictionary preference as a localised string, which is what the spell checker code actually expects
Flags: needinfo?(neil)

Comment 45

4 years ago
(In reply to neil@parkwaycc.co.uk from comment #44)
> But don't forget to remove it from suite-l10n.js too.

No, locales still need to set it to an actually useful value (which can differ from @AB_CD@ unfortunately), the default pref should be empty, which is the wrong value when a dict is present.

I'd actually prefer a fix though so that nsSuiteGlue sets it to empty when it's not set (and that is throwing and not caught right now, breaking stuff in the process) and no dictionary is present.
(Assignee)

Comment 46

4 years ago
And now a patch for the third option. Fixing nsSuiteGlue.js to not throw an exception.

Tested it only briefly but seems to work. The en-US suite-l10n.js needs only to be changed if you want to test it on US builds. In this case also remove the dictionaries and try it on a new profile.

My preference is still patch 2 combined with patch 1 to always initilize and set it but either one of the three is good in my eyes and fixes the problem for German builds. 2 and 3 should fix it for all language builds without a dictionary.

To quote '1, 2 oder 3' a former German quizshow for kids: „Ob ihr recht habt oder nicht, sagt euch gleich das Licht.“

FRG
Attachment #8681690 - Flags: review?
(Assignee)

Updated

4 years ago
Attachment #8678435 - Flags: review? → review?(neil)
(Assignee)

Updated

4 years ago
Attachment #8678471 - Flags: review?(neil)
(Assignee)

Updated

4 years ago
Attachment #8681690 - Flags: review? → review?(neil)
(In reply to Robert Kaiser from comment #45)
> (In reply to comment #44)
> > But don't forget to remove it from suite-l10n.js too.
> 
> No, locales still need to set it to an actually useful value (which can
> differ from @AB_CD@ unfortunately), the default pref should be empty, which
> is the wrong value when a dict is present.

If it's blank then won't the nsSuiteGlue.js code set it to a useful value if a dictionary exists?

Comment 48

4 years ago
(In reply to neil@parkwaycc.co.uk from comment #47)
> If it's blank then won't the nsSuiteGlue.js code set it to a useful value if
> a dictionary exists?

True, but necessarily the right one that the locale considers the default.
Suppose you started with the German version, then installed multiple dictionaries, would you want to default to the German dictionary?

Comment 50

4 years ago
(In reply to neil@parkwaycc.co.uk from comment #49)
> Suppose you started with the German version, then installed multiple
> dictionaries, would you want to default to the German dictionary?

If that dictionary is included in the German install, then yes. (German does not have any dictionary it installs by default, though.)
(In reply to Robert Kaiser from comment #50)
> (In reply to comment #49)
> > Suppose you started with the German version, then installed multiple
> > dictionaries, would you want to default to the German dictionary?
> 
> If that dictionary is included in the German install, then yes. (German does
> not have any dictionary it installs by default, though.)

Sorry, I meant currently, when it doesn't ship any dictionaries.

Comment 52

4 years ago
In that case, I'd expect us to set any that is installed, not necessarily a German one (and there is none in existence that exactly matches the locale code anyhow, the the build is "de" while the dictionaries are "de-DE", "de-AT" or "de-CH").
(Assignee)

Comment 53

4 years ago
nssuiteglue.js already does this if it finds an invalid entry. As long as even one dictionary is installed it is set. 

>>     // If the preference contains an invalid dictionary, set it to a valid
>>     // dictionary, any dictionary will do.

A better solution would be to query the system locale and find a compatible dictionary in this case. But this would need OS specific methods and imho not worth the manpower to do it. There are other construction zones which should be tackled first

Comment 54

4 years ago
just for your guidance

2.39 behaves as before:
- German installer does not work
- English installer works
- English installer with German language-pack on top: don't know, no language-pack for 2.39 available

rgds
mh
(In reply to mhonline from comment #54)
> just for your guidance
> 
> 2.39 behaves as before:
> - German installer does not work
> - English installer works
> - English installer with German language-pack on top: don't know, no
> language-pack for 2.39 available
> 
> rgds
> mh

IIUC, there is now a 2.39 langpack for German (and a number of others for different languages) at http://www.seamonkey-project.org/releases/#langpacks

However, there are no spelling dictionaries for "de" German (with no regional suffix) but only for de-AT, de-DE and de-CH: see full discussion in bug 1235993.
Comment hidden (obsolete)
(Assignee)

Comment 57

3 years ago
Bug is a little stale for me. Would be great if 2.40 or 2.41 could include the fix. Anyone else who can review this bug and tell me / us what what version is best? 

FRG
(In reply to Frank-Rainer Grahl from comment #57)
> Bug is a little stale for me. Would be great if 2.40 or 2.41 could include
> the fix. Anyone else who can review this bug and tell me / us what what
> version is best? 
> 
> FRG

Hmm, let's see… KaiRo is Data Manager owner and German localizator (von Wilhelmshaven bis Eisenstadt und von Zermatt bis Sassnitz, haha), he might be interested; otherwise general "UI" reviewers are Neil, IanN and maybe Mnyromyr.
P.S. When fixing a bug which affects the Trunk, always fix it first on Trunk. Porting the fix from Trunk to successively earlier "branches" requires not only r+ (review) but also a+ (approval).

Comment 60

3 years ago
My latest opinion is in comment #45 and that's still what I think about this particular bug.
(Assignee)

Comment 61

3 years ago
Then lets just fix nsSuiteGlue.js only.
Attachment #8678435 - Attachment is obsolete: true
Attachment #8678471 - Attachment is obsolete: true
Attachment #8681690 - Attachment is obsolete: true
Attachment #8678435 - Flags: review?(neil)
Attachment #8678471 - Flags: review?(neil)
Attachment #8681690 - Flags: review?(neil)
Attachment #8703430 - Flags: review?(kairo)

Comment 62

3 years ago
Comment on attachment 8703430 [details] [diff] [review]
1208971-spellchecker-pref-V2.patch

This looks good to me, exactly what I think should be done. That said, I'd like Neil to actually put the official review on this.
Attachment #8703430 - Flags: review?(neil)
Attachment #8703430 - Flags: review?(kairo)
Attachment #8703430 - Flags: feedback+
Comment on attachment 8703430 [details] [diff] [review]
1208971-spellchecker-pref-V2.patch

>+    var prefValue = " ";
(Is there any reason to put a space here? Otherwise I'd remove it.)
Attachment #8703430 - Flags: review?(neil) → review+
(Assignee)

Comment 64

3 years ago
>> (Is there any reason to put a space here? Otherwise I'd remove it.)

Not Exactly. Will retest it with an empty string and if it works ask for checkin.

FRG
(Assignee)

Comment 65

3 years ago
Just changed the pref initialize to "".

Carried over review+ from Neil and feedback+ from kairo.
Attachment #8703430 - Attachment is obsolete: true
Attachment #8707172 - Flags: review+
Attachment #8707172 - Flags: feedback+
(Assignee)

Updated

3 years ago
Keywords: checkin-needed
(Assignee)

Comment 66

3 years ago
Comment on attachment 8707172 [details] [diff] [review]
1208971-spellchecker-pref-V3.patch

[Approval Request Comment]
Regression caused by (bug #): unknown
User impact if declined: Password feature broken when no dictionary installed.
Testing completed (on m-c, etc.): Yes. Tested on c-b and c-a
Risk to taking this patch (and alternatives if risky): None. Bustage fix for de build. en-us build tested and not affected.
String changes made by this patch: None
Attachment #8707172 - Flags: approval-comm-beta?
Attachment #8707172 - Flags: approval-comm-aurora?

Comment 67

3 years ago
Comment on attachment 8707172 [details] [diff] [review]
1208971-spellchecker-pref-V3.patch

a=me for c-a and c-b
Attachment #8707172 - Flags: approval-comm-beta?
Attachment #8707172 - Flags: approval-comm-beta+
Attachment #8707172 - Flags: approval-comm-aurora?
Attachment #8707172 - Flags: approval-comm-aurora+

Comment 68

3 years ago
Landed on c-c:
https://hg.mozilla.org/comm-central/rev/96bcab794a6e

Leaving checkin-needed for landing on aurora and beta.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
OS: Unspecified → All
Hardware: Unspecified → All
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.