1150572 – default spellchecker dictionary is not correct for firefox

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

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Red Hat Enterprise Linux 7
Classification:	Red Hat
Component:	firefox
Sub Component:
Version:	7.1
Hardware:	All
OS:	Linux
Priority:	medium
Severity:	medium
Target Milestone:	rc
Target Release:	---
Assignee:	Jan Horak
QA Contact:	Desktop QE
Docs Contact:
URL:
Whiteboard:
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)
CC List:	18 users (show)
Fixed In Version:
Doc Type:	Bug Fix
Doc Text:
Clone Of:	643954
Environment:
Last Closed:	2015-01-13 23:19:18 UTC
Target Upstream Version:
Embargoed:

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
View All

Links
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.

https://rhn.redhat.com/errata/RHSA-2015-0046.html

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 :

696 NS_IMETHODIMP
697 nsEditorSpellCheck::UpdateCurrentDictionary(nsIEditorSpellCheckCallback* aCallback)
698 {
699   nsresult rv;
700 
701   nsRefPtr<nsEditorSpellCheck> kungFuDeathGrip = this;
702 
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   }
714   NS_ENSURE_TRUE(rootContent, NS_ERROR_FAILURE);
715 
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);
722 
723   rv = fetcher->Fetch(mEditor);
724   NS_ENSURE_SUCCESS(rv, rv);
725 
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));
832 
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?

thanks
Laura

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.