On 31/08/2015 17:18, Ehsan Akhgari wrote:
Just wanting to reiterate that the problem is not as big as you claim
it is. We did not break Firefox for "single language users".
If you take a good look at the fallback processing in
editor/composer/nsEditorSpellCheck.cpp, you will notice that it is
highly broken. Single language users who visit a site where the language
doesn't match any on the dictionaries (or the only dictionary) they
have, end up with no dictionary set. Try:
<div style="background-color:#eee;border:1px solid #000;padding:10px"
lang="ko" contenteditable="">
<div>element ko (which is not installed)</div>
</div>
or visit https://www.kyobo.co.kr on your Firefox now, assuming that you
don't have Korean installed.
This code is in desperate need of a clean-up. Some fallbacks only work
if the site doesn't supply a language, see below for a list of all the
problems I encountered.
This is a mish-mash of probably unrelated bugs that have any number of
causes and solutions. Not sure why this is relevant to anything
discussed here.
While some of the bugs may be unrelated, you get the general idea of
users not understanding why a specific spell check language is used.
Part of the discussion here is to establish clear rules that everybody
can understand. The rule: "If you visit site 1 and change the spelling
language (which is currently stored in the preference) and then visit
site 2 you may or may not get the language you just set" is something no
one understands.
If nothing else, I'd clean-up the fallback behaviour, since it's broken
and unclear. I'd also clean up the content preference behaviour since I
cannot store "en-GB" on an "en" website, resulting the explicit user
choice to be forgotten all the time.
"Your" code is broken here:
https://dxr.mozilla.org/mozilla-central/source/editor/composer/nsEditorSpellCheck.cpp?offset=11100#616
("en-GB" on an "en" site like BMO gets tossed away)
https://dxr.mozilla.org/mozilla-central/source/editor/composer/nsEditorSpellCheck.cpp?offset=11100#764
(faulty error handling)
https://dxr.mozilla.org/mozilla-central/source/editor/composer/nsEditorSpellCheck.cpp?offset=11100#768
(this is wrong, that should be retrieved straight after getting the
language of the element/parent, if this isn't set)
https://dxr.mozilla.org/mozilla-central/source/editor/composer/nsEditorSpellCheck.cpp?offset=16900#834
(this is wrong, since rv controlls the flow of the fallback, but is used
as the return status for a helper function)
https://dxr.mozilla.org/mozilla-central/source/editor/composer/nsEditorSpellCheck.cpp?offset=18400#853
(IMHO the status should be checked here)
https://dxr.mozilla.org/mozilla-central/source/editor/composer/nsEditorSpellCheck.cpp?offset=21400#859
(this is wrong, see Korean example above)
https://dxr.mozilla.org/mozilla-central/source/editor/composer/nsEditorSpellCheck.cpp?offset=20800#871
(this is wrong, must not check rv again)
https://dxr.mozilla.org/mozilla-central/source/editor/composer/nsEditorSpellCheck.cpp?offset=21200#880
(this makes no sense, since en-US is not a useful fallback for most
locales).
I've looked at this code for a few days now and tested a few things, and
it simply doesn't work in any meaningful way.
I don't really have any concrete suggestions unfortunately. If this
is an area that interests you I suggest to start working on the UX
with the help of our UX team. The implementation strategy needs to
come after agreeing on what UI/UX we want to support here.
I think the first step should be to clean up the current mess, even if
we mostly maintain the current behaviour of storing
"spellchecker.dictionary" as a possible fallback.
Then yes, I'd be interested to get to know the UX people you talk about.
From the Thunderbird side I know Blake and Jim.
Jorg K.
_______________________________________________
dev-platform mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-platform
