[Linux] Can't paste over 4000 bytes from another app into mozilla

RESOLVED FIXED in mozilla1.6alpha



19 years ago
8 years ago


(Reporter: spam, Assigned: bryner)


(Depends on 1 bug, {dataloss, helpwanted, platform-parity})

Dependency tree / graph
Bug Flags:
blocking1.3a -
blocking1.4b -
blocking1.5b -

Firefox Tracking Flags

(Not tracked)



(7 attachments, 5 obsolete attachments)



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

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

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?
Assignee: beppe → akkana

Comment 2

19 years ago
Cc jfrancis@netscape.com since he was involved in some recent copy/paste

Comment 3

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

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

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

19 years ago
Also cc jst in case it's a noxif bug.

Comment 7

19 years ago
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?
Looks like a GTK clipboard issue. Over to pavlov.
Assignee: akkana → pavlov
Component: Editor → XP Toolkit/Widgets

Comment 9

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

19 years ago
Adding akkana@netscape.com back to the Cc list.

Comment 11

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

19 years ago
futuring...  I know what is causing this, but the fix isn't trivial... maybe we
can fix this for mozilla 1.0
Target Milestone: --- → Future

Comment 13

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

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

19 years ago
I really want to fix this.  This bug angers me.
Target Milestone: Future → mozilla0.9

Comment 16

19 years ago
uncc'ing me
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

19 years ago
i don't have any problem pasting from gedit..  i don't have abiword, although i
guess i could try it and see.


18 years ago
Target Milestone: mozilla0.9 → mozilla1.0

Comment 19

18 years ago
so.. does this depend on bug 84973?
I still can't paste over 4000 byte to moz from any editor i use.

Comment 20

18 years ago
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 
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 
Target Milestone: mozilla1.0 → mozilla1.0.1

Comment 22

18 years ago
*** Bug 114968 has been marked as a duplicate of this bug. ***

Comment 23

18 years ago
Please check Netscape 4.77 source, where this bug doesn't exist.
See also [Bug 114968] New: paste of larger text impossible


18 years ago
Blocks: 115259

Comment 24

17 years ago
Noone has mentioned it AFAI can see, but this bug affects pasting everywhere in
Mozilla, not only in the Composer. *EXTREMELY* annoying and *EXTREMELY*

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

17 years ago
Nominating for nsbeta1.
Keywords: nsbeta1

Comment 26

17 years ago
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.
Keywords: helpwanted, pp
Summary: Can't paste over 4000 bytes in composer → [Linux] Can't copy / paste over 4000 bytes in composer

Comment 27

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

17 years ago
clarify summary based on comment 27
Summary: [Linux] Can't copy / paste over 4000 bytes in composer → [Linux] Can't paste over 4000 bytes from another app into mozilla

Comment 29

17 years ago
brade: To clarify mair's comment with respect to your question, there is no
truncation going on. Pasting just *doesn't work*.


17 years ago
Keywords: nsbeta1nsbeta1-
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.
Blocks: 144260

Comment 31

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

17 years ago
*** Bug 150173 has been marked as a duplicate of this bug. ***

Comment 33

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

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

17 years ago
Similarly, SpamCop is mostly unusable from Mozilla because of this.
*** Bug 158067 has been marked as a duplicate of this bug. ***

Comment 37

17 years ago
not yet fixed in 

Mozilla 1.1b
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1b) Gecko/20020722

Comment 38

17 years ago
Posted patch Proposed patch (obsolete) — Splinter Review
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

17 years ago
The patch is against Mozilla 1.1b source.


17 years ago
Keywords: patch

Comment 40

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

17 years ago
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.
Attachment #92812 - Attachment is obsolete: true

Comment 42

17 years ago
This patch should also (help to) fix bug 83024 (I cannot measure that, though).

Comment 43

17 years ago
*** Bug 161419 has been marked as a duplicate of this bug. ***
*** Bug 166136 has been marked as a duplicate of this bug. ***
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.
*** Bug 158052 has been marked as a duplicate of this bug. ***

Comment 47

17 years ago
Patch is needed ASAP.
This bug makes mozilla unusable for most of content managment systems (CMS).

Comment 48

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


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

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

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


17 years ago
Keywords: mozilla1.3

Comment 51

17 years ago
*** Bug 182553 has been marked as a duplicate of this bug. ***

Comment 52

17 years ago
not yet fixed in

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

Comment 53

17 years ago
This is a very important bug. You should try to correct it before releasing any


17 years ago
Flags: blocking1.3a?


17 years ago
Flags: blocking1.3a? → blocking1.3a-


17 years ago
Attachment #93030 - Flags: review?
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

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.)

mgabriel: try requesting the review from a specific person... like blizzard

Comment 57

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

Comment 58

17 years ago
I don't think it's a blocker, but it does meet the terms of critical since there
is dataloss.
Severity: normal → critical
Keywords: dataloss
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.
Attachment #93030 - Flags: review? → review?(blizzard)

Comment 60

17 years ago
*** Bug 190977 has been marked as a duplicate of this bug. ***

Comment 61

17 years ago
Bug 190977 claims that the reverse doesn't work either (copying from Mozilla
into another app).

Comment 62

17 years ago
yup, it (copy/paste to a different program) doesn't work for me (see comment 31)

Comment 63

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

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

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

17 years ago

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

16 years ago

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!
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

16 years ago
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.


16 years ago
Flags: blocking1.4b?
Keywords: mozilla1.3


16 years ago
Flags: blocking1.4b? → blocking1.4b-
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.


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


------- 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

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

16 years ago
*** Bug 205823 has been marked as a duplicate of this bug. ***
*** Bug 208858 has been marked as a duplicate of this bug. ***

Comment 74

16 years ago
Posted patch working patch (obsolete) — Splinter Review
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

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

Thanks very much.
Attachment #125490 - Flags: review?(blizzard)
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

16 years ago
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.
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.
Posted file 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

16 years ago
Posted patch updated patch for trunk (obsolete) — Splinter Review
Attachment #125490 - Attachment is obsolete: true


16 years ago
Attachment #125490 - Flags: review?(blizzard)


16 years ago
Attachment #125735 - Flags: review?(blizzard)

Comment 81

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

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

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

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 on attachment 125735 [details] [diff] [review]
updated patch for trunk

can you use diff -u please?
Attachment #125735 - Flags: review?(blizzard) → review-

Comment 84

16 years ago
Posted patch updated patch using diff -u (obsolete) — Splinter Review
same to previous one, using diff -u instead
Attachment #125735 - Attachment is obsolete: true


16 years ago
Attachment #126099 - Flags: review?(blizzard)


16 years ago
Flags: blocking1.4?

Comment 85

16 years ago
*** Bug 210473 has been marked as a duplicate of this bug. ***

Comment 86

16 years ago
Posted patch patch v3Splinter Review
I found the way to reproduce Michiel's problem. It happens in the circumstance

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.
Attachment #126099 - Attachment is obsolete: true


16 years ago
Attachment #126099 - Flags: review?(blizzard)
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.


16 years ago
Attachment #126444 - Flags: review?(blizzard)
Comment on attachment 93030 [details] [diff] [review]
Better solution

clearing this review request as there are newer patches
Attachment #93030 - Flags: review?(blizzard)
*** Bug 212424 has been marked as a duplicate of this bug. ***

Comment 90

16 years ago
*** Bug 182596 has been marked as a duplicate of this bug. ***

Comment 91

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

16 years ago
> 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.
mozilla1.4 shipped. unsetting blocking1.4 request.
Flags: blocking1.4? → blocking1.5b?

Comment 94

16 years ago
*** Bug 214856 has been marked as a duplicate of this bug. ***

Comment 95

16 years ago
pav/blizzard, can we knock this one out for 1.5?

Comment 96

16 years ago
yes, I'll test this in the next day or two to make sure there are no extra problems

Comment 97

16 years ago
any update?

Comment 98

16 years ago
*** Bug 216839 has been marked as a duplicate of this bug. ***
Too late for beta, not final material, -> 1.6a (with Stuart's consent).
Flags: blocking1.5b? → blocking1.5b-
Target Milestone: mozilla1.0.1 → mozilla1.6alpha

Comment 100

16 years ago
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.
*** Bug 218702 has been marked as a duplicate of this bug. ***


16 years ago
Flags: blocking1.6a?


16 years ago
Blocks: majorbugs
*** Bug 169244 has been marked as a duplicate of this bug. ***


16 years ago
Flags: blocking1.7a?
Bryner says he might know of a way to fix this without introducing the event
reentrancy problems for GTK1.
Assignee: pavlov → bryner

Comment 104

16 years ago
Posted patch backport of gtk2 patch (obsolete) — Splinter Review
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

I also removed some unused code, including SendClipPing (which seems to be the
only reason we were also processing ClientMessage events).


16 years ago
Attachment #140213 - Flags: superreview?(blizzard)
Attachment #140213 - Flags: review?(blizzard)
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.
Attachment #140213 - Flags: superreview?(blizzard)
Attachment #140213 - Flags: superreview-
Attachment #140213 - Flags: review?(blizzard)
Attachment #140213 - Flags: review-
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

16 years ago
Copy the VMS #ifdefs from xremote, and merge the same fix onto gtk2.
Attachment #140213 - Attachment is obsolete: true


16 years ago
Attachment #140466 - Flags: superreview?(blizzard)
Attachment #140466 - Flags: review?(blizzard)
Attachment #140466 - Flags: superreview?(blizzard)
Attachment #140466 - Flags: superreview+
Attachment #140466 - Flags: review?(blizzard)
Attachment #140466 - Flags: review+

Comment 108

16 years ago
Is it possible that this has caused bug 233317 ("Cannot paste from clipboard")?
Please test with Open Office cut & paste.  That's where it was most broken before.

Comment 110

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

16 years ago
marking as fixed.
Last Resolved: 16 years ago
Resolution: --- → FIXED


16 years ago
Flags: blocking1.7a?
Comment on attachment 126444 [details] [diff] [review]
patch v3

This is fixed, so I'm assuming this review request is obsolete.
Attachment #126444 - Flags: review?(blizzard)

Comment 113

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

15 years ago
*** Bug 223705 has been marked as a duplicate of this bug. ***

Comment 115

15 years ago
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.
We need a volunteer on Solaris or HP-UX to reproduce this, work with bryner via
IRC, and get it debugged.  Roland, anyone?


Comment 117

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

15 years ago
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.
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..


Comment 120

15 years ago
There a problem with the "backport of gtk2 patch"

+  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!
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).
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

15 years ago
Posted file 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

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

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

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

It wouldn't surprise me if different gcc versions, or the same gcc version on
different cpu architectures shows similar behaviour.
Attachment #144051 - Flags: superreview?(bryner)
Attachment #144051 - Flags: review?(bryner)
Attachment #144051 - Flags: approval1.7b?


15 years ago
Attachment #144051 - Flags: superreview?(bryner)
Attachment #144051 - Flags: superreview+
Attachment #144051 - Flags: review?(bryner)
Attachment #144051 - Flags: review+

Comment 124

15 years ago
Comment on attachment 144051 [details] [diff] [review]
patch to avoid ++ inside macro

a=chofmann for 1.7b
Attachment #144051 - Flags: approval1.7b? → approval1.7b+
Comment on attachment 144051 [details] [diff] [review]
patch to avoid ++ inside macro

Checked in to trunk, 2004-03-16 13:08 -0800.
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.)


14 years ago
No longer blocks: majorbugs
You need to log in before you can comment on or make changes to this bug.