if you select some text and copy it then close firefox
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mozilla Firefox |
Fix Released
|
Unknown
|
|||
firefox (Ubuntu) |
In Progress
|
Low
|
Mozilla Bugs |
Bug Description
Binary package hint: firefox
you will not be able to paste it. major bug..
maybe it should go upstream to the firefox team.
give it up for discord master bug reporter.
In Mozilla Bugzilla #311340, Thomas Winwood (jormundgand) wrote : | #2 |
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
In Mozilla Bugzilla #311340, Bugzilla-tecnocode (bugzilla-tecnocode) wrote : | #3 |
*** Bug 330704 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #311340, Bzbarsky (bzbarsky) wrote : | #4 |
I'm not sure I follow. We follow the spec at http://
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?
In Mozilla Bugzilla #311340, Thomas Winwood (jormundgand) wrote : | #5 |
The problem from my perspective is that Firefox somehow bypasses gnome-clipboard
In Mozilla Bugzilla #311340, Rimas Kudelis (rq) wrote : | #6 |
I guess it's a duplicate of Bug 23386. Someone should probably dupe one of these against the other.
In Mozilla Bugzilla #311340, Rimas Kudelis (rq) wrote : | #7 |
Btw the Summary field of this bug is really invalid. AFAICS, gnome-clipboard
In Mozilla Bugzilla #311340, Rimas Kudelis (rq) wrote : | #8 |
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
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://
[2] http://
In Mozilla Bugzilla #311340, Rimas Kudelis (rq) wrote : | #9 |
(one last message for now, I promise).
It's the link that is bad, not the summary. Someone please change the link to http://
Also, please dupe Bug 23386 against this one.
In Mozilla Bugzilla #311340, Rimas Kudelis (rq) wrote : | #10 |
could anybody apply the changes listed in my last comment, please?
In Mozilla Bugzilla #311340, Rimas Kudelis (rq) wrote : | #11 |
*** Bug 23386 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #311340, Rimas Kudelis (rq) wrote : | #12 |
Changing the URL and reassigning the bug to Toolkits/Widgets, as it seems more appropriate to go there.
discord (colin.williams) wrote : | #13 |
Binary package hint: firefox
you will not be able to paste it. major bug..
maybe it should go upstream to the firefox team.
give it up for discord master bug reporter.
Rich Johnson (nixternal) wrote : | #14 |
I don't know if this is a bug or not, but I experience this same issue and it is rather annoying.
Changed in firefox: | |
importance: | Undecided → Low |
status: | Unconfirmed → Confirmed |
Changed in firefox: | |
status: | Unknown → Confirmed |
Bruce Cowan (bruce89-deactivatedaccount) wrote : | #15 |
This looks like bug #21202
Alexander Sack (asac) wrote : | #16 |
upstream confirmed bugs are 'In Progress' for us.
Changed in firefox: | |
assignee: | nobody → mozillateam |
status: | Confirmed → In Progress |
Changed in firefox: | |
assignee: | mozillateam → mozilla-bugs |
In Mozilla Bugzilla #311340, eppy 1 (choppy121212) wrote : | #17 |
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:/
https:/
In Mozilla Bugzilla #311340, Rimas Kudelis (rq) wrote : | #18 |
I don't think this bug should be considered an RFE anymore. It's much rather a major loss of functionality, IMO.
In Mozilla Bugzilla #311340, Bunny13-tm (bunny13-tm) wrote : | #19 |
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.
In Mozilla Bugzilla #311340, Dstile (dstile) wrote : | #20 |
Since the URL field leads to a page that doesn't exist, I am pointing it to current location of Clipboard Manager specification:
http://
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.
In Mozilla Bugzilla #311340, Eldmannen+mozilla (eldmannen+mozilla) wrote : | #21 |
Please fix this.
This annoys me a lot. I must use Epiphany or other browser, if you cant fix it.
In Mozilla Bugzilla #311340, Martin Olsson (mnemo) wrote : | #22 |
This bug is _the_ most annoying bug for Firefox on Ubuntu. I'm hit my this bug at least once every week.
In Mozilla Bugzilla #311340, Bugmail-asutherland (bugmail-asutherland) wrote : | #23 |
*** Bug 221183 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #311340, Colin Dean (colindean) wrote : | #24 |
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.
In Mozilla Bugzilla #311340, Rimas Kudelis (rq) wrote : | #25 |
(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.
In Mozilla Bugzilla #311340, Daniel Holbert (dholbert) wrote : | #26 |
*** Bug 412782 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #311340, Yann Dirson (ydirson-altern) wrote : | #27 |
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
In Mozilla Bugzilla #311340, mati (mati-wroc) wrote : | #28 |
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.
In Mozilla Bugzilla #311340, robbert (robbertvandendoorn) wrote : | #29 |
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.
In Mozilla Bugzilla #311340, sklp (sklp) wrote : | #30 |
Created an attachment (id=384458)
Possible clipboard fix
In Mozilla Bugzilla #311340, sklp (sklp) wrote : | #31 |
It seems to work for me, feel free to try, modify, and/or commit it.
In Mozilla Bugzilla #311340, Mkmelin+mozilla (mkmelin+mozilla) wrote : | #32 |
Richard: you need to get the patch reviewed - see https:/
In Mozilla Bugzilla #311340, sklp (sklp) wrote : | #33 |
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.
In Mozilla Bugzilla #311340, Rimas Kudelis (rq) wrote : | #34 |
Rickard: I think you may at least want to ask for caillon's review.
In Mozilla Bugzilla #311340, Stransky (stransky) wrote : | #35 |
(From update of attachment 384458)
Can you please check this patch?
In Mozilla Bugzilla #311340, Stransky (stransky) wrote : | #36 |
(From update of attachment 384458)
Karl, can you check this one please?
In Mozilla Bugzilla #311340, Mozbugz (mozbugz) wrote : | #37 |
(From update of attachment 384458)
Thank you, Rickard for submitting the patch.
It looks like gtk_clipboard_
think we should be using it so often.
My reading of http://
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_
immediately, and I don't think we want to do this every time
nsClipboard:
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".)
In Mozilla Bugzilla #311340, Stransky (stransky) wrote : | #38 |
Created an attachment (id=407846)
an updated patch
Reworked patch, data are transfered to clipboard when app quits only.
In Mozilla Bugzilla #311340, Mozbugz (mozbugz) wrote : | #39 |
(From update of attachment 407846)
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_
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:
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:
gtk_clipboard_
gtk_selection_
(m*Owner and m*Transferable need to be set after gtk_clipboard_
as the GtkClipboardCle
nsClipboard would no longer need mWidget. invisible_
selection_
gtk_clipboard_
nsClipboard:
would be removed.
nsClipboard:
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_
nsClipboard:
nsClipboard:
Little nits:
>+#define APP_QUIT "quit-application"
>+ os->AddObserver
>+ 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:/
>+ // Save global clipboard content to gtk
>+ nsresult Store (void);
>
> private:
Let's ...
In Mozilla Bugzilla #311340, Stransky (stransky) wrote : | #40 |
Okay, It would be better and more clear solution. I'll rewrite the patch...
In Mozilla Bugzilla #311340, Stransky (stransky) wrote : | #41 |
Created an attachment (id=410768)
v3
A next version.
Store() has been removed because gtk_clipboard_
Data are set by gtk_clipboard_
In Mozilla Bugzilla #311340, Mozbugz (mozbugz) wrote : | #42 |
(From update of attachment 410768)
I like this much better, thank you.
(In reply to comment #37)
> Store() has been removed because gtk_clipboard_
That would be enough when Gecko is embedded in GTK apps using gtk_main
(because that calls _gtk_clipboard_
would work with a XUL app, which uses lower level event functions.
> GtkClipboardCle
GtkClipboardCle
selection. nsClipboard:
released the nsITransferable and notified the owner with:
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_
Mozilla style is a space after "if".
>- nsCOMPtr<
>+ nsCOMPtr<
Unnecessary extra whitespace.
In Mozilla Bugzilla #311340, Stransky (stransky) wrote : | #43 |
Created an attachment (id=411182)
v4
Should address the comments...
In Mozilla Bugzilla #311340, Mozbugz (mozbugz) wrote : | #44 |
(From update of attachment 411182)
>+nsClipboard:
>+{
>+ if (mSelectionTran
>+ GtkClipboard *clipboard = gtk_clipboard_
>+ gtk_clipboard_
>+ }
>+ if (mGlobalTransfe
http://
CLIPBOARD selection, not the PRIMARY. Also _gtk_clipboard_
stores the CLIPBOARD, and gtk_clipboard_
clipboard-
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_
>+ clipboard_get_cb, clipboard_clear_cb, (gpointer)this))
The (gpointer) cast should be unnecessary because |this| is a |void*|.
>+ if (aWhichClipboard == kSelectionClipb
>+ mSelectionOwner = aOwner;
>+ mSelectionTrans
>+ }
>+ else {
>+ mGlobalOwner = aOwner;
>+ mGlobalTransferable = aTransferable;
>+ }
>
>+ gtk_clipboard_
Can you move gtk_clipboard_
no difference in functionality because it won't do anything when
aWhichClipboard == kSelectionClipb
r=karlt with these changes.
In Mozilla Bugzilla #311340, Stransky (stransky) wrote : | #45 |
Created an attachment (id=411407)
v4+updates
In Mozilla Bugzilla #311340, Stransky (stransky) wrote : | #46 |
is sr requested here?
In Mozilla Bugzilla #311340, Roc-ocallahan (roc-ocallahan) wrote : | #47 |
No
In Mozilla Bugzilla #311340, Mozbugz (mozbugz) wrote : | #48 |
(From update of attachment 411407)
>+ // 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!
In Mozilla Bugzilla #311340, Martin Olsson (mnemo) wrote : | #49 |
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:/
In Mozilla Bugzilla #311340, Daniel Holbert (dholbert) wrote : | #50 |
(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+).
In Mozilla Bugzilla #311340, Reed Loden (reed) wrote : | #51 |
Created an attachment (id=414679)
what I landed
Changed in firefox: | |
status: | Confirmed → Fix Released |
FMaz (fmaz008) wrote : | #52 |
This bug has been marked as a duplicate of the bug #11334, called: "MASTER Copy-Paste doesn't work if the source is closed before the paste"
If this bug still affects you, please use the "This bug affect me too" option to increase the resolution priority:
https:/
The full bug repport can be seen at:
https:/
*** Bug 312485 has been marked as a duplicate of this bug. ***