User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:33.0) Gecko/20100101 Firefox/33.0 Build ID: 20141030112145 Steps to reproduce: This is in SeaMonkey 2.30 on Mac OS X 10.10 Yosemite, and on Windows 7, both OSes with updates current as of 2014-11-12. I created a new page in Composer (File > New > Composer Page), entered some text, and saved it as index.html. Spelling was being checked as I typed, and I attempted to turn it off. I tried turning it off using the "Check Spelling" checkbox menu item in the right-click context menu on the editor's main text area, and the "Spellcheck as you type" checkbox menu item under the Edit menu. Neither worked. Actual results: The spelling checker remained on, and words continued to be underlined in red in the Normal, HTML Tags, Source, and Preview views. The check mark remained on the "Check Spelling" menu item in the context menu. On Windows, the Edit > "Spellcheck as you type" menu item was sometimes enabled and sometimes not. (I can't determine the conditions that let it be enabled.) When it was enabled, clicking it would toggle whether it had a check mark next to it or not, but would have no effect on the behavior of the spell checker. When it was disabled, it would not have a check mark, and could not be selected. On Mac, each time I tried it, the Edit > "Spellcheck as you type" menu item was disabled (greyed out and could not be selected) and had no check mark. Expected results: Initially, I would expect the state of context menu > "Check Spelling" and Edit > "Spellcheck as you type" to be identical in terms of being enabled and presence of a check mark next to it. And I would expect them to be enabled. When clicking either of those menu items when in a currently selected state, I would expect it to toggle the state of the spelling checker, so spelling is no longer checked in the Composer component and all the red underlines disappear, and the check marks to disappear from both menu items. When clicking either of the menu items while they're unchecked, I would expect it to enable the spelling checker.
Probably a number of issues here. Spell check toggle is ineffectual. Don't know if this applies? > Error: TypeError: aWindow is undefined > Source File: resource://gre/modules/InlineSpellChecker.jsm > Line: 317 317: > let chromeFlags = aWindow.QueryInterface(Ci.nsIInterfaceRequestor). That looks to be a regression? Then the fact that (on older SeaMonkey's) when Spell Check was disabled, it still proceeded to spell check the <HTML> Source tab. Related, I would think, Bug 722842 - Spell Check checkmark is in opposite state.
http://mxr.mozilla.org/comm-release/source/suite/common/contentAreaContextOverlay.xul?rev=9cf4459806ca#334 I guess we forgot to change: "InlineSpellCheckerUI.toggleEnabled();" to "InlineSpellCheckerUI.toggleEnabled(window);" Bug 1026099 (Gecko 35, SeaMonkey 2.32) removes the need for passing the window object (Bug 1026099 - MozHunspell opens dictionary files in content processes) In the mean time there's SeaMonkey 2.31beta...
Status: UNCONFIRMED → NEW
status-seamonkey2.30: --- → affected
status-seamonkey2.31: --- → affected
status-seamonkey2.32: --- → unaffected
Ever confirmed: true
From: > InlineSpellCheckerUI.toggleEnabled(); To: > InlineSpellCheckerUI.toggleEnabled(window); Manually updating contentAreaContextOverlay.xul in omni.ja does look to work. Spelling is enabled/disabled as wanted, & no longer any Error Console messages. (Spell check is still "enabled" in for '<HTML> Source' tab but I suppose that's a different situation.)
Created attachment 8526620 [details] [diff] [review] Patch v1.0 regression fix for 2.31beta Kwikfix for 2.31b comm-beta.
Assignee: nobody → philip.chee
Status: NEW → ASSIGNED
Attachment #8526620 - Flags: review?(neil)
Ah, so regression from bug 693555.
status-seamonkey2.29: --- → unaffected
Comment on attachment 8526620 [details] [diff] [review] Patch v1.0 regression fix for 2.31beta [Approval Request Comment] Regression caused by (bug #): Bug 693555 User impact if declined: Cannot toggle spellcheck on and off from the contest menu in web composer and (probably) navigator/browser. Testing completed (on m-c, etc.): Manually tested on 2.30 by therube Risk to taking this patch (and alternatives if risky): no risk bustage fix. String changes made by this patch: None.
Comment on attachment 8526620 [details] [diff] [review] Patch v1.0 regression fix for 2.31beta [Triage Comment]
Pushed bustage fix to comm-beta: https://hg.mozilla.org/releases/comm-beta/rev/7d62c1c2f88a
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
status-seamonkey2.30: affected → wontfix
status-seamonkey2.31: affected → fixed
status-seamonkey2.33: --- → unaffected
tracking-seamonkey2.31: --- → +
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.