Bug 4990 – WebKit needs to use a local pasteboard during testing

• Component: Tools / Tests
• Status: RESOLVED FIXED

[Eric Seidel (no email)]

WebKit needs to use a local pasteboard during testing

Currently WebKit always uses the "generic" pasteboard for copy/paste, etc.  This causes problems during 
testing because you are unable to safely use the pasteboard while runing run-webkit-tests for fear of 
causings test failures.  There are also situations underwhich SSH sessions will not properly connect to the 
pasteboard server (pbs) and thus cause editing tests to fail.

This could be a secret default which turned on various "debug only" behaviors in WebKit, or a single 
default just for disabling using the generic pasteboard.  This would require small changes to both WebKit 
and DumpRenderTree.

[Eric Seidel (no email)]

Dave had expressed interest in this.

[Justin Garcia]

Is it even possible to have a local pasteboard?

[Eric Seidel (no email)]

Sure:

NSPasteBoard *myLocalPasteBoard = [[NSPasteBoard alloc] init];

[Justin Garcia]

Boy don't I feel silly.  We should do this right away.

[Darin Adler]

I tried. [[NSPasteBoard alloc] init] does not work.

But you can have a pasteboard not shared with any other process. I'll attach my patch.

[Darin Adler]

Created attachment 5141 [details]
use a pasteboard with a unique name; next best thing to a local pasteboard

We discussed using a local pasteboard, but as far as I can tell there's no such
thing. I tried [[NSPasteboard alloc] init] and discovered that alloc is
overriden to indicate you can't allocate your own NSPasteboard.

[Justin Garcia]

Darin, didn't you mention that this change required some changes to updateLayout calls in the editing 
code?  Are those attached to a different bug?

[Eric Seidel (no email)]

Comment on attachment 5141 [details]
use a pasteboard with a unique name; next best thing to a local pasteboard

I'm not familiar with that pose-as syntax, but the change looks totally fine. 
r=me.

[Darin Adler]

(In reply to comment #7)
> Darin, didn't you mention that this change required some changes to updateLayout calls
> in the editing code? Are those attached to a different bug?

I'm not certain of the relationship between this change and the failures I was seeing.

The bug is bug 6142, but it seems likely it was just coincidence that I first saw those failures after 
applying this patch.

[Darin Adler]

(In reply to comment #8)
> I'm not familiar with that pose-as syntax

This is the low-level poseAs. There's also a higher level poseAs in NSObject, but there's no strong 
argument in favor of using that one over this. Historically in Safari it was important to use this one instead 
of the one that involved Objective-C method calls but I can't remember why. Here I was just using it 
because I had the code from Safari to copy and paste.