I see that WebViewImpl::spellingMarkers skips remote frames, but code should be deleted soon, by https://codereview.chromium.org/2177023002 (and so, should not be a concern for OOPIFs).

It prevents other cleanups too though: the code in question is in https://codereview.chromium.org/2012823003/diff/160001/chrome/renderer/spellchecker/spellcheck_provider.cc, which is in the embedder.

I'm somewhat confused by this "blocking" bug, because WebRemoteFrameImpl::removeSpellingMarkers doesn't even exist any more?

Now (Chrome 56) OOPIF enabled for extensions. As result, part of my extension lost spell checking... :(

Comment 11: What's the extension?  We'll try to investigate.

(groby@, are you aware of spell check issues in OOPIFs that still exist?  It was unclear to me after comment 9.)

I can confirm that the red underline is not showing up in OOPIFs.  groby@, can you help find an owner or let us know where to start looking to fix it?

General repro steps:
1) Start Chrome with --site-per-process.
2) Visit http://csreis.github.io/tests/cross-site-iframe-simple.html
   (Chrome's task manager should confirm that you have an OOPIF at this point.)
3) Type "mispeled" into the first text box and hit space.

There's no red underline, and there aren't suggestions in the context menu.

groby@ is OOO, I think. Assigning to xiaochengh@, who's being reworking a lot of spellcheck code in Blink lately.

In #13's test case, everything in the OOPIF renderer process looks fine: it successfully generates a SpellCheckHostMsg_CallSpellingService and sends it via IPC.

However, the browser process doesn't receive it. The same message from the main frame can be received, though.

Ooh, who handles the IPC?  Is it sent via RenderView{Host}?  If so, it might be getting filtered out and we can add an exception in swapped_out_messages.cc.

The issue is that SpellCheckProvider is a RenderViewObserver and it should be a RenderFrameObserver. For subframes, which are in a different process from the main frame, the routing of IPC messages using the RenderView routing id will fail and they will not be delivered to the browser process.

Let me know if you want more guidance on how to refactor the code to be based on RenderFrame instead of RenderView.

Thanks for your analysis, Nasko.

Sorry I didn't investigate thoroughly in #15. As you analyzed, the message got canceled in the renderer process in RenderWidget::Send:

bool RenderWidget::Send(IPC::Message* message) {
  // Don't send any messages after the browser has told us to close, and filter
  // most outgoing messages while swapped out.
  if ((is_swapped_out_ &&
       !SwappedOutMessages::CanSendWhileSwappedOut(message)) ||
      closing_) {
    delete message;
    return false;
  }
...

Let me have a try to fix this.

I'm going to move to  issue 638361 , since this one is the meta bug.

Please assign this issue back to an appropriate owner in the OOPIF team.

xiaochengh@: I'm hopeful that  issue 638361  is all that's need to close this, but I'll sign up to keep an eye on it.  Once  issue 638361  is done, we can revisit if there's anything else to do.  Thanks!

(Ah, I see the other blocking bugs now.   Issue 638356  sounds like it might not be a problem, though, and  issue 642795  does sound a lot like it would be resolved by moving to a RenderFrameObserver.  So maybe  issue 638361  will be sufficient.)

Any idea when this fix will be live? Our customers are hurting in the meantime via our chrome extension: https://chrome.google.com/webstore/detail/outreach-everywhere/chmpifjjfpeodjljjadlobceoiflhdid?hl=en

Our Chrome Extension injects our app into a sidebar on the page, via an iframe. Users type up emails within the sidebar, and spellchecking is crucial for this.

#22: I'll fix  issue 638361 , which is the main cause, by M59.

So if there is no other cause, OOPIF spellchecking should work in M59.

Fantastic, thanks #23

Spellcheck panel is still broken in OOPIF...

I guess that's the only remaining issue?

 Issue 712395  was fixed on Jun 16th and seems to have been the last remaining spellchecking problem with OOPIFs. Can this bug be closed now?

Sounds like issue 733880 is the last issue here.  noel@, are you able to resolve that one?  We've been using OOPIFs for web iframes in extensions since March and for <webview>s since M61, and there are more uses coming.  Thanks!

@29 nope, better to assign to a person who works on spell checking I think.

xiaochengh@: Can you help find an owner for issue 733880?  Just trying to wrap up this work.  Thanks!

Another thing I noticed:  issue 712395  had repro steps which I used to investigate and fix that bug.

Those repro steps no longer work for me on my MacOSX dev release chrome [1].  Also, the OSX spelling panel does not appear when I select it from Chrome's Edit menu.  

Anyone else confirm?  If so, looks to me like there has been a regression sometime after Jun 16th (when  issue 712395  landed).

[1] Version 64.0.3253.3 (Official Build) dev (64-bit)

I can confirm that OSX spelling panel doesn't appear. Tested on both M64 Canary (64.0.3260.0) and also M61 Stable (61.0.3163.100)...

Seems that something went wrong right after the fix on Jun 16th?

Thanks for the confirm, and was certainly working for me on Jun 16th with or without the --site-per-process flag.  Filing a bug about this regression now ...

Filed  issue 781968  for it.

With some other issues (781971, 789273), issue 733880 once again becomes the only blocking issue.

How much do we prioritize it, or how much does it block the launch?

Does the visibility tracking actually block OOPIF work? (FWIW, you can probably fix this by simply making the panel browser-global instead of constraining it to a frame)

Just tested the spellcheck panel behavior on Mac. Doesn't seem to be that broken :)

Using the steps in crbug.com/733880#c2:

⌘+; (find next misspelling) works fine, regardless of how many frames (including OOPIFs) the page has.

⌘+: (show spelling panel) seems slightly problematic. If you focus one input field, press ⌘+: to show the menu, then focus another input field and press ⌘+: again, the menu is not immediately dismissed -- you have to press ⌘+: for another time to dismiss it.

And it does't matter if the two input fields are in the same origin or not.

And that's it. Having to press ⌘+: for one more time doesn't seem too bothering.

So I don't think it blocks OOPIF.

I believe crbug.com/733880 no longer blocks OOPIF.

Please close this issue and remove 733880 from blockers if you think so, or let me know if there's any other remaining issue.

Thanks!