Closed
Bug 311340
Opened 19 years ago
Closed 15 years ago
Clipboard data is lost on exit (Should implement the freedesktop.org specification for clipboard management)
Categories
(Core :: Widget: Gtk, defect)
Tracking
()
RESOLVED
FIXED
mozilla1.9.3a1
People
(Reporter: siimo2005, Assigned: stransky)
References
(Depends on 1 open bug, )
Details
(Keywords: dataloss)
Attachments
(2 files, 5 obsolete files)
15.76 KB,
patch
|
Details | Diff | Splinter Review | |
15.96 KB,
patch
|
christian
:
approval1.9.2.11-
christian
:
approval1.9.2.9-
|
Details | Diff | Splinter Review |
Since gnome desktop that firefox attempts to blend with on linux uses the freedesktop specs for clipboard management, anything copied from firefox is lost when firefox is closed as firefox does not follow these specifications: http://www.freedesktop.org/wiki/Standards_2fclipboards_2dspec in other applications copying something and closing the application does not cause the copied content to be lost (this clipboard manager was implemented in gnome 2.12)
Updated•19 years ago
|
Severity: major → minor
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Should implement the freedesktop.org specification for clipboard management → Should implement the freedesktop.org specification for clipboard management (clipboard data (buffer) is lost when window closed)
Updated•19 years ago
|
Severity: minor → enhancement
Comment 1•19 years ago
|
||
*** Bug 312485 has been marked as a duplicate of this bug. ***
Comment 2•19 years ago
|
||
I'd like to bring this to the attention of the necessary developers so we can get this in - it's annoying having Firefox not interact properly with gnome-clipboard-daemon (or anything else for that matter).
Updated•19 years ago
|
Assignee: nobody → general
Blocks: 233462
Component: General → GFX
Product: Firefox → Core
QA Contact: general → ian
Version: 1.5.0.x Branch → Trunk
Comment 3•18 years ago
|
||
*** Bug 330704 has been marked as a duplicate of this bug. ***
Comment 4•18 years ago
|
||
I'm not sure I follow. We follow the spec at http://standards.freedesktop.org/clipboards-spec/clipboards-0.1.txt just fine -- the Ctrl-c key combination uses CLIPBOARD while mouse-highlight uses PRIMARY. The behavior I observe in Mozilla is the same as the behavior I observe in Gnumeric and the Terminal thing that Fedora Core 4 ships with -- the CLIPBOARD is available until the app quits, but not after that. So as far as I can tell, this bug is invalid -- it's demanding that we implement a specification that we already implement and implying that doing that will change what happens when the browser is shutdown (which looks like an unrelated issue to me). What am I missing?
Comment 5•18 years ago
|
||
The problem from my perspective is that Firefox somehow bypasses gnome-clipboard-daemon which is used for ensuring that CLIPBOARD does exist after the program quits.
Comment 6•18 years ago
|
||
I guess it's a duplicate of Bug 23386. Someone should probably dupe one of these against the other.
Comment 7•18 years ago
|
||
Btw the Summary field of this bug is really invalid. AFAICS, gnome-clipboard-daemon is not a part of the Freedesktop.org specification.
Comment 8•18 years ago
|
||
One last thing (sorry for too many messages). I'm using GNOME and Cutting and Pasting from Gedit (as an example) works even after I quit it. However, I've just checked and I don't see any gnome-clipboard-daemon or -manager banary running or even existing on my system. However I've found out an announcement of GNOME 2.12 [1], which states that that version of GNOME is managing the clipboard in a new, much better, way. It also states that this feature is based on a freedesktop.org specification. The summary of this bug should be changed to something more exact, but I'm not sure about to what. However, the developers of Mozilla may want to look at the list of clipboard-related links in freedesktop.org[2]. [1] http://www.gnome.org/~davyd/gnome-2-12/ [2] http://freedesktop.org/wiki/FindPage?action=titlesearch&value=clipboard
Comment 9•18 years ago
|
||
(one last message for now, I promise). It's the link that is bad, not the summary. Someone please change the link to http://freedesktop.org/wiki/Standards_2fclipboard_2dmanager_2dspec Also, please dupe Bug 23386 against this one.
Comment 10•18 years ago
|
||
could anybody apply the changes listed in my last comment, please?
Comment 11•18 years ago
|
||
*** Bug 23386 has been marked as a duplicate of this bug. ***
Comment 12•18 years ago
|
||
Changing the URL and reassigning the bug to Toolkits/Widgets, as it seems more appropriate to go there.
Assignee: general → jag
Component: GFX → XP Toolkit/Widgets
QA Contact: ian → xptoolkit.widgets
Comment 13•17 years ago
|
||
Anyone know if a freedesktop clipboard fix will be in Firefox 3? Firefox sticks out like a sore thumb due to this issue and makes it look unpolished, even though it ships with many Linux distros. (there are multiple bugs in Ubuntu's Launchpad about this as well, if devs need more info: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/21202 https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/69613 https://bugs.launchpad.net/bugs/81506 https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/90477 )
Comment 14•17 years ago
|
||
I don't think this bug should be considered an RFE anymore. It's much rather a major loss of functionality, IMO.
Severity: enhancement → normal
Comment 15•17 years ago
|
||
Hi, I want to solve this problem whether a bug or not.. Can anybody help me, I want to know where exactly this problem should be delt with. I mean, which file in the source code contains the relevant code.
Comment 16•17 years ago
|
||
Since the URL field leads to a page that doesn't exist, I am pointing it to current location of Clipboard Manager specification: http://freedesktop.org/wiki/Specifications/clipboard-manager-spec Trisha: This bug is not about the Clipboard spec, which as B Zbarsky rightly pointed out, Firefox already implements, but rather the Clipboard *Manager* spec.
Comment 17•16 years ago
|
||
Please fix this. This annoys me a lot. I must use Epiphany or other browser, if you cant fix it.
Comment 18•16 years ago
|
||
This bug is _the_ most annoying bug for Firefox on Ubuntu. I'm hit my this bug at least once every week.
Comment 20•16 years ago
|
||
This bug is getting aged, and it is still not fixed, nor has there been any progress on it. It would be great if this was fixed for Firefox 3.0 final.
Comment 21•16 years ago
|
||
(In reply to comment #20) > This bug is getting aged, and it is still not fixed, nor has there been any > progress on it. It would be great if this was fixed for Firefox 3.0 final. Don't expect it to happen for 3.0, I think it's feature complete already. Let's hope for the next major release.
Updated•16 years ago
|
Assignee: jag → nobody
Comment 23•16 years ago
|
||
When checking what happens to the clipboard content on exit [1], we can see that any xulrunner application clears the clipboard (or sets it to be empty). I hope this can help to pinpoint where the problem lies. [1] eg. when running xclipboard to monitor successive contents, but under an environment that does mess by itself with the clipboard and selection, that is eg. plain fvwm, or kde 3.5 with klipper set not so sync clipboard and selection, and not to forbid empty clipboard
Comment 24•16 years ago
|
||
I was working on some article (in a web-based cms, sadly without autosave or drafts) and decided to save it on a usb pendrive in order to continue later on my friend's machine. So I copied the content, closed firefox, opened my editor... but couldn't paste it :/ The bug's importance should be raised, it causes *data loss* :/ Please, fix this issue.
Updated•16 years ago
|
Keywords: dataloss
Summary: Should implement the freedesktop.org specification for clipboard management (clipboard data (buffer) is lost when window closed) → Clipboard data is lost on exit (Should implement the freedesktop.org specification for clipboard management)
Comment 25•16 years ago
|
||
I completely agree, MATi. Why does it take so long to fix this bug? Why don't the developers see how important this is? It's just ridiculous this still doesn't work. Being able to copy / paste is one the basic features of an application and in my opinion those features have the highest priority to work on. After all those years this basic function still doesn't work in Firefox, but a lot of other features have been added in those years. In my opinion this is a wrong choice. Working on important basic features must have a much higher priority than working on all those features which are nice to have. Fix all those bugs first and introduce new features when those bugs are fixed. This is not only a problem with Firefox. It seems to be a basic problem of open source projects. Looks like open source developers develop an application and keep on adding new features without first fixing existing bugs. I'm thinking about Gnomes Nautilus with its bugged list view (not being able to drag and drop a file into a folder when there are more items than fit on the screen). Please, fix those bugs first and then start adding new features.
Comment 26•15 years ago
|
||
Comment 27•15 years ago
|
||
It seems to work for me, feel free to try, modify, and/or commit it.
Comment 28•15 years ago
|
||
Richard: you need to get the patch reviewed - see https://developer.mozilla.org/en/Getting_your_patch_in_the_tree
Assignee: nobody → ickard
Status: NEW → ASSIGNED
Hardware: x86 → All
Updated•15 years ago
|
Assignee: ickard → nobody
Comment 29•15 years ago
|
||
OK, have read a bit in the review info link, but I don't want to be an assignee or anything atm, just posted a patch that I thought could be useful.
Status: ASSIGNED → NEW
Flags: wanted1.9.2?
Keywords: helpwanted
Whiteboard: Help needed for getting provided patch landed.
Comment 30•15 years ago
|
||
Rickard: I think you may at least want to ask for caillon's review.
Assignee | ||
Comment 31•15 years ago
|
||
Comment on attachment 384458 [details] [diff] [review] Possible clipboard fix Can you please check this patch?
Attachment #384458 -
Flags: review?(caillon)
Assignee | ||
Comment 32•15 years ago
|
||
Comment on attachment 384458 [details] [diff] [review] Possible clipboard fix Karl, can you check this one please?
Attachment #384458 -
Flags: review?(caillon) → review?(mozbugz)
Flags: wanted1.9.2?
Flags: wanted1.9.2-
Flags: blocking1.9.2-
Comment 33•15 years ago
|
||
Comment on attachment 384458 [details] [diff] [review] Possible clipboard fix Thank you, Rickard for submitting the patch. It looks like gtk_clipboard_store() is a suitable function to use, but I don't think we should be using it so often. My reading of http://freedesktop.org/wiki/ClipboardManager is that it is intended that the app should only ask the clipboard manager to save the clipboard when the app is about to exit. I think the following clauses imply this: "If a client needs to exit while owning the CLIPBOARD selection, it should request the clipboard manager to take over the ownership of the clipboard, using the SAVE_TARGETS mechanism." "the clipboard owner will quit upon receiving the SelectionNotify" It looks like gtk_clipboard_store() passes ownership to the clipboard manager immediately, and I don't think we want to do this every time nsClipboard::SetData is called with new data for the CLIPBOARD. Saving the clipboard involves converting the data (possibly of significant size) to a number of different target formats and transferring each of these (possibly across a network) to the manager. The clipboard manager may even prompt to check whether the user really wants to do this. (The spec says "possibly refusing to save large amounts of data, or asking the user before doing so".)
Attachment #384458 -
Flags: review?(mozbugz)
Assignee | ||
Comment 34•15 years ago
|
||
Reworked patch, data are transfered to clipboard when app quits only.
Attachment #384458 -
Attachment is obsolete: true
Attachment #407846 -
Flags: review?(mozbugz)
Comment 35•15 years ago
|
||
Comment on attachment 407846 [details] [diff] [review] an updated patch What makes things awkward here is that Mozilla is using low level selection functions and signals on its own GtkWidget mWidget to set data on the clipboard, but gtk_clipboard_store() only works on higher level GtkClipboards which have their own GtkWidget. There is no way to associate Mozilla's selections on its own GtkWidget with GtkClipboards. The patch here works around that (on quit) by changing the selection owner from nsClipboard's mWidget to a GtkClipboard and adds code to convert the nsITransferable to GtkClipboard format. I'm not so enthusiastic though about having yet another place where nsITransferables are converted to GtkSelectionData (and targets). The conversion in nsClipboard::Store() of this patch does convert from text/unicode _or_ images, but doesn't convert both text _and_ images (for which support was added in bug 518249) and doesn't convert to other mime types such as text/html (and maybe text/uri-list and text/plain, if they get used). Also, the Clipboard Manager Specification says "Clients which support the SAVE_TARGETS mechanism should announce this by listing SAVE_TARGETS as a target for the CLIPBOARD", but with this patch that target only gets added to the clipboard briefly on quit. I assume the intention is that the SAVE_TARGETS target informs the clipboard manager that it doesn't need to preemptively convert the clipboard selection whenever this app changes it. I think the best solution is to make nsClipboard use GtkClipboards for setting data. (It already uses GtkClipboard for getting data.) nsClipboard::SetData() would use gtk_clipboard_set_with_data() and gtk_clipboard_set_can_store() instead of gtk_selection_owner_set(), gtk_selection_clear_targets(), and gtk_selection_add_target(s)(). (m*Owner and m*Transferable need to be set after gtk_clipboard_set_with_data() as the GtkClipboardClearFunc will erase them.) nsClipboard would no longer need mWidget. invisible_selection_get_cb() and selection_clear_event_cb() would be replaced with the similar callbacks for gtk_clipboard_set_with_data(). nsClipboard::SelectionGetEvent() would be similar, except the unused arguments would be removed. nsClipboard::SelectionClearEvent() would get a GtkClipboard instead of a GdkEventSelection. That means the aEvent->selection is no longer available, but the type of selection can be determined by comparing the GtkClipboard* with gtk_clipboard_get(GDK_SELECTION_CLIPBOARD or GDK_SELECTION_PRIMARY). nsClipboard::Store() would simply just call gtk_clipboard_store() and nsClipboard::SelectionGetEvent() would be used for the conversion. Little nits: >+#define APP_QUIT "quit-application" >+ os->AddObserver(this, "quit-application", PR_FALSE); >+ if (strcmp(aTopic, APP_QUIT) == 0) { I'd like each of these topics to be represented consistently. As "quit-application" is only used twice, I'd suggest just using the string literal each time. >+ if (aTransferable == nsnull) Mozilla style is "!aTransferable". https://developer.mozilla.org/En/Mozilla_Coding_Style_Guide >+ // Save global clipboard content to gtk >+ nsresult Store (void); > > private: Let's make Store() private unless you have other uses in mind.
Attachment #407846 -
Flags: review?(mozbugz)
Assignee | ||
Comment 36•15 years ago
|
||
Okay, It would be better and more clear solution. I'll rewrite the patch...
Updated•15 years ago
|
Assignee: nobody → stransky
Component: XUL → Widget: Gtk
Keywords: helpwanted
QA Contact: xptoolkit.widgets → gtk
Whiteboard: Help needed for getting provided patch landed.
Assignee | ||
Comment 37•15 years ago
|
||
A next version. Store() has been removed because gtk_clipboard_set_can_store() is enough. Data are set by gtk_clipboard_set_can_store(), GtkClipboardClearFunc is not used because we don't need that (do we?).
Attachment #407846 -
Attachment is obsolete: true
Attachment #410768 -
Flags: review?(mozbugz)
Updated•15 years ago
|
Attachment #410768 -
Flags: review?(mozbugz)
Comment 38•15 years ago
|
||
Comment on attachment 410768 [details] [diff] [review] v3 I like this much better, thank you. (In reply to comment #37) > Store() has been removed because gtk_clipboard_set_can_store() is enough. That would be enough when Gecko is embedded in GTK apps using gtk_main (because that calls _gtk_clipboard_store_all), but I don't understand how it would work with a XUL app, which uses lower level event functions. > GtkClipboardClearFunc is not used because we don't need that (do we?). GtkClipboardClearFunc provides notification that something else owns the selection. nsClipboard::SelectionClearEvent called EmptyClipboard which released the nsITransferable and notified the owner with: mSelectionOwner->LosingOwnership(mSelectionTransferable); This comment makes me suspect that this is important (though comments that say why are more helpful): >- // XXX make sure to set up the selection_clear event Nits: >+ bool ImagesAdded = PR_FALSE; I'd like avoid mixing types here. Either of the following would be OK: PRBool ImagesAdded = PR_FALSE; bool ImagesAdded = false; >+ gint nTargetsNum; Just |nTargets| or |numTargets| >+ if(gtk_clipboard_set_with_data(gtkClipboard, gtkTargets, nTargetsNum, Mozilla style is a space after "if". >- nsCOMPtr<nsITransferable> trans = GetTransferable(whichClipboard); >+ nsCOMPtr<nsITransferable> trans = GetTransferable(whichClipboard); Unnecessary extra whitespace.
Assignee | ||
Comment 39•15 years ago
|
||
Should address the comments...
Attachment #410768 -
Attachment is obsolete: true
Attachment #411182 -
Flags: review?(mozbugz)
Comment 40•15 years ago
|
||
Comment on attachment 411182 [details] [diff] [review] v4 >+nsClipboard::Store(void) >+{ >+ if (mSelectionTransferable) { >+ GtkClipboard *clipboard = gtk_clipboard_get(GDK_SELECTION_PRIMARY); >+ gtk_clipboard_store(clipboard); >+ } >+ if (mGlobalTransferable) { http://freedesktop.org/wiki/ClipboardManager seems only intended for the CLIPBOARD selection, not the PRIMARY. Also _gtk_clipboard_store_all() only stores the CLIPBOARD, and gtk_clipboard_set_can_store() doesn't do anything when clipboard->selection != GDK_SELECTION_CLIPBOARD so this first block won't do anything, and so should be removed. >+ PRBool ImagesAdded = PR_FALSE; Variables in Mozilla usually start with lower case, so |imagesAdded|. (Class names and function names start with upper case.) >+ if (gtk_clipboard_set_with_data(gtkClipboard, gtkTargets, numTargets, >+ clipboard_get_cb, clipboard_clear_cb, (gpointer)this)) The (gpointer) cast should be unnecessary because |this| is a |void*|. >+ if (aWhichClipboard == kSelectionClipboard) { >+ mSelectionOwner = aOwner; >+ mSelectionTransferable = aTransferable; >+ } >+ else { >+ mGlobalOwner = aOwner; >+ mGlobalTransferable = aTransferable; >+ } > >+ gtk_clipboard_set_can_store(gtkClipboard, gtkTargets, numTargets); Can you move gtk_clipboard_set_can_store to the else block, please. There's no difference in functionality because it won't do anything when aWhichClipboard == kSelectionClipboard, but it makes the intentions clearer. r=karlt with these changes.
Attachment #411182 -
Flags: review?(mozbugz) → review+
Assignee | ||
Comment 41•15 years ago
|
||
Attachment #411182 -
Attachment is obsolete: true
Attachment #411407 -
Flags: review?(mozbugz)
Assignee | ||
Comment 42•15 years ago
|
||
is sr requested here?
No
Comment 44•15 years ago
|
||
Comment on attachment 411407 [details] [diff] [review] v4+updates >+ // Store current clipboard content to GTK clipboard "Ask the clipboard manager to store the current clipboard content" would be more accurate. No need to ask for further review (unless you want to make further changes). Thank you!
Attachment #411407 -
Flags: review?(mozbugz) → review+
Comment 45•15 years ago
|
||
If no further review is necessary, when will this patch land and on what branches? There are hordes of restless users in this downstream bug and it would be nice to give them some sort of bugfix ETA: https://bugs.launchpad.net/ubuntu/+bug/11334
Comment 46•15 years ago
|
||
(In reply to comment #45) > If no further review is necessary, when will this patch land When someone checks it in on Martin Stránský's behalf. (Martin, could you post one final version with the comment-tweak that Karl suggested in comment 44? Then we can add the "checkin-needed" keyword to this bug, which will get your final patch noticed & checked in.) > and on what > branches? Per the current settings of the "wanted1.9.2" and "blocking1.9.2" flags at the top of this bug, this isn't targeted for landing on any branches. Just on trunk (for Firefox 3.7+).
Comment 47•15 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/270a70535807
Attachment #411407 -
Attachment is obsolete: true
Updated•15 years ago
|
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
See Also: → https://launchpad.net/bugs/11334
Target Milestone: --- → mozilla1.9.3a1
Comment 48•15 years ago
|
||
I'm seeing this on the console a lot... Gtk-CRITICAL **: gtk_clipboard_get_for_display: assertion `!display->closed' failed
Assignee | ||
Comment 50•14 years ago
|
||
If we take it to branches we need bug 518249 and bug 531580 too.
Assignee | ||
Updated•14 years ago
|
Comment 51•14 years ago
|
||
I have this problem on Windows Vista Home Premium SP2 English. Firefox 3.6.8 Final English. Copy url from adresbar, restart firefox, then paste copied url, and clipboard is empty...
Comment 52•14 years ago
|
||
Marc, this particular bug is Linux-specific. You should file a new one if you happen to have this same problem on Windows. Clipboard implementations are completely different among different operating systems, so Windows issues are totally irrelevant in this Linux bug.
Comment 53•14 years ago
|
||
(In reply to comment #52) > Marc, this particular bug is Linux-specific. You should file a new one if you > happen to have this same problem on Windows. Clipboard implementations are > completely different among different operating systems, so Windows issues are > totally irrelevant in this Linux bug. Ok, thanks :)
Assignee | ||
Comment 54•14 years ago
|
||
Attachment #461511 -
Flags: approval1.9.2.9?
Comment 55•14 years ago
|
||
Comment on attachment 461511 [details] [diff] [review] 1.9.2 version We will not be taking this for .9. Moving approval request forward.
Attachment #461511 -
Flags: approval1.9.2.9?
Attachment #461511 -
Flags: approval1.9.2.9-
Attachment #461511 -
Flags: approval1.9.2.10?
Comment 56•14 years ago
|
||
There is an unfixed dependency (bug 531580) and a fixed dependency (bug 518249) that depends on an unfixed bug (bug 552449). Until those are resolved we can't take this on the branches.
Attachment #461511 -
Flags: approval1.9.2.10? → approval1.9.2.10-
Updated•12 years ago
|
Comment 57•2 years ago
|
||
This Problem still exists in Firefox 100 and Ubuntu 22.04 for me.
Comment 58•2 years ago
|
||
Please reopen, thanks.
Comment 59•2 years ago
|
||
(In reply to Martin from comment #57)
This Problem still exists in Firefox 100 and Ubuntu 22.04 for me.
Please file a new bug with details. It might be a Snap issue, but reopening a 17 year old bug is probably not the way to go :)
Comment 60•2 years ago
|
||
Sorry, it is the XA_PRIMARY not the XA_CLIPBOARD (confused both): here is the new bug report: https://bugzilla.mozilla.org/show_bug.cgi?id=1771600
You need to log in
before you can comment on or make changes to this bug.
Description
•