1234584 - We get disconnected from the system clipboard after a content process crash

Status: RESOLVED WORKSFORME

(Core :: Widget: Cocoa, defect, P4)

Description

[(no longer active)]

I'm seeing this on OS X 10.11.2, not sure how platform specific it is.

STR:
1. Copy something from outside of Firefox, like "foo".
2. Paste in a webpage.  See "foo" getting pasted.
3. Kill the content process, or get it to crash.
4. Reload the webpage to get a new content process.
5. Paste in a webpage.  See "foo" getting pasted.
6. copy something else from outside of Firefox, like "bar".
7. Paste in a webpage.  See "foo" getting pasted!
8. Copy something from inside Firefox, such as "baz".
9. Paste in a webpage.  See "baz" getting pasted.
10. Paste outside of Firefox.  See "bar" getting pasted!

Steps 7 and 10 demonstrate how at this stage we're completely detached from the system clipboard, and cannot transfer any information on the clipboard across Firefox and other apps.

Comment 1

[Blake Kaplan (:mrbkap) (inactive)]

I've tried this both in a debug Nightly and my normal Nightly without reproducing it (the clipboards stayed in sync through the crash). I tried both on OS X 10.11.1 and 10.11.2.

It might matter what type of element you're pasting into (contenteditable/textarea) and the source of the copy (is it rich text, regular text, are there images, etc.). Also, is it possible that you have an extension or some sort of clipboard manager that could be getting confused by the content process dying? Were you pasting into a specific website that might be overriding copy/paste?

I was copying out of my terminal and into a textarea (though I just tried a contenteditable div and vim, which worked).

Comment 2

[(no longer active)]

Huh...  I don't have any clipboard related extensions, and the test page I used was bugzilla (through copying comments and pasting in the comment field.)  But now that I tried again, I can't reproduce any more either.  :/

Comment 3

[Blake Kaplan (:mrbkap) (inactive)]

Resolving WFM.

Comment 4

[(no longer active)]

FWIW I have seen this issue quite a bit, there is definitely a bug here, even though if the STR in comment 0 is not the right one.

Comment 5

[Blake Kaplan (:mrbkap) (inactive)]

I'll reopen this, but I don't have any real theories. It might be useful to specify what "not Firefox" apps you're using, since that could affect things.

We do have a cache in the parent process to avoid the OSX "pasteboard" if we were the last process to set something [1]. It's based on the "changeCount", which I guess could get out of whack. I will note that we don't actually do anything special for e10s in terms of caching (we always hit the parent process), so I wonder if crashing the content process is necessary...

[1] https://dxr.mozilla.org/mozilla-central/rev/c690c50b2b543b420803e8192d6e08e06b20e0a3/widget/cocoa/nsClipboard.mm#286

Comment 6

[(no longer active)]

(In reply to Blake Kaplan (:mrbkap) (please use needinfo!) from comment #5)
> I'll reopen this, but I don't have any real theories. It might be useful to
> specify what "not Firefox" apps you're using, since that could affect things.

Definitely iTerm, perhaps among others.

> We do have a cache in the parent process to avoid the OSX "pasteboard" if we
> were the last process to set something [1]. It's based on the "changeCount",
> which I guess could get out of whack. I will note that we don't actually do
> anything special for e10s in terms of caching (we always hit the parent
> process), so I wonder if crashing the content process is necessary...

Hmm, it seems that mChangeCount is compared against the value we get from the OS, so that shouldn't be the issue.  Also that cache seems to only exist for reading clipboard data, not writing to it...

Comment 7

[Blake Kaplan (:mrbkap) (inactive)]

Markus, do you have any ideas of where to start looking here or anyone else who'd have any ideas?

Comment 8

[Markus Stange [:mstange]]

I'm afraid not :-(

I doubt we can do much here without reliable steps to reproduce.

Comment 9

[Jeff Griffiths (:canuckistani) (:⚡︎)]

I can't repro. I don't think this should block anything unless we get a reliable repro. Is it possible the exact type of crash has any affect?

Comment 10

[(no longer active)]

I was just killing plugin-container.  But this bug is so surprising that I guess anything is _possible_.

Comment 11

[Jeff Griffiths (:canuckistani) (:⚡︎)]

(In reply to :Ehsan Akhgari from comment #10)
> I was just killing plugin-container.  But this bug is so surprising that I
> guess anything is _possible_.

I don't understand, you initially said:

> 3. Kill the content process, or get it to crash.

Is it the content process or a flash plugin container process?

Comment 12

[Blake Kaplan (:mrbkap) (inactive)]

(In reply to Jeff Griffiths (:canuckistani) (:⚡︎) from comment #11)
> Is it the content process or a flash plugin container process?

The content process's executable is also called plugin-container.

Comment 13

[Jeff Griffiths (:canuckistani) (:⚡︎)]

(In reply to Blake Kaplan (:mrbkap) (please use needinfo!) from comment #12)
> (In reply to Jeff Griffiths (:canuckistani) (:⚡︎) from comment #11)
> > Is it the content process or a flash plugin container process?
> 
> The content process's executable is also called plugin-container.

Ah, didn't realize that - makes sense now, thanks.

Comment 14

[ovidiu boca[:Ovidiu]]

Build ID 20160209004008
User Agent Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:46.0) Gecko/20100101 Firefox/46.0


I have tested this on Mac OS X 10.11 with Firefox 46.0a2 and I can't reproduce it.

Comment 15

[Blake Kaplan (:mrbkap) (inactive)]

I'm calling this WFM at this point.