Closed
Bug 940619
Opened 11 years ago
Closed 9 years ago
Spellchecker should respect @lang on contenteditable elements
Categories
(Core :: Spelling checker, defect)
Tracking
()
RESOLVED
FIXED
mozilla43
People
(Reporter: accounts+bugzilla.mozilla.org, Unassigned)
References
Details
(Whiteboard: [bugday-20131125])
Attachments
(2 files)
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.
|
||
Updated•11 years ago
|
Component: Untriaged → Spelling checker
Product: Firefox → Core
Whiteboard: [bugday-20131125]
|
||
Comment 1•11 years ago
|
||
Bug 338427 implemented this for the root editable element. Extending this to any arbitrary element is probably going to be more work...
Blocks: 338427
|
|
||
Updated•11 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
|
Reporter | |
Comment 2•11 years ago
|
||
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).
|
|
||
Comment 3•11 years ago
|
||
(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.
|
|
Reporter | |
Comment 4•11 years ago
|
||
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.
|
||
Comment 5•11 years ago
|
||
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).
|
|
||
Comment 6•11 years ago
|
||
(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)?
|
|
Reporter | |
Comment 7•11 years ago
|
||
@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.
|
||
Comment 8•9 years ago
|
||
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.
Description
•