Closed Bug 940619 Opened 11 years ago Closed 9 years ago

Spellchecker should respect @lang on contenteditable elements

Categories

(Core :: Spelling checker, defect)

Product:
Core
Component:
Spelling checker
Version:
26 Branch
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla43

People

(Reporter: accounts+bugzilla.mozilla.org, Unassigned)

References

Details

(Whiteboard: [bugday-20131125])

Attachments

(2 files)

firefox-spellchecker-contenteditable.htm
(deleted), text/html
Details
3-textarea test case
(deleted), application/xhtml+xml
Details
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0 (Beta/Release) Build ID: 20131114085019 Steps to reproduce: Please see attache file for test case. I have the en-US and the de-AT dictionaries installed. Actual results: Firefox simply keeps the Spellchecker at the last dictionary that was configured. Expected results: Firefox should respect the @lang attributes that are set on the HTML elements.
Component: Untriaged → Spelling checker
Product: Firefox → Core
Whiteboard: [bugday-20131125]
Bug 338427 implemented this for the root editable element. Extending this to any arbitrary element is probably going to be more work...
Blocks: 338427
Status: UNCONFIRMED → NEW
Ever confirmed: true
Root element would be a great start. Respecting the @lang attribute of the contenteditable element itself seems like the next logical step for me. Respecting every @lang within the element is even in my eyes overkill (it’s included in the test I know, but I was just curious).
(In reply to comment #2) > Root element would be a great start. Respecting the @lang attribute of the > contenteditable element itself seems like the next logical step for me. That should already work. > Respecting every @lang within the element is even in my eyes overkill (itâs > included in the test I know, but I was just curious). Yes, that is what this bug is about.
My Firefox doesn’t respect any @lang attribute (not root, not on the contenteditable element, not within). The spellchecker only works with textarea. Could you check again with the provided test attach above. It works great with input and textarea.
Attached file 3-textarea test case (deleted) —
With this test case Firefox 25 seems to choose the right spellchecker language for the active textarea. But when entering a textarea Firefox performs spell check on all textareas using the language of the active one (instead of using the respective languages specified via @lang on the textareas). On a dynamic page where the textareas are loaded via XMLHTTPRequest (as XML with proper namespace and then imported into the current page) @lang is not being respected at all (need to get it factored out into a small test-case though).
(In reply to comment #4) > My Firefox doesnât respect any @lang attribute (not root, not on the > contenteditable element, not within). The spellchecker only works with > textarea. Could you check again with the provided test attach above. Not even if you set the attribute on the document element (most commonly, the <html> element)?
@Bruno Prémont as I said, it works great on textareas. @Ehsan Akhgari here’s the code from the test case I attached to the bug report: <!doctype html> <html lang="de"> <head> <title>Mozilla Firefox Spellchecker ContentEditable Test Case</title> </head> <body style="background:lightgrey"> <div contenteditable="true" style="min-height:500px;padding:10px;border:1px solid black;background:white"> <p>Deutscher Text in einem <em lang="en">content editable</em> Element.</p> </div> </body> </html> As you can see, the @lang attribute is set on the HTML element and Firefox doesn’t respect it. It simply sticks to the dictionary that is currently set. If I insert a textarea it directly changes the dictionary according to the @lang attribute of the html element.
Spellchecking was reworked in bug 1200533, bug 717433, bug 697981, bug 1205983, bug 1204147 and bug 1193293. The spellchecker honours the lang attributes of text areas or contenteditable, unless a content preference sets a common language for the whole page. See meta-bug 1073827 comment #33 for details. The safest way to remove the content preference is to remove/rename the content-prefs.sqlite from the profile or test with a new profile. The problem reported here is fixed in Firefox 43, some of the bugs mentioned here landed on Firefox 44.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla43
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: