Last Comment Bug 56219 - [Linux] Can't paste over 4000 bytes from another app into mozilla
: [Linux] Can't paste over 4000 bytes from another app into mozilla
Status: RESOLVED FIXED
: dataloss, helpwanted, pp
Product: Core
Classification: Components
Component: XUL (show other bugs)
: Trunk
: x86 Linux
: P3 critical with 27 votes (vote)
: mozilla1.6alpha
Assigned To: Brian Ryner (not reading)
: sujay
: Neil Deakin
Mentors:
: 114968 150173 158052 158067 161419 166136 169244 182553 182596 190977 205823 208858 210473 212424 216839 218702 223705 (view as bug list)
Depends on: 84973
Blocks: 115259 144260
  Show dependency treegraph
 
Reported: 2000-10-11 22:28 PDT by R.K.Aa.
Modified: 2011-08-05 22:36 PDT (History)
59 users (show)
asa: blocking1.3a-
asa: blocking1.4b-
asa: blocking1.5b-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Proposed patch (4.08 KB, patch)
2002-07-25 17:04 PDT, Michal Bukovjan
no flags Details | Diff | Splinter Review
Better solution (7.82 KB, patch)
2002-07-27 12:51 PDT, Michal Bukovjan
no flags Details | Diff | Splinter Review
working patch (7.06 KB, patch)
2003-06-12 00:18 PDT, Louie Zhao
no flags Details | Diff | Splinter Review
console log (4.44 KB, application/octet-stream)
2003-06-15 15:10 PDT, Michiel van Leeuwen (email: mvl+moz@)
no flags Details
updated patch for trunk (5.66 KB, patch)
2003-06-16 02:38 PDT, Louie Zhao
blizzard: review-
Details | Diff | Splinter Review
console log on RH8.0 (2.82 KB, text/plain)
2003-06-16 03:00 PDT, Louie Zhao
no flags Details
updated patch using diff -u (7.04 KB, patch)
2003-06-19 21:20 PDT, Louie Zhao
no flags Details | Diff | Splinter Review
patch v3 (4.54 KB, patch)
2003-06-25 04:11 PDT, Louie Zhao
no flags Details | Diff | Splinter Review
backport of gtk2 patch (5.96 KB, patch)
2004-01-29 18:26 PST, Brian Ryner (not reading)
blizzard: review-
blizzard: superreview-
Details | Diff | Splinter Review
backport of gtk2 patch (8.29 KB, patch)
2004-02-02 18:17 PST, Brian Ryner (not reading)
blizzard: review+
blizzard: superreview+
Details | Diff | Splinter Review
patch to avoid ++ inside macro (2.19 KB, patch)
2004-03-16 09:38 PST, David Baron :dbaron: ⌚️UTC-8
bryner: review+
bryner: superreview+
chofmann: approval1.7b+
Details | Diff | Splinter Review
FD_SET testcase (238 bytes, text/plain)
2004-03-16 09:52 PST, Jürgen Keil
no flags Details

Description R.K.Aa. 2000-10-11 22:28:17 PDT
Old bug, still not solved.

linux 2000101113

Open mailcompose
Select text equivalent of 4001 bytes or more in an external app
Place cursor in mailbody field
Click middle button

Nothing pastes.

In console it says "Read cliboard from memory"

Now click middle mouse button again a few times:

Console now states:
->>>>>>>>>>>>>> Read Clipboard from memory
Don't know how to insert an image yet!

--

Up to 4000 bytes can be pasted just fine this way.
4001 bytes ++ can not.

4001 bytes is barely a full page of text.
Comment 1 kinmoz 2000-10-12 11:22:59 PDT
Reassign to akkana@netscape.com.

I tried this with my Netscape_20000922_BRANCH Win32 and Linux builds, in both
Composer and MsgCompose, and each time I was able to paste over 7K worth of data.

I used the following script to generate a text file that told me exactly how
many bytes I was selecting:


#! /usr/bin/perl

$str = "Now is the time for all good men to come to the aide of their country.";
$len = length($str);

for ($i = 0 ;  $i < 100; $i++)
{
  $total += $len + 7; # 4 digits, colon, space and LF.
  printf STDOUT "%4d: $str\n", $total;
}


I then loaded the textfile into emacs, selected all of it (7700 bytes) and then
middle mouse pasted into both Composer and MsgCompose, and it always pasted
properly.

My trunk builds are not done building yet, I'll try them when they are done.

Perhaps we need more info, like what window manager are you using, what app you
are trying to copy from, and perhaps even the sample text you are trying to copy?
Comment 2 kinmoz 2000-10-12 11:23:54 PDT
Cc jfrancis@netscape.com since he was involved in some recent copy/paste
modifications.
Comment 3 R.K.Aa. 2000-10-12 11:48:09 PDT
I'm using gnome1.2 /sawfish 0.30 on RH6.2 all upgrades.

The bug seems to occure regardless of what external application i have selected
text in. Have tried from Powershell (xterm clone), tknotepad (simple Tcl/Tk
editor) Abiword, gedit.
It does NOT happen in NC 4.75, where i for fun tested pasting 3 MB of text, and
it worked just fine.

Sympthomatic is that the first patee attempt outputs "Read clipboard from
memory" and the *second* attempt in addition states "Don't know how to insert an
image yet".

All subsequent attempts will now only state "Read clipboard from memory".
The "image" error-message never displays again.

This is not a new bug. It's months since i pointed it out, in connection with
the same amount of text attempted pasted (over 4000 bytes) would crash mozilla.

Also noteworthy: When closing the editor window (composer or mailcompose) - it
does NOT prompt to save changes. Nothing is changed in editor by the failed pastes.
Comment 4 kinmoz 2000-10-12 12:10:30 PDT
Ok, I see the problem now if I use gedit to load my sample file, and as you say,
if you select more than 4000 chars it doesn't paste into composer.

I'm wondering if gedit and the other apps you mention are using some X clipboard
feature/type, when they have a selection greater than 4000 bytes, that we are
not supporting in our code.

Comment 5 kinmoz 2000-10-12 12:12:37 PDT
I forgot to mention that we might want to look at the differences in the X
clipboard when it is set by emacs and when it is set by gedit, since we
obviously support whatever emacs is using.
Comment 6 Akkana Peck 2000-10-12 12:26:48 PDT
Also cc jst in case it's a noxif bug.
Comment 7 Akkana Peck 2000-10-12 12:35:25 PDT
We'd better bring Pavlov into this.  Pav, do you know of any limitations in the
gnome clipboard which might be limiting copies to 4000 bytes?
Comment 8 Simon Fraser 2000-10-12 12:39:21 PDT
Looks like a GTK clipboard issue. Over to pavlov.
Comment 9 kinmoz 2000-10-12 12:47:27 PDT
Just wanted to add a note that there is no limitation on size for the clipboard
... I can paste *all* 7k of the text I selected in gedit, into a vi session, but
not into Composer/MsgCompose. I think it has to do with us not recognizing the
format of the data on the clipboard.
Comment 10 kinmoz 2000-10-12 12:48:03 PDT
Adding akkana@netscape.com back to the Cc list.
Comment 11 Stuart Parmenter 2000-10-12 16:34:02 PDT
the xincr protocol could be kicking in... although gtk does that for us, so we
should be getting that done automagically.. I will take a look at this.
Comment 12 Stuart Parmenter 2000-10-13 03:15:02 PDT
futuring...  I know what is causing this, but the fix isn't trivial... maybe we
can fix this for mozilla 1.0
Comment 13 R.K.Aa. 2000-10-13 07:01:17 PDT
The sum of futured bugs are by and by meaning that i can't use this product.
I need a tool, not a toy. For the curiosity of it: Apart from emacs: Which
applications CAN i paste more than 4000 bytes from?
Comment 14 tenthumbs 2000-10-13 09:54:36 PDT
I can paste 4900 bytes from nedit. Opening xclipboard and pasting into it first
also seems to work.

How about a description of the real problem? There's no reason to keep it secret,
is there?
Comment 15 Stuart Parmenter 2000-12-20 11:35:40 PST
I really want to fix this.  This bug angers me.
Comment 16 Joe Francis 2001-01-20 00:46:58 PST
uncc'ing me
Comment 17 Christian Schaller 2001-02-13 12:49:41 PST
Hi, I noticed that this bug is still here in the latest nightly builds, any
progress on fixing it since it really hampers me and I would guess a lot of
other people. 4000 chars isn't that much, really :)


AFAIK no gtk based app is able to paste into Mozilla, gedit other has mentioned
but I can confirm that the same is true for Abiword too.
Comment 18 Stuart Parmenter 2001-02-13 13:17:25 PST
i don't have any problem pasting from gedit..  i don't have abiword, although i
guess i could try it and see.
Comment 19 R.K.Aa. 2001-06-09 18:33:26 PDT
so.. does this depend on bug 84973?
I still can't paste over 4000 byte to moz from any editor i use.
Comment 20 Stuart Parmenter 2001-06-11 04:34:00 PDT
yeah, it pretty much depends on 84973.... we can't process the xincr messages 
that gtk tries to process because we have to process the clipboard requests 
syncronously...
Comment 21 Asa Dotzler [:asa] 2001-12-03 11:13:35 PST
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)
Comment 22 R.K.Aa. 2001-12-12 17:55:08 PST
*** Bug 114968 has been marked as a duplicate of this bug. ***
Comment 23 János Holányi 2001-12-12 20:09:02 PST
Please check Netscape 4.77 source, where this bug doesn't exist.
See also [Bug 114968] New: paste of larger text impossible
Comment 24 mair 2002-03-12 02:05:56 PST
Noone has mentioned it AFAI can see, but this bug affects pasting everywhere in
Mozilla, not only in the Composer. *EXTREMELY* annoying and *EXTREMELY*
counterproductive!

RH 7.2 + all updates, GNOME 1.4, Sawfish 1.0.1, every Mozilla version I have
ever downloaded.
FWIW the bug affects Galeon as well.

Comment 25 kinmoz 2002-03-12 09:10:12 PST
Nominating for nsbeta1.
Comment 26 Kathleen Brade 2002-03-12 12:19:03 PST
This is a Linux-specific bug.
Is it actually the copy that truncates to 4000 bytes or the paste?
Adding helpwanted keyword since I think pavlov wouldn't mind a patch from someone.
Comment 27 mair 2002-03-12 12:56:27 PST
Copying > 4k from within Mozilla and pasting into Mozilla or into any other app
works fine.
Copying > 4k from any other app and pasting into Mozilla does not work.
Comment 28 Kathleen Brade 2002-03-12 13:17:50 PST
clarify summary based on comment 27
Comment 29 Braden 2002-03-12 13:37:55 PST
brade: To clarify mair's comment with respect to your question, there is no
truncation going on. Pasting just *doesn't work*.
Comment 30 odd@findus.dhs.org 2002-04-23 12:15:10 PDT
This bug deserves some attention. It's quite a critical issue, since it gets in
the way of such (for some people) critical things as good bug reporting (pasting
stack traces) in Mozilla and derivatives.
Comment 31 alge 2002-06-08 10:56:03 PDT
Urm, comment 27.. Selecting more than 4000 characters in mozilla and pasting it
in another app (wc -c in aterm) does not work for me, it just outputs one byte
of a seemingly random value. So it does not work any way for me (from, to browser)
Comment 32 alge 2002-06-08 10:57:28 PDT
*** Bug 150173 has been marked as a duplicate of this bug. ***
Comment 33 Toni Willberg 2002-06-08 12:56:27 PDT
Ok, this is very very major bug that has existed for over two years. 

Please change this to "critical", as I'd like to see it fixed asap.

And by the way, thanks for nice browser. :)

Comment 34 cpintvn001 2002-06-13 11:47:48 PDT
This bug is impeding serious wiki usage because non-trivial wiki contents can't
be copied into another editor and then pasted back during editing.
Comment 35 Braden 2002-06-13 12:13:37 PDT
Similarly, SpamCop is mostly unusable from Mozilla because of this.
Comment 36 Ere Maijala (slow) 2002-07-18 00:43:36 PDT
*** Bug 158067 has been marked as a duplicate of this bug. ***
Comment 37 Igor Furlan 2002-07-22 23:57:26 PDT
not yet fixed in 

Mozilla 1.1b
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1b) Gecko/20020722
Comment 38 Michal Bukovjan 2002-07-25 17:04:21 PDT
Created attachment 92812 [details] [diff] [review]
Proposed patch

Bug fix, cleanup and maybe speed up :-)
I tested whatever came to my mind, and this just works for me.
Only bugs remaining is interaction with KDE apps and sometimes the Paste option
is not highlighted, but both of these existed before so separate bugs may (have
to) be filled.
Comment 39 Michal Bukovjan 2002-07-25 17:06:53 PDT
The patch is against Mozilla 1.1b source.
Comment 40 Stuart Parmenter 2002-07-26 15:17:32 PDT
unfortunatly, you can't do that.

the problem with this patch is that you also process other non-clipboard events.
 Too much code depends on the clipboard operation happening without other events
being processed while it gets the data.  This patch would introduce lots of hard
to repdouce crashes and other problems.

The "best" fix would be to make the whole mozilla clipboard interface async...
but thats a lot of work.

The other approach would be to rewrite the clipboard code to not use GTK and
avoid using XINCR completly, since it doesn't really buy us anything since we
have to block anyways.
Comment 41 Michal Bukovjan 2002-07-27 12:51:24 PDT
Created attachment 93030 [details] [diff] [review]
Better solution

Better solution to the problem.
Rather than let go the entire main iteration, only filter clipboard events for
the widget in question and process that.

This works better and solves popup menu problems as well.
There are some GTK warnings that I don't undestand: 
- some are clearly buggy (gdk_event_copy assumes that an event has always
window and tries to add a ref, which is wrong)
- when pasting by pop up menu, there are some warnings, look like random. I
spent several hours trying to figure those out, but no success - maybe someone
more skilled than me could help here.

Other than those warnings, everything works great now :-)
Again, the patch is against Mozilla 1.1b codebase.
Comment 42 Michal Bukovjan 2002-07-28 05:49:18 PDT
This patch should also (help to) fix bug 83024 (I cannot measure that, though).
Comment 43 R.K.Aa. 2002-08-06 20:51:35 PDT
*** Bug 161419 has been marked as a duplicate of this bug. ***
Comment 44 Boris Zbarsky [:bz] (still a bit busy) 2002-09-02 03:44:14 PDT
*** Bug 166136 has been marked as a duplicate of this bug. ***
Comment 45 Christopher Blizzard (:blizzard) 2002-09-02 08:22:45 PDT
This is probably because we're using our own hand-rolled clipboard code instead
of using the gtk code.  If my memory serves, there's a specific protocol for
handling large clipboard transfers.
Comment 46 Ben Bucksch (:BenB) 2002-09-19 12:05:05 PDT
*** Bug 158052 has been marked as a duplicate of this bug. ***
Comment 47 Andraz Tori 2002-09-22 05:25:00 PDT
Patch is needed ASAP.
This bug makes mozilla unusable for most of content managment systems (CMS).
Comment 48 Igor Furlan 2002-09-26 08:11:29 PDT
I've noticed that I can "paste" long text snippets into the e-mail
composer, IF I SELECT THE TEXT from the HTML page. I could not find yet a size
limit..


but

if I select the text from the TEXT EDITOR (for example vi)  I can not
paste more than 4000 bytes


just my 0.01 euro
Comment 49 Igor Furlan 2002-09-26 08:15:30 PDT
ooooooooops   I've forgot to say that my system is

Mozilla 1.2b
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20020920
Comment 50 Igor Furlan 2002-10-11 22:28:40 PDT
Mozilla's coding gurus ,   p l e a s e   p l e a s e    p l e a s e

fix this booooooooooooooog ASAP
Comment 51 R.K.Aa. 2002-11-28 14:31:57 PST
*** Bug 182553 has been marked as a duplicate of this bug. ***
Comment 52 Igor Furlan 2002-11-28 22:41:08 PST
not yet fixed in

Mozilla 1.3a
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021117
Comment 53 tirantloblanc 2002-11-30 03:34:38 PST
This is a very important bug. You should try to correct it before releasing any
release.
Comment 54 Eli K. Breen - ActiveState 2002-12-19 13:06:19 PST
Pasting maximum appears to be 1k, not 4. (Pasting 1025bytes causes the cursor in
Mozilla to hang temporarily, 1024 works.)

Verified copying from Vim (with select, and right mouse button paste) and Open
Office (Ctrl+c/v).

Running FreeBSD 4.7, XFree86 4.02 and Blackbox with Mozilla/5.0 (X11; U; FreeBSD
i386; en-US; rv:1.1) Gecko/20021112

-E-
Comment 55 Eli K. Breen - ActiveState 2002-12-19 13:15:29 PST
Clarification on comment #54

The 1K limit is only when pasting in to a text box in the browser (pasting to
mail composer will paste upwards of 5120Bytes. So no probs there.)

-E-
Comment 56 Christian :Biesinger (don't email me, ping me on IRC) 2002-12-23 03:16:08 PST
mgabriel: try requesting the review from a specific person... like blizzard
Comment 57 Toni Willberg 2003-01-02 05:58:50 PST
Now it's really time to fix this. 

Mozilla based clients are only possibility here with Linux, and this really
really needs to be fixed.

Do we have to pay some amount of money to the developers before they act or what
might help?

And somebody with enough power, please mark this as "blocker", I have not enough
magic.
Comment 58 Aaron Kaluszka 2003-01-02 07:05:47 PST
I don't think it's a blocker, but it does meet the terms of critical since there
is dataloss.
Comment 59 Christian :Biesinger (don't email me, ping me on IRC) 2003-01-02 07:24:54 PST
Comment on attachment 93030 [details] [diff] [review]
Better solution

I told you guys one week ago that you should request review from someone
specifically if you want results.

doing that for you know.
Comment 60 Jo Hermans 2003-01-28 09:43:29 PST
*** Bug 190977 has been marked as a duplicate of this bug. ***
Comment 61 Jo Hermans 2003-01-28 09:45:16 PST
Bug 190977 claims that the reverse doesn't work either (copying from Mozilla
into another app).
Comment 62 alge 2003-01-28 10:23:03 PST
yup, it (copy/paste to a different program) doesn't work for me (see comment 31)
Comment 63 Bartosz Wucke 2003-01-28 17:47:17 PST
Just a note (from my Dup 190977 ) - original xterm seems to work fine with any
amount of data, rxvt and clones like aterm fail. What's curious though, where
copying "mozilla to aterm" fails, "mozilla->xterm->aterm" works (no problem with
copying large amounts of data from other than mozilla apps.)
In aterm I get a single apparently random character pasted instead of no output
at all as reported here.

Sorry for dup, "selection" seemed to be the only reasonable component, wouldn't
guess it's XP Toolkit/Widgets. (there's a few other clipboard-related bugs there)

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030121
aterm version 0.4.2
xterm: XFree86 4.0.3(156)
Comment 64 otaylor 2003-02-03 11:35:44 PST
Quick note here ... while you could write your own clipboard code,
you can't avoid supporting INCR.

The sender side (the clipboard owner) is the party that decides
to use INCR, and the ICCCM requires that you support it.

I don't really understand what the big problem here is - yes,
INCR requires reentering the event loop or scanning ahead for
messages, but no more so than a normal cut and paste.

I think someone just needs to read the INCR section of the ICCCM
and extend the current bad hacks that mozilla is doing appropriately.
Comment 65 Juliano F. Ravasi 2003-02-05 08:10:02 PST
This bug is still alive on
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030201.

I have to copy and paste a lot of data from gvim into Mozilla (mainly in
Insert->HTML of Composer) and this bug is being critical, because I have to
divide the copyied text in 4 or 5 parts.

Both clipboards have this problem (Ctrl-V and middle mouse button). The review
is already 1 month old without any answer.
Comment 66 Erik Moeller 2003-02-05 08:33:27 PST
Workaround: 

1) Open the file you want to copy using Mozilla e.g. in a new tab;

2) Copy it from within Mozilla where you want it.

There's no limit on copying & pasting within Mozilla.
Comment 67 Pratik 2003-03-06 11:17:51 PST
fyi,

The patch doesn't apply cleanly anymore but it works! The only place of
conflicts was in the header files inclusions and its not that big a deal. (Would
it help if I posted a current patch?)

There is one issue I noticed. After pasting it in the compose window, the window
doesn't seem to get refreshed. So If I have a small compose window and paste a
lot of text, the window stays blank. If I move the scrollbars around, the text
shows up.

Thanks mgabriel!
Comment 68 Michiel van Leeuwen (email: mvl+moz@) 2003-03-07 13:30:17 PST
The patch makes opening composer hang for me. There should be some timeout
checking somewhere,  I think in GetTargets, and maybe others.
Oh, and it doesn't use mozilla style everywhere.
Comment 69 Igor Furlan 2003-03-20 23:29:52 PST
no... select & paste still does not work !!

I CAN NOT "select" in GVIM and "paste" into mozilla e-mail client
more than 4K of pure ASCII text

Mozilla 1.4a
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030315

This bug is more than 2 years old. Even MS fixes their bugs faster.
This is "bug" is the only reason I am still using NS4.7X Messanger as
my daily e-mail client.

Please , please , please FIX IT !!

Additional note:
"select" & "paste" from NS4.7X browser to mozilla e-mail client (composer)
works without a problem. I can select and paste with mouse any text I choose to.
There is no size limitation.
Comment 70 Eli K. Breen - ActiveState 2003-04-23 13:28:45 PDT
This problem is made much worse by the fact that you can't paste more than 1K
from Open Office and other apps to Mozilla.

OO guys say it's a Moz bug, makes sense.

http://www.openoffice.org/issues/show_bug.cgi?id=13235
Says:

Cut/Paste maxes at 1K from Writer --> Mozilla* however much more is possible if
you cut/paste from Writer-->Vim-->Mozilla. Why is this?

* Cursor will hang in Mozilla form for about 1s, but no paste.
(Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3) Gecko/20030409
RPT-HTTPClient/0.3-2)

[...]

------- Additional Comments From Joost Andrae 2003-04-10 03:34 PDT -------

Joost: AFAIK this was a bug in Mozilla. Mozilla pretent to support the
clipboard format text/html but it wasn't able to

Comment 71 Ben Bucksch (:BenB) 2003-04-30 17:41:22 PDT
Bug also visible when copying between different Mozilla instances. Nothing at
all get copied. I tried to copy HTML (from HTML page composer to HTML mail
composer). Using Moz 1.0.2.
Comment 72 Andrew Schultz 2003-05-31 14:40:04 PDT
*** Bug 205823 has been marked as a duplicate of this bug. ***
Comment 73 Boris Zbarsky [:bz] (still a bit busy) 2003-06-09 19:06:18 PDT
*** Bug 208858 has been marked as a duplicate of this bug. ***
Comment 74 Louie Zhao 2003-06-12 00:18:08 PDT
Created attachment 125490 [details] [diff] [review]
working patch

This patch works well when copy data from OpenOffice, gvim, gedit with large
data size.

If the data can be transfered within 1 time, when requestor received
"SelectionNotify" event, it means the data (if available) has been stored in
the window's property of the requestor. But when transfering large data, INCR
protocol is used. In that case, when requestor received "SelectionNotify"
event, that only mean the data owner will begin to transfer data (refer to
http://tronche.com/gui/x/icccm/sec-2.html#s-2). Mozilla thinks data transfer
finished when received "SelectionNotify" event (refer to
"FindSelectionNotify"), so large data copy failed.

The solution in this patch refer to gtk2 implementation (see
gtk_clipboard_wait_for_contents), which works well in Mozilla gtk2 version.

BTW, OpenOffice has the same issue when pasting data, which cause the problem
when copy from mozilla to openoffice. Hope OpenOffice guy can fix this issue. 

The limitation on data size is always 4K. Because when copy from mozilla to
openoffice or from openoffice to mozilla,  the data format is "text/html". So
the data size we see is less than the size of actual data transfered.
Comment 75 Louie Zhao 2003-06-12 00:28:17 PDT
Comment on attachment 125490 [details] [diff] [review]
working patch

Blizzard, can you spare some time to review this patch since this function is
important and has been discussed for quite a long time ? 

IMHO, I think the solution is reasonable since it has been used in gtk2
implementation.

Thanks very much.
Comment 76 Michiel van Leeuwen (email: mvl+moz@) 2003-06-12 03:48:16 PDT
I used to have problems pasting from nedit, but those are gone when applying
this patch.
However, when starting composer, it seems to hang now. the wait cursor stays
forever, and i even closing all the windows doesn't quit mozilla anymore.

Hmm, after more testing it works "sometimes". But i still can't exit mozilla
cleanly. It seems to be waiting for some selection events.
Comment 77 Louie Zhao 2003-06-12 20:24:34 PDT
I use mozilla1.4b on RedHat8.0 and don't encounter your problem. mvl, can you
specify your building enviornment for me to reproduce the isse? Thanks very much.
Comment 78 Michiel van Leeuwen (email: mvl+moz@) 2003-06-15 14:53:14 PDT
I use regular nightlies from ftp.mozilla.org for regualr browsing, and sometimes
pasting (even a few chars) doesn't work correctly. Mostly, that is from nedit
into some html form. I have to try multiple times to get it working.

My own build is with gcc3.3, debian prerelease and debug enabled, on debian
testing. gtk is version 1.4.2.
Opening composer hangs, but when switching to another virtual screen (or
workpace, or whatever sawfish calls it) and switching back, stops the hang. But
pasting is very slow now, and still unreliable.

btw, with your patch and without DEBUG_CLIPBOARD, the build fails around line 477.
Comment 79 Michiel van Leeuwen (email: mvl+moz@) 2003-06-15 15:10:17 PDT
Created attachment 125704 [details]
console log

The output on the console when running mozilla -editor. 
nsPluginHostImpl::Observe "quit-application" is where i closed the window. It
took a while before i got the prompt back, a few seconds.
Comment 80 Louie Zhao 2003-06-16 02:38:26 PDT
Created attachment 125735 [details] [diff] [review]
updated patch for trunk
Comment 81 Louie Zhao 2003-06-16 03:00:55 PDT
Created attachment 125737 [details]
console log on RH8.0

This console output is from my workspace (mozilla trunk, RH8.0, gcc3.2,
gtk1.2.10). The main difference with Michiel's is the time sequence of
"quit-application" and "nsClipboard::WaitingForContents -> got reply and exit
loop".

With the patch, mozilla starts a new event loop when sending request. When
getting "SelectionRecieve" signal, mozilla quit the new loop and return to the
old one. From the debug info, there seems to be no problem when waiting for
"SelectionRecieve" signal.
Comment 82 Louie Zhao 2003-06-17 23:24:00 PDT
I test the patch on Solaris 9. With DEBUG_CLIPBOARD, it will crash sometimes
because some debug sentence use "g_printf()", which can't handle "null" on
Solaris (there is no problem on Linux), such as line 425.  There is no crash
without DEBUG_CLIPBOARD.

If the speed of the running host is slow, it will wait for a long time when
pasting both from mozilla and from other app (seem to hang, but really not).
It's not due to Clipboard module. Getting data from clipboard won't cost much
time. The delay happens after composer gets data.

Besides the issues above, clipboard work well on Solaris9.
Comment 83 Christopher Blizzard (:blizzard) 2003-06-19 10:32:06 PDT
Comment on attachment 125735 [details] [diff] [review]
updated patch for trunk

can you use diff -u please?
Comment 84 Louie Zhao 2003-06-19 21:20:38 PDT
Created attachment 126099 [details] [diff] [review]
updated patch using diff -u

same to previous one, using diff -u instead
Comment 85 Jo Hermans 2003-06-24 04:09:02 PDT
*** Bug 210473 has been marked as a duplicate of this bug. ***
Comment 86 Louie Zhao 2003-06-25 04:11:08 PDT
Created attachment 126444 [details] [diff] [review]
patch v3

I found the way to reproduce Michiel's problem. It happens in the circumstance
below:

1. nsClipboard start a new main loop
2. nsClipboard start another new main loop before the SIGNAL come back(which
mean the first new loop hasn't quit)
3. Only 1 SIGNAL come back, which cause the first new loop never ends. 

This only happen when GetTarget. So this patch only apply the new solution to
"DoRealConvert", not to "GetTarget".

Michiel, can you test this patch on your workspace? Thanks very much.
Comment 87 Michiel van Leeuwen (email: mvl+moz@) 2003-06-25 04:55:38 PDT
I did a quick test with the patch, and so far everything looks good. Al my tries
to paste something succeeded (in the browser, in mailnews compose, and in
composer), and quitting mozilla is no problem.
I will leave the patch in my test build, and let you know when I see problems.
Comment 88 Christian :Biesinger (don't email me, ping me on IRC) 2003-06-30 12:57:18 PDT
Comment on attachment 93030 [details] [diff] [review]
Better solution

clearing this review request as there are newer patches
Comment 89 Boris Zbarsky [:bz] (still a bit busy) 2003-07-11 11:09:59 PDT
*** Bug 212424 has been marked as a duplicate of this bug. ***
Comment 90 Jo Hermans 2003-07-13 03:38:03 PDT
*** Bug 182596 has been marked as a duplicate of this bug. ***
Comment 91 Joshua Mostafa 2003-07-23 21:17:49 PDT
Just to add my 2c:

I'm running Firebird 0.6 on Mandrake 9.0 with KDE 3.0. I use ActiveState's
Komodo text editor (based on the Gecko engine), it's based on the Gecko engine.

I also found that I can't paste any sizable amount of text - more than about a
page - between these apps. To get the text across I have to paste into KEdit or
some other app, then copy again and paste into Firebird.

Weird - especially since Komodo and Firebird are both Mozilla-based apps .. :S
Comment 92 Louie Zhao 2003-07-23 21:56:10 PDT
> Weird - especially since Komodo and Firebird are both Mozilla-based apps .. :S
This bug will happen when copy-paste between 2 running mozilla. So komodo and
Firebird will also has this issue.
Comment 93 Asa Dotzler [:asa] 2003-07-27 19:06:27 PDT
mozilla1.4 shipped. unsetting blocking1.4 request.
Comment 94 Andrew Schultz 2003-08-02 20:36:06 PDT
*** Bug 214856 has been marked as a duplicate of this bug. ***
Comment 95 chris hofmann 2003-08-07 10:17:35 PDT
pav/blizzard, can we knock this one out for 1.5?
Comment 96 Stuart Parmenter 2003-08-07 10:26:37 PDT
yes, I'll test this in the next day or two to make sure there are no extra problems
Comment 97 chris hofmann 2003-08-18 13:47:29 PDT
any update?
Comment 98 Andrew Schultz 2003-08-21 04:48:42 PDT
*** Bug 216839 has been marked as a duplicate of this bug. ***
Comment 99 Asa Dotzler [:asa] 2003-08-25 17:07:35 PDT
Too late for beta, not final material, -> 1.6a (with Stuart's consent).
Comment 100 Brian Ryner (not reading) 2003-08-29 20:02:46 PDT
Comment on attachment 126444 [details] [diff] [review]
patch v3

I think this patch would introduce event reentrancy problems such as bug 214583
to the gtk1 port.
Comment 101 Michiel van Leeuwen (email: mvl+moz@) 2003-09-09 12:33:12 PDT
*** Bug 218702 has been marked as a duplicate of this bug. ***
Comment 102 Boris Zbarsky [:bz] (still a bit busy) 2003-12-03 23:10:48 PST
*** Bug 169244 has been marked as a duplicate of this bug. ***
Comment 103 Asa Dotzler [:asa] 2004-01-29 14:13:09 PST
Bryner says he might know of a way to fix this without introducing the event
reentrancy problems for GTK1.
Comment 104 Brian Ryner (not reading) 2004-01-29 18:26:11 PST
Created attachment 140213 [details] [diff] [review]
backport of gtk2 patch

This is an adaptation of the changes we made for gtk2 to fix this.  The key
change is that we must dispatch PropertyNotify events with atom ==
GDK_SELECTION to the clipboard widget in order for INCR selection retrieval to
work.

I also removed some unused code, including SendClipPing (which seems to be the
only reason we were also processing ClientMessage events).
Comment 105 Christopher Blizzard (:blizzard) 2004-02-02 11:16:31 PST
Comment on attachment 140213 [details] [diff] [review]
backport of gtk2 patch

If you're going to use select() you're going to have to use the code that's in
XRemoteClient.cpp due to VMS differences.  Just have a look there - you should
be able to cut and paste.
Comment 106 Asa Dotzler [:asa] 2004-02-02 12:54:57 PST
bryner, we're going to be coming up on 1.7 Alpha pretty quickly (10 days). Is
this the kind of change we should try to squeeze in for alpha, to get the extra
release worth of exposure, or should we try to get it in first thing in Beta and
have a full cycle of nightly builds to test?
Comment 107 Brian Ryner (not reading) 2004-02-02 18:17:33 PST
Created attachment 140466 [details] [diff] [review]
backport of gtk2 patch

Copy the VMS #ifdefs from xremote, and merge the same fix onto gtk2.
Comment 108 Roland Mainz 2004-02-06 16:10:06 PST
bryner:
Is it possible that this has caused bug 233317 ("Cannot paste from clipboard")?
Comment 109 Bryce Mozilla Nesbitt 2004-02-07 10:47:42 PST
Please test with Open Office cut & paste.  That's where it was most broken before.
Comment 110 Leston Buell 2004-02-07 19:00:23 PST
I have tested pasting into Mozilla 1.6 and a build from yesterday on Linux.
Pasting from OpenOffice.org doesn't work with 1.6 but does work with the new
build. So, the patch works.

Thanks for getting this fixed!
Comment 111 Brian Ryner (not reading) 2004-02-09 14:46:38 PST
marking as fixed.
Comment 112 Mike Kaply [:mkaply] 2004-03-02 11:02:03 PST
Comment on attachment 126444 [details] [diff] [review]
patch v3

This is fixed, so I'm assuming this review request is obsolete.
Comment 113 Roland Mainz 2004-03-02 12:51:35 PST
Bryner:
We should back this patch out. More and more people are complaining in the
newsgroups and bugzilla (see bug 233317) that clipboard is now defunct and
triggers crashes on all Unix platforms (I've seen reports for Solaris and HP-UX
right now).
Comment 114 timeless 2004-03-07 23:23:50 PST
*** Bug 223705 has been marked as a duplicate of this bug. ***
Comment 115 beanladen 2004-03-14 16:58:51 PST
Bryner:
This fix is poisened, please back this one out, it causes a regression on Unix
builds (crashes on clipboard use), see bug 233317.
Having a problem with more than 4000 bytes is not as severe as having a crash
with a few bytes.
Comment 116 Brendan Eich [:brendan] 2004-03-14 21:02:49 PST
We need a volunteer on Solaris or HP-UX to reproduce this, work with bryner via
IRC, and get it debugged.  Roland, anyone?

/be
Comment 117 Roland Mainz 2004-03-14 21:26:56 PST
Brendan Eich wrote:
> We need a volunteer on Solaris or HP-UX to reproduce this, work with bryner 
> via IRC, and get it debugged.  Roland, anyone?

I can't help this week, still sick... ;-(
BTW: There are at two Solaris 2.8 tinderbox machines at Seakmonkey-Ports
("worms" and "speedracer") which may be useable for debugging. Or ask timeless
Comment 118 timeless 2004-03-14 22:11:19 PST
brendan: no you don't.

bug 233317 comment 29:
> I'm not running CDE on Solaris and this problem persists until the other 
change is backed out. 
> This happens with Xvnc (not Xsun) and fvwm2.
Comment 119 Brendan Eich [:brendan] 2004-03-14 23:06:07 PST
timeless: try to say more than "no you don't", presumably in reply to my call
for a volunteer on Solaris or HP-UX.  I can trade cryptic bug comment references
as well: http://bugzilla.mozilla.org/show_bug.cgi?id=233317#c33.

You're not adding value here.  We need someone who can reproduce the problem
working with bryner to debug it, period, end of story.  Lead, follow, or get out
of the way.  Carping inaccurately and cryptically doesn't help..

/be
Comment 120 Jürgen Keil 2004-03-16 08:06:57 PST
There a problem with the "backport of gtk2 patch"
<URL:http://bugzilla.mozilla.org/attachment.cgi?id=140466&action=view>:

+  int cnumber = ConnectionNumber(xDisplay);
+  fd_set select_set;
+  FD_ZERO(&select_set);
+  FD_SET(cnumber++, &select_set);
...
+    select_result = select(cnumber, &select_set, NULL, NULL, &tv);


On Solaris, FD_SET() is implemented as a macro, and the first parameter is
evaluated multiple times.  So you're not allowed to use macro arguments with
sideeffects (the ++ part of cnumber++), or you're getting bogus behaviour.

(On Solaris, the connection to the X server is file descriptor 3, but we end
up selecting on filedescriptor 4, which happens to be a DOOR file descriptor
to the nscd server, and a DOOR cannot be used with the select/poll system
call, so the select/poll always fails)


After changing the code like this...

+  FD_SET(cnumber, &select_set);
...
+    select_result = select(cnumber+1, &select_set, NULL, NULL, &tv);


... the put&paste problems on Solaris seem to be gone!
Comment 121 David Baron :dbaron: ⌚️UTC-8 2004-03-16 09:27:50 PST
That seems like a logical explanation, although I'm a little puzzled by the fact
that the first argument is evaluated twice on Linux as well (at least on my
Fedora Core 1 system).
Comment 122 David Baron :dbaron: ⌚️UTC-8 2004-03-16 09:38:38 PST
Created attachment 144051 [details] [diff] [review]
patch to avoid ++ inside macro

This doesn't seem to cause any problems on Linux -- perhaps the Linux
implementation of select doesn't care if its first parameter is too large.
Comment 123 Jürgen Keil 2004-03-16 09:52:35 PST
Created attachment 144052 [details]
FD_SET testcase

The FD_SET testcase attachment reproduces the problem for me.

When I compile it on Solaris using Sun's Forte compiler with optimization, the
bit for FD 4 is set (*not* FD 3, as you might expect)

% cc -O -o sel sel.c
% sel
bit for FD#4 is set
i=5

Compiling the testcase with gcc and -O shows different behaviour:

% gcc -O -o sel sel.c
% sel
bit for FD#3 is set
i=5

Note that in both cases, the macro argument 'i' is incremented by two (and not
one).

It wouldn't surprise me if different gcc versions, or the same gcc version on
different cpu architectures shows similar behaviour.
Comment 124 chris hofmann 2004-03-16 13:06:48 PST
Comment on attachment 144051 [details] [diff] [review]
patch to avoid ++ inside macro

a=chofmann for 1.7b
Comment 125 David Baron :dbaron: ⌚️UTC-8 2004-03-16 13:09:23 PST
Comment on attachment 144051 [details] [diff] [review]
patch to avoid ++ inside macro

Checked in to trunk, 2004-03-16 13:08 -0800.
Comment 126 David Baron :dbaron: ⌚️UTC-8 2004-03-16 13:10:46 PST
Comment on attachment 144051 [details] [diff] [review]
patch to avoid ++ inside macro

And thanks to Jürgen Keil for figuring out the problem.  (...who I forgot to
cite in the checkin comment after chofmann told me to check in immediately.)

Note You need to log in before you can comment on or make changes to this bug.