843727 - Having dictionaries listed as 'Dictionaries' (type 64) instead of plain 'extensions' makes them invisible to the internal Mozilla function getDictionaryList()

Status: RESOLVED FIXED

(Developer Documentation Graveyard :: API: Miscellaneous, defect)

Description

[Alfredo Fernández Díaz]

User Agent: Mozilla/5.0 (OS/2; Warp 4.5; rv:10.0.9) Gecko/20121011 Firefox/10.0.9 SeaMonkey/2.7.2
Build ID: 20121011194603

Steps to reproduce:

Retrieve a list of dictionaries from my extension via getDictionaryList()


Actual results:

I got a list with missing dictionaries, specifically those that are not listed under 'extensions' anymore, and are listed under 'dictionaries' instead.


Expected results:

I should have gotten a list with ALL available dictionaries

Comment 1

[Alfredo Fernández Díaz]

I expected this to be fixed but months have gone by and I see no changes to the relevant interfaces in 

https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIEditorSpellCheck#GetDictionaryList%28%29

For a while I told users to
"delete / comment out the line "<em:type>64</em:type>"
and you're done until the next dictionary update reverts it or until the
guys at Mozilla fix this, whichever comes first. The down side is,
meanwhile the 'dictionaries' tab will be empty, and dictionaries will
get listed as regular 'extensions'. Oh, the horror!"

but apparently I'm the only extension developer affected by the bug and now it's been raining bad reviews for a while, so I thought it was about time to report.

I've never reported an internal interfaces bug before so please excuse me and tell me how to improve any inaccuracies / vagaries in this report.

Comment 2

[Alfredo Fernández Díaz]

Sorry, I forgot the obvious. My extension depending on this can be seen along with many reports at https://addons.mozilla.org/addon/dictionary-switcher/ .
It had all been discussed to death in http://groups.google.com/group/mozilla.support.thunderbird/browse_thread/thread/f93da9855448b1c8/
but apparently new users are too lazy to check after their applications update and the extension 'mysteriously' stops working and just leave bad reviews

Comment 3

[Clément Sire]

Please, please, correct this bug; Dictionary switcher is a most useful extension, and it is a shame to be plagued by this bug...
Cheers

Comment 4

[Renato Silva]

It seems that the awesome Switchasitype is also blocked by this bug: https://github.com/saraedum/switchasitype/issues/3. It's not working in this very message, for example. English dictionary doesn't get selected, not even manually. Please fix this!

Comment 5

[C. Perrot]

I can confirm this bug on Thunderbird 17.0.7 (language used : French) / Dictionnary Switcher 1.3.2 / Windows Vista Professional (32 bits). The Diccionario de Español/España 1.7 is not visible with the Dictionnary switcher extension unless removing em:type 64.

Comment 6

[Dani]

I can confirm this bug on Thunderbird 17.0.7 (language used : Galician) / Dictionnary Switcher 1.3.2 / Windows XP Professional (32 bits). The Diccionario de Español/España 1.7 is not visible with the Dictionnary switcher extension unless removing em:type 64.
Dicionario de Galego 2.2.3 work fine, this not have em:type 64.
Not detect dictionaries when em:type 64 is present.

Comment 7

[Renato Silva]

The user Dagger said on #firefox channel:

I scanned the getDictionaryList() code. it's not obvious why it doesn't enumerate <type>64</type> dictionaries...
Oh. that would be because it does enumerate them.
Might be worth trying in Nightly?

Could anyone confirm this and update bug status? Also, how long will it take to see this fix released?

Comment 8

[Klemens Schölhorn]

Does not work in Nightly 26.0a1 (2013-09-07).
The german dictionary (https://addons.mozilla.org/de/firefox/addon/german-dictionary/) does not show up in the list of Alfredo's addon until I remove the type (<em:type>64</em:type>) from install.rdf.

Comment 9

[V@no]

The component of this bug "editor" is incorrect, because GetDictionaryList() from nsIEditorSpellCheck interface (https://developer.mozilla.org/docs/XPCOM_Interface_Reference/nsIEditorSpellCheck) works fine...

However the getDictionaryList() from mozISpellCheckingEngine interface (https://developer.mozilla.org/docs/XPCOM_Interface_Reference/mozISpellCheckingEngine) doesn't work properly.

Comment 10

[Alex]

The workaround of removing "<em:type>64</em:type>" does not work for https://addons.mozilla.org/en-US/firefox/addon/russian-spellchecking-dic-3703/
When that line is deleted or commented out, the dictionary no longer works at all.

This bug is open for over 7 months and is still "unconfirmed" in spite of numerous reports and a trivial way of reproducing.  Amazing!

Comment 11

[TGOS]

This bug is definitely confirmed; can easily confirm it myself.

Comment 12

[Renato Silva]

Commenting out the line "<em:type>64</em:type>" did work here for pt_BR, but en_US needed this additional line removed: "<em:bootstrap>true</em:bootstrap>". Then both Dictionary Switcher and Switchasitype were able to switch normally between the dictionaries while I type.

Comment 13

[TGOS]

Okay, after playing around a lot with the scratchpad and browsing the Mozilla source code, I think this is not a bug in Firefox but actually an implementation bug in the code of the extensions. If there is someone to blame at all, it is the MDN (Mozilla Development Network) author(s) for giving incorrect sample code that most extension developers just copied (and that is still found on the MDN pages).

The problematic piece of code is the following:

    var spellclass = "@mozilla.org/spellchecker/engine;1";
    var spellCheckEngine = Components.classes[spellclass].createInstance(
        Components.interfaces.mozISpellCheckingEngine
    );

This code creates a new instance of the spell check engine, which is not what the extensions really require. It seems that this has worked fine in the past, maybe because user installed dictionaries were added to the spell check engine each time it a new instance was created (or they added themselves there, after all dictionaries used to be "normal extensions" in the past), but now it seems like dictionaries installed by the user are added to a shared, global, singleton instance of the spell checker engine somewhere later in the bootstrap process of the application and this action is not automatically repeated if a new instance of the spell check engine is created, which seems to be the reason why the user installed dictionaries are missing.

Instead of creating a new instance, the extensions actually should access the already created and correctly initialized engine, using the following two lines of code:

    var spellclass = "@mozilla.org/spellchecker/engine;1";
    var = spellCheckEngine = Components.classes[spellclass].getService(
        Components.interfaces.mozISpellCheckingEngine
    );

Note that the code above uses "getService()" instead of "createInstance()" (as in the first code sample). If I now run the following code after the two lines above:

    var allDictsObj = {};
    spellCheckEngine.getDictionaryList(allDictsObj, {});

    var allDictsArray = allDictsObj.value;
    for (var index in allDictsArray) {
        console.log(allDictsArray[index]);
    }

I see all my installed dictionaries getting printed to console.

Maybe one of the extension authors can confirm this solution and fix their extension accordingly. In that case I'd vote for closing this bug as invalid, since the behavior of the API is not incorrect and the fact that it was working before by creating a new instance was rather a coincident than a documented feature.

Comment 14

[TGOS]

Please verify that my code suggestions actually solves the problem for you.

Comment 15

[Alfredo Fernández Díaz]

The code seems to work properly now.

I wanted to say thanks, however, not for what might be a working workaround but for providing an actual explanation of how code taken directly from MDN could be wrong yet work before.

Comment 16

[TGOS]

I hereby declare this bug as resolved. The solution is invalid because the bug itself is invalid. The bug was about complaining that user installed spell check dictionaries are not found in the list of dictionaries of a newly created spell check engine, but nowhere in the documentation was said that a newly created spell check engine will automatically have all user installed spell check engines added. Thus there is no proof that anything does not behave the way it is documented.

I admit that the documentation isn't very clear about that and the sample code is a bad example as it "indirectly implies" that creating a new instance is always the correct way to go. I will see if I can update the documentation accordingly.

Comment 17

[Patrick]

Shouldn't we rather file this bug against developer documentation?

Comment 18

[Alfredo Fernández Díaz]

(In reply to Patrick from comment #17)
> Shouldn't we rather file this bug against developer documentation?

That!

Comment 19

[TGOS]

I did fix the developer documentation already; I did so right after closing this bug.

See here:
https://developer.mozilla.org/en-US/docs/Using_spell_checking_in_XUL

Comment 20

[Patrick]

Closing it since I was the one to reopen it even if I feel unable to verify.

Please comment if needed!

Comment 21

[Renato Silva]

Thanks!