354580 - Add "Ignore word" to inline spellchecker used for editable elements

Status: RESOLVED FIXED

(Core :: Spelling checker, enhancement)

Description

[Ian Neal]

Currently there is not an "Ignore word" for the inline spellchecker used in editable elements on web pages.

Comment 1

[Ian Neal]

Attachment: Ignore word patch

This patch:
* Adds an "Ignore word" menu item to the context menu.
* Adds a separator between suggestions and "Add to dictionary" item.

Comment 2

[Ian Neal]

Just noticed that "Add to dictionary" accesskey "t" clashes with "Cut", is it worth respining this patch with a change of accesskey to "o"?

Comment 3

[Brett Wilson]

I deliberately did not add this capability, and I still would lobby for its non-inclusion. I don't think it is useful, and I think it clutters the already very long and complicated menu.

Why would somebody use ignore word instead of add to dictionary? If they use a word commonly they should add it to the dictionary.

Ignore All is only important for unusual words that appear in the current document only, but are not generally common so the user doesn't want them to be in the main dictionary.

Web forms are by nature very time limited. There is no opening the document later to work on it some more, for example, where a word processor would gain from the feature. The usefulness of this command is at most several minutes. Misspellings are easy to ignore because the contextual spellchecker isn't modal (another possibly important use case for Ignore All). The only reason to have a command that disables an easily ignorable thing for only a few minutes is for OCD.

Does a typical user understand the difference between ignore all and add to dictionary? Perhaps (and I actually question this) in the context of a word processor most users do, but I think the answer starts getting extremely muddled for these very short lived "documents." What does this affect? All fields on this page? Every time you view the page?

I think this menu item would do much more harm than good.

Comment 4

[Ian Neal]

A few points:
1) You seem to be ignoring midas-like editable web pages where ignore word is useful.
2) In web forms with comment fields (like bugzilla) you might end up writing quite long pieces (like your one) where being able to ignore a word for just that form is again useful.
3) In the future TB and mailnews might be needing to tap into your implementation and also Editor/Composer could do the same.

One option is to not do the /browser changes (though fix the accesskey conflict) but leave the other changes in.

Comment 5

[Brett Wilson]

(In reply to comment #4)
> 1) You seem to be ignoring midas-like editable web pages where ignore word is
> useful.
> 2) In web forms with comment fields (like bugzilla) you might end up writing
> quite long pieces (like your one) where being able to ignore a word for just
> that form is again useful.

I think my comments about the time limited nature apply to these cases as well.

> One option is to not do the /browser changes (though fix the accesskey
> conflict) but leave the other changes in.

I'm fine with that, the suite people can do whatever they want, and I can see it might be useful in some cases.

Comment 6

[Ben Goodger (use ben at mozilla dot org for email)]

If I exhibited OCD over this, I would find the context menu annoying since the squiggly underline would show up all the time, and each time I'd have to right click and choose an option to get rid of it. Cumbersome! 

In that case I'd much rather a little button popped up around the text field that let me ignore, and when I clicked it it'd ignore and then disappear, leaving the screen clean! Only to return on the next misspelling. 

Comment 7

[Brett Wilson]

(In reply to comment #6)
> In that case I'd much rather a little button popped up around the text field
> that let me ignore, and when I clicked it it'd ignore and then disappear,
> leaving the screen clean! Only to return on the next misspelling. 

But what if you don't notice the button and you accidentally left misspelled words highlighted on the screen. If you noticed them later, you might be so mad that you wanted to switch back IE. So I propose this button be large and pulsing, and also emit a "ee-ee-ee-ee-ee" noise like Alf did when he wanted to be annoying.

Oh, Alf, where are you now?

Comment 8

[Ian Neal]

Attachment: No browser ignore word but with accesskey fix patch v0.1a (Checked into trunk)

Changes since v0.1:
* Removed "Ignore word" for browser
* Added change of accesskey for "Add to dictionary" to avoid clashing with "Cut"

Carrying forward r=

Comment 9

[Scott MacGregor]

Comment on attachment 240674 [details] [diff] [review]
No browser ignore word but with accesskey fix patch v0.1a (Checked into trunk)

I'm not a reviewer for browser so make sure one of those guys is ok with the access key change.

sr=me for the suite changes.

Comment 10

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 240674 [details] [diff] [review]
No browser ignore word but with accesskey fix patch v0.1a (Checked into trunk)

r=me on the /browser accesskey change.

Comment 11

[Ian Neal]

Comment on attachment 240674 [details] [diff] [review]
No browser ignore word but with accesskey fix patch v0.1a (Checked into trunk)

Checking in (trunk)
browser/locales/en-US/chrome/browser/browser.dtd;
new revision: 1.54; previous revision: 1.53
suite/common/contentAreaContextOverlay.xul;
new revision: 1.62; previous revision: 1.61
suite/common/nsContextMenu.js;
new revision: 1.117; previous revision: 1.116
suite/locales/en-US/chrome/common/contentAreaCommands.dtd;
new revision: 1.33; previous revision: 1.32
toolkit/content/inlineSpellCheckUI.js;
new revision: 1.9; previous revision: 1.8
done

Comment 12

[Phil Ringnalda (:philor)]

*** Bug 364769 has been marked as a duplicate of this bug. ***