61257 - crash (or forced quit) causes text copied to clipboard to be lost

Status: VERIFIED INVALID

(Core :: XUL, defect, P3)

Description

[Jesse Ruderman]

Steps to reproduce:
1. Copy 'foo' from a notepad window to the clipboard
2. Run Mozilla with the -console command-line option
3. Copy some text from Mozilla's location bar
4. Force-quit by clicking the 'x' in the Mozilla console window
5. Try to paste into a notepad window

Result:
Nothing is pasted.

Expected:
The text I copied from the location bar is pasted.

Works fine if I paste into notepad, kill Mozilla, and paste again.  The bug 
only affects text copied from Mozilla (so if I don't copy something from 
Mozilla, force-quitting it won't clear the clipboard).

Ccing pinkerton, who fixed related bugs: bug 24260 and bug 49354.

Comment 1

[Mike Pinkerton (not reading bugmail)]

yup. we only flush the data to the clipboard when the app quits. we could flush
every time, but that could be expensive. your call. what do other apps do, in
general?

cc'ing rod, he may have an opinion and taking this bug. it's mine.

Comment 2

[John Morrison]

A highly unrigorous survey:
  Doing copy of "foo" in a text editor (Notepad/win2k and BBEdit/mac), 
  then copy of "bar" in another "App", then killing that "App" and 
  trying a paste back in the text editor:

                      Mac              Win2k          Linux
"App" is            Final paste      Final paste    Final paste 
  MS-Excel            "foo"            "bar"           n/a
  Nav4.x              "bar"            "bar"           ""
  IE                  "bar"            "bar"           n/a
  Wordpad             n/a              ""              n/a
  Mozilla             "bar"            ""              ""
  xterm               "bar"            n/a             ""

The tendency of other apps on win32/mac is towards not losing this 
bit of state, although not unanimously (e.g. Excel on Mac, Wordpad on 
win2k). On linux, I seemed to get nuked in all three apps I tried.   

Comment 3

[John Morrison]

Er, obviously the entry for 'xterm' on Mac should be 'n/a'.
(... until OS X comes out).

Comment 4

[John Morrison]

(Responding to an email): er, good point. "Normal" behaviour (for both forms
of X clipboard) is that the data placed on the clipboard by "App", goes away
when "App" is exited normally.

Comment 5

[rods (gone)]

I really have no opinion other then it should work how users expect it should 
work. I would expect it to be there is I quit.

It what is on the clipboard is huge, sometimes an app asks if you want it to be 
made available for other apps. (Photoshop and you have copied an image).

Comment 6

[Peter Trudelle]

I think this bug is invalid.  Writing the data on normal exit is correct and
sufficient on Mac & Windows. We shouldn't waste time writing the data before we
need to just because the app might crash. When that happens, the crash is the
problem, not the clipboard. Whether we have the same policy on Linux, or whether
we first ask permission, are separate policy questions, outside the scope of
this bug. 

Comment 7

[Jesse Ruderman]

I have a habit of copying important text to the clipboard just before doing 
something that might cause me to crash IE or accidentally close/"reuse" the 
window, so I'd probably run into this at least a few times if I started using 
Mozilla as my main browser.  I don't know how many other users do that.

Most of the time (on Windows), a copy is followed quickly by a paste, so is it 
really a waste of time or memory to put the text on the clipboard right away?  
(Maybe it is; I'm not familiar with how this stuff works.)

Comment 8

[Mike Pinkerton (not reading bugmail)]

now that you mention it, i do the same thing.

this would be fairly trivial to implement (it's a one-liner, i think). if i put
in a patch, would people be willing to help me run a bunch of performance tests
to see if it would be a problem?

Comment 9

[John Morrison]

Sure, he says (not knowing how one would actually measure this). 

[One point of clarification: when I said above that I "killed" the application,
I mean that I use the OS to terminate the process unexpectedly. When doing
a normal exit (with File->Quit, or a close "X" control, I don't believe we
ever lose the selection [except on Linux where that is, afaict, the "norm"].

Comment 10

[Mike Pinkerton (not reading bugmail)]

I'm torn. the api's are setup to put a proxy object on the clipboard which
defers taking up memory until the data is actually needed by another app. books
are written about how to do this with OLE. None of these books ever talk about
what happens when your app crashes, and the assumption i guess is that you just
lose the data. i'm a little suprised that excel on win32 preserves the clipboard. 

i'm going to mark this invalid...*shrug*

Comment 11

[Chad Austin]

invalids, wontfixes, dups, worksformes

Comment 12

[Jesse Ruderman]

http://www.blogger.com/news_archive.pyra?which=2001_02_01_news_archive.xml#2206742
"The best way to keep from losing data, is to copy your post to your clipboard
before hitting the post button. While in the posting form, you can do this in
Windows with two quick keystrokes -- ctrl+A, ctrl+C.... I do this for all web
applications where I'm entering a lot of data, because by nature, they are
precarious."

Also, this bug hurts perceived performance / UI efficiency.  When I copy
something, I don't expect anything to happen visually, so it's ok if it takes
half a second.  But when I paste something, I expect it to appear immediately.