I captured IPC dump via chrome://tracing and I see the following 2, spellchecking-related messages:

SpellCheckHostMsg_CallSpellingService
SpellCheckMsg_RespondSpellingService

I see that SpellCheckHostMsg_CallSpellingService is sent via RenderViewObserver::Send and I am guessing that this message is dropped if RenderView is swapped out.

So - I guess that this issue might be seen as a special case of  issue 638361 ...

groby@: how would I write an automated test for this?

I can see how I could write either a browser test or a layout test that duplicates the repro steps.  I am not sure how I would verify presence of red squiggles - layout tests would miss them because they don't cover the //chrome layer;  I am not sure if browser tests have support for comparing actual vs expected screenshot (or if such test is consider acceptable [or too fragile] in browser tests land).

piman@, could you please advise on how a browser test could verify presence of red squiggles under misspelled words?  I wonder if this verification can be done at graphics level, but without comparison of whole-window screenshots (which seems rather fragile).  creis@ suggested that maybe the browser test can somehow get a dump of elements in the current render tree.  Alternatively (at least for the spellchecking case) maybe the browser tree can see if the web contents contain some "redness".  WDYT?  How would you approach such test?

PS. I guess the test could intercept and inspect some spellchecking-specific IPC messages, but I dislike how such test would be closely coupled with a particular implementation of spellchecking feature.  I'd love if I could have a test that is independent from the spellchecking implementation details (so that the same test can be expected to work both before and after the redesign needed to add OOPIF support to the spellchecking feature).

Doing pixel tests, even approximate, is going to be way harder than one might think, if only because the asynchronicity of rendering, as well as very fragile. I suspect that looking at the render tree is better (should this be a layout test?). Then again, looking at IPCs seems even better - we have many tests that do that.

Ah, sorry for missing this. 

spellcheck_service_browsertest tests some of the IPC mechanics, but might not be enough for this case. (And yes, we intercept IPC messages)

Spellcheck has the concept of a "FeedbackSender", which reports misspellings. You might be able to hijack this, but IIUC, this is going away soon. Rouslan might know more

Also, for style points, there are two ways to call the browser side - SpellCheckMsg_RespondTextCheck on OSX. (Sorry - they carry different payloads, and security doesn't care for unused parameters, so that's where we are)

And finally, please do not rely on pixel tests for this, because they will break every single time blink touches text rendering. Don't do that to blink or yourself :)

> Spellcheck has the concept of a "FeedbackSender", which reports misspellings. You might be able to hijack this, but IIUC, this is going away soon. Rouslan might know more

Removal of FeedbackSender is imminent. Patch is in review.

Is this issue still relevant?

Given that SpellCheckProvider has been changed into a RenderFrameObserver, and a browser test verifying whether browser receives spellcheck messages is added.

I can no longer repro on 59.0.3071.1 (Official Build) canary SyzyASan (32-bit) (cohort: ASAN).  Thanks for fixing this (I assume it was fixed as part of your work on  issue 638361 ).