If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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




17 years ago
14 years ago


(Reporter: Jesse Ruderman, Assigned: Mike Pinkerton (not reading bugmail))



Windows 98

Firefox Tracking Flags

(Not tracked)




17 years ago
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

Nothing is pasted.

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.


17 years ago
Keywords: dataloss

Comment 1

17 years ago
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

cc'ing rod, he may have an opinion and taking this bug. it's mine.
Assignee: trudelle → pinkerton
Target Milestone: --- → mozilla0.9

Comment 2

17 years ago
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

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

Comment 4

17 years ago
(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

17 years ago
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

17 years ago
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

17 years ago
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

17 years ago
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

17 years ago
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"].


17 years ago
Keywords: crash


17 years ago
Keywords: crash

Comment 10

17 years ago
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*
Last Resolved: 17 years ago
Resolution: --- → INVALID

Comment 11

17 years ago
invalids, wontfixes, dups, worksformes

Comment 12

14 years ago
"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

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.
You need to log in before you can comment on or make changes to this bug.