1176716 - "Spelling" button should not be disabled when contacts side bar has focus

Status: RESOLVED FIXED

(Thunderbird :: Message Compose Window, defect)

Description

[Thomas D. (:thomas8)]

+++ This bug was initially created as a clone of Bug #368915 +++

STR

1 compose new msg, with contacts side bar shown (F9)
2 focus msg body and observe spelling dual button
3 focus contacts side bar and observe spelling dual button vs. all other buttons on composition toolbar

actual

Spelling button is the only message-related button which is disabled when contacts side bar has focus; other buttons like Send, Attach, Security or Save are still enabled.

expected

Spelling dual button should never be disabled, not even when there's no text in msg body or subject (because user can still select language or edit dictionary entries). Like all the other message-related buttons which are not disabled.

Comment 1

[Jorg K (CEST = GMT+2)]

In bug 368915 we are contemplating a two-button solution, so that the "Spelling" button would be context sensitive, the "Language" button would always be enabled. Why don't we wait for a decision before raising more bugs?

If we don't implement two buttons and make the one button always available, this bug here is also superfluous.

I really do not understand why we need this bug, since independently of the decision taken, the other bug covers this one 100%.

IMHO you're just delivering another argument why spelling and language choice should not be combined into the same UI element. You wrote: "The spelling button should never be disabled". In fact, it should be disabled exactly when no full spell check is available.

Comment 2

[Thomas D. (:thomas8)]

(In reply to Jorg K from comment #1)
> In bug 368915 we are contemplating a two-button solution, so that the
> "Spelling" button would be context sensitive, the "Language" button would
> always be enabled. Why don't we wait for a decision before raising more bugs?
> If we don't implement two buttons and make the one button always available,
> this bug here is also superfluous.

Bug 368915 per current summary (Selection of spell check dictionaries disabled in *subject* line) does NOT cover enabling the current dual spell button for *contacts side bar*. If context-independent enabling came as a by-product of that bug, it's easy to just resolve this bug as fixed by the other one.
 
> IMHO you're just delivering another argument why spelling and language
> choice should not be combined into the same UI element. You wrote: "The
> spelling button should never be disabled". In fact, it should be disabled
> exactly when no full spell check is available.

As Magnus has already commented, there's no problem if user deliberately triggers a dialogue spell-check on empty document. The dialog will come up and just say: "No misspelled words". Click close, done. If user wants to explore spellcheck functionality that way, why not? We should actually encourage exploring advanced UI. For those who don't want to spell-check empty documents, it's also fine. We're not forcing you to click the button at this stage, and you'll probably not even try it because, well, the document is empty.

But the main argument in favor of always enabling even the dedicated "Spelling"-only button in the two-button scenario is what I hinted at the end of comment 0: Please have a close look at the spell-check dialogue. There's a lot more than just spell-checking. There's a full dictionary administration including options to edit existing entries and add new entries to custom dictionary. So this is one scenario in favor of "always enable": If user prefers to add or edit some custom words to his dictionaries *before* writing the message, then why should we prevent that by disabling the spell-check dialogue without need or benefit?

Comment 3

[Thomas D. (:thomas8)]

By analogy, we don't disable "Advanced Search" dialogue for empty folders even though there's nothing to search; which has the benefit of allowing user to explore the function AND there's also "Save as Search Folder" function inside the dialogue, so we're also enabling the user to create and save a "Saved Search" at any time when he so pleases.

Comment 4

[Jorg K (CEST = GMT+2)]

Fixed as part of bug 368915.