1925365 - Spelling suggestions on right-click no longer working for plain text composition (HTML composition is ok)

Status: RESOLVED FIXED

(Thunderbird :: Message Compose Window, defect, P2)

Description

[macuc]

Attachment: no_shpeling_suggestions.png

Steps to reproduce:

TB v132.0b5

• Enable Enable spell checking as you type in Composition settings.
• Click New Message and type some content with spelling errors.
• Note that words with spelling errors display a squiggly red underline under them.
• Right-click on a misspelled word.

Actual results:

• Context menu for misspelled words does not show spelling suggestions.

Expected results:

• Spelling suggestions should be displayed in the context menu, like it used to.

Note: Clicking the Spelling button in the new message header does work normally. So this does not seem to be a problem with the basic functions of spelling dictionary, or finding and replacing misspelled words.

Comment 1

[Magnus Melin [:mkmelin]]

Seems to work for me (on linux/daily)

Comment 2

[macuc]

Attachment: Working with HTML composition

Spelling suggestions work when Compose message in HTML format is enabled on the account setting.

Comment 3

[macuc]

Attachment: Plain-Text not working

Not working when Compose message as HTML is disabled in account settings.

Comment 4

[Magnus Melin [:mkmelin]]

If you have the default html composition you can shift click "New message" to get plain text composition.
I do see that yes.

Comment 5

[Alice0775 White]

Regression window:
https://hg.mozilla.org/comm-central/pushloghtml?fromchange=d7a05df28f55acb954447c16f17af3cd5ca4dc5f&tochange=be902fc717335037fa91d7a400339f645a057554
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f4f1159d250a769d457738a3c8a63fe9922714ea&tochange=a021c885397e096d8bc0dd6574dc4c9873be6f99

Suspect:
91c94dc113f8b8cc460f73fabf2cb59d8d919b94 Emilio Cobos Álvarez — Bug 1920118 - Unship -moz-user-modify. r=dholbert
4ef7651b6fb98f41908a4f33905206a88384bb5c Emilio Cobos Álvarez — Bug 1920118 - Don't look at -moz-user-modify in InlineSpellChecker. r=Gijs

OR

0f470e1a67afe6044b03ba5c8dd92daa3037de8a Masayuki Nakano — Bug 1919927 - Implement contenteditable="plaintext-only" in the DOM module r=smaug

Tentatively, mark Bug 1920118 as regressor.

Comment 7

[Alfred Peters [:infofrommozilla]]

I can confirm the bug for self-written text.
For quotes, however, the spelling correction works without any problems.
Even if I inject a simple P-node into the DOM tree with the help of the Inspector, the correction also works there.

I can further confirm that removing D222983 and D222984 fixes the bug. However, removing D222983 alone is not enough.

Nevertheless, this is where the problem arises: D222983

	            editingSession.windowIsEditable(win) &&
--	            this.getComputedStyle(element, "-moz-user-modify") == "read-write"
++	            element.matches(":read-write")
	          ) {
	            isSpellcheckable = true;
	          }

Both variants fail if the text is directly below the BODY tag.
This means that if element=“BODY”, the read-write property is not found and isSpellcheckable therefore remains false.

Comment 8

[Alfred Peters [:infofrommozilla]]

Attachment: Screenshot 2024-11-17 151954.png

The reason for this can now be found in the DOM tree again.

Above the state without D222984. Below with D222984.

In both cases, the property -moz-user-modify: read-write is present, but is deactivated with D222984.

However, I don't understand why D222984 deactivates the property.

Comment 9

[Magnus Melin [:mkmelin]]

Emilio, any insights?

Comment 10

[Emilio Cobos Álvarez [:emilio]]

so it seems that the <editor>s document is in designMode (document.designMode == "on"), but somehow the elements aren't :read-write.

That seems like a bug. If I do document.designMode = "off", then document.designMode = "on" again, then the spellcheck suggestions start working.

Do you know what controls the editing session here? Do you manually set designMode = "on" or does Gecko code somehow do it magically?

Comment 11

[Emilio Cobos Álvarez [:emilio]]

Ah it might be this?

Comment 12

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 1925365 - Simplify nsINode::IsInDesignMode. r=masayuki

We know that the document has the flag because we've set it above, and a
document is always in the uncomposed doc.

No behavior change.

Comment 13

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 1925365 - Make sure editable flag and element state remain in sync. r=masayuki

Some nsEditingSession callers didn't update element state, incorrectly.

No behavior change on Firefox.

Comment 14

[Emilio Cobos Álvarez [:emilio]]

Can you check that the attached patch fixes it on your end?

Comment 15

[Alfred Peters [:infofrommozilla]]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #14)

Can you check that the attached patch fixes it on your end?

Yes, with the patches the spelling correction in the context menu works again.

Comment 16

[Magnus Melin [:mkmelin]]

I can also confirm with the patches it seems to be working, thanks!

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/bce14f8fc2f6
Simplify nsINode::IsInDesignMode. r=masayuki
https://hg.mozilla.org/integration/autoland/rev/fd53bfd242de
Make sure editable flag and element state remain in sync. r=masayuki

Comment 18

[amarc]

https://hg.mozilla.org/mozilla-central/rev/bce14f8fc2f6
https://hg.mozilla.org/mozilla-central/rev/fd53bfd242de