RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1150572 - default spellchecker dictionary is not correct for firefox
Summary: default spellchecker dictionary is not correct for firefox
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: firefox
Version: 7.1
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Jan Horak
QA Contact: Desktop QE
Depends On: 643954
Blocks: 1133060
TreeView+ depends on / blocked
Reported: 2014-10-08 12:43 UTC by Stephen Beal
Modified: 2019-11-14 06:31 UTC (History)
18 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 643954
Last Closed: 2015-01-13 23:19:18 UTC
Target Upstream Version:

Attachments (Terms of Use)
video displaying bug (3.68 MB, application/octet-stream)
2015-01-14 12:59 UTC, Stephen Beal
no flags Details
Latest screencase to show behavior (4.63 MB, application/octet-stream)
2015-01-15 14:04 UTC, Stephen Beal
no flags Details

System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 455543 0 None None None Never
Red Hat Product Errata RHSA-2015:0046 0 normal SHIPPED_LIVE Critical: firefox security and bug fix update 2015-01-14 04:18:51 UTC

Comment 3 Jan Horak 2014-11-19 13:53:52 UTC
Upstream bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1097625

Comment 5 errata-xmlrpc 2015-01-13 23:19:18 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Comment 7 Stephen Beal 2015-01-14 12:59:02 UTC
Created attachment 979989 [details]
video displaying bug

Comment 11 Stephen Beal 2015-01-15 14:04:04 UTC
Created attachment 980506 [details]
Latest screencase to show behavior

Comment 12 Jan Horak 2015-01-15 14:20:04 UTC
Hm, please try with the fresh profile (firefox -ProfileManager). Do you also see this on some public pages, like here http://www.html.am/html-codes/textboxes/html-textbox.cfm ?

Comment 17 Jan Horak 2015-01-29 13:53:28 UTC
I'm still unable to reproduce customer's issue.

Do the customer have some system wide preferences set? These preferences are in /usr/lib64/firefox/defaults or /usr/lib64/firefox/defaults/pref directories.

Recorded video resembles behavior of previous Firefox version 31.3. Please could the customer double check that they have firefox 31.4.0-1 installed?

Anyway customer can safely remove hunspell-en package by yum remove hunspell-en. Then en_US dictionary still stay installed.

Comment 23 Siteshwar Vashisht 2015-02-03 14:58:41 UTC
There are 2 issues here :

1. 'en_ZW' dictionary is used by default (when you have not explicity set spellchecker dictionary)
2. Default dictionary keeps getting set back to 'en_ZW'

I am able to reproduce issue 1.

Steps to reproduce :

1. Start with a fresh firefox profile

2. Visit 'http://google.co.in/'. Right click search box and enable spellchecker.

3. Righ click search box and select Languages. 'Engligsh (Zimbabwe)' is selected in the list by default.

When spellchecker is enabled, nsEditorSpellCheck::UpdateCurrentDictionary() method is invoked from editor/composer/src/nsEditorSpellCheck.cpp :

697 nsEditorSpellCheck::UpdateCurrentDictionary(nsIEditorSpellCheckCallback* aCallback)
698 {
699   nsresult rv;
701   nsRefPtr<nsEditorSpellCheck> kungFuDeathGrip = this;
703   // Get language with html5 algorithm
704   nsCOMPtr<nsIContent> rootContent;
705   nsCOMPtr<nsIHTMLEditor> htmlEditor = do_QueryInterface(mEditor);
706   if (htmlEditor) {
707     rootContent = htmlEditor->GetActiveEditingHost();
708   } else {
709     nsCOMPtr<nsIDOMElement> rootElement;
710     rv = mEditor->GetRootElement(getter_AddRefs(rootElement));
711     NS_ENSURE_SUCCESS(rv, rv);
712     rootContent = do_QueryInterface(rootElement);
713   }
716   DictionaryFetcher* fetcher = new DictionaryFetcher(this, aCallback,
717                                                      mDictionaryFetcherGroup);
718   rootContent->GetLang(fetcher->mRootContentLang);
719   nsCOMPtr<nsIDocument> doc = rootContent->GetCurrentDoc();
720   NS_ENSURE_STATE(doc);
721   doc->GetContentLanguage(fetcher->mRootDocContentLang);
723   rv = fetcher->Fetch(mEditor);
724   NS_ENSURE_SUCCESS(rv, rv);
726   return NS_OK;
727 }

Line 712 will fetch root element of the page and line 718 will set language specified in root item as the dictionary to be used.

Google India home page specifies value of lang attribute to "en-IN" :
<html itemscope="" itemtype="http://schema.org/SearchResultsPage" lang="en-IN">

but there is no 'en-IN' dictionary on my system, so the search will fallback to editor/composer/src/nsEditorSpellCheck.cpp:822

822       // Otherwise, try any available dictionary aa-XX
823       if (NS_FAILED(rv)) {
824         // loop over avaible dictionaries; if we find one with required
825         // language, use it
826         nsTArray<nsString> dictList;
827         rv = mSpellChecker->GetDictionaryList(&dictList);
828         NS_ENSURE_SUCCESS(rv, rv);
829         int32_t i, count = dictList.Length();
830         for (i = 0; i < count; i++) {
831           nsAutoString dictStr(dictList.ElementAt(i));
833           if (dictStr.Equals(dictName) ||
834               dictStr.Equals(preferedDict) ||
835               dictStr.Equals(langCode)) {
836             // We have already tried it
837             continue;
838           }
839           if (nsStyleUtil::DashMatchCompare(GetDictNameWithDash(dictStr), langCode, comparator) &&
840               NS_SUCCEEDED(SetCurrentDictionary(dictStr))) {
841               break;
842           }
843         }
844       }

'en_ZW' is the first dictionary which matches condition specified in line 839 and is set as default dictionary.

Comment 24 Jan Horak 2015-02-03 15:58:49 UTC
Thanks for the debugging and reproducer. In fact from Mozilla point of view the code is correct. In Mozilla products users install dictionaries by their own. Fallback to first dictionary in list that user actually installed is most likely correct for majority of Firefox/Thunderbird users.

This is wrong for Fedora and RHEL however. The hunspell-en package contains various dialects, in fact all of them are symlink to en-GB. This is because we want working dictionaries for some other locales, not just for en_US and en_GB (some applications require language_region to be the same to locale settings to be able to find and use the dictionary).

This bug was initially about fallback to French (if you had French dictionary installed) instead of some English dictionary on English pages because the fallback code didn't work correctly for our dictionaries (our dictionaries use underscore as separator, Mozilla use dash). I think issue with en_ZW is another bug so we should fill another one.

Comment 25 Laura Novich 2015-02-03 16:59:14 UTC
I have RHEL 6 installed - there is no fallback to French - it is the default, no matter how many times I have tried to change it. I do not speak French and do not reside in a French speaking country so there is no reason why I would have enabled it. Also for whatever reason, Mozilla seems to think I am located in the Netherlands so content that is enabled to track location and to localize presents itself in Dutch. 
When will these fixes be applied to RHEL 6 CSB?


Comment 26 Siteshwar Vashisht 2015-02-04 09:14:11 UTC
Opened a new bug at https://bugzilla.redhat.com/show_bug.cgi?id=1189018 as requested in comment #24.

Note You need to log in before you can comment on or make changes to this bug.