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

Status: RESOLVED FIXED

(Core :: XUL, defect, P3)

Description

[R.K.Aa.]

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]

Reassign to [e-mail].

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]

Cc [e-mail] since he was involved in some recent copy/paste
modifications.

Comment 3

[R.K.Aa.]

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]

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]

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]

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

Comment 7

[Akkana Peck]

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 [no longer active]]

Looks like a GTK clipboard issue. Over to pavlov.

Comment 9

[kinmoz]

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]

Adding [e-mail] back to the Cc list.

Comment 11

[Stuart Parmenter]

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]

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

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]

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]

I really want to fix this.  This bug angers me.

Comment 16

[Joe Francis]

uncc'ing me

Comment 17

[Christian Schaller]

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]

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

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]

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

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

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

Comment 23

[János Holányi]

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]

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]

Nominating for nsbeta1.

Comment 26

[Kathleen :Brade]

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]

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]

clarify summary based on comment 27

Comment 29

[Braden]

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

Comment 30

[[e-mail]]

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]

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]

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

Comment 33

[Toni Willberg]

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]

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]

Similarly, SpamCop is mostly unusable from Mozilla because of this.

Comment 36

[Ere Maijala (slow)]

*** Bug 158067 has been marked as a duplicate of this bug. ***

Comment 37

[Igor Furlan]

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]

Attachment: 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]

The patch is against Mozilla 1.1b source.

Comment 40

[Stuart Parmenter]

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]

Attachment: 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]

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

Comment 43

[R.K.Aa.]

*** Bug 161419 has been marked as a duplicate of this bug. ***

Comment 44

[Boris Zbarsky [:bzbarsky]]

*** Bug 166136 has been marked as a duplicate of this bug. ***

Comment 45

[Christopher Blizzard (:blizzard)]

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

*** Bug 158052 has been marked as a duplicate of this bug. ***

Comment 47

[Andraz Tori]

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

Comment 48

[Igor Furlan]

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]

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]

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

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

Comment 52

[Igor Furlan]

not yet fixed in

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

Comment 53

[tirantloblanc]

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

Comment 54

[Eli K. Breen - ActiveState]

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]

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

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

Comment 57

[Toni Willberg]

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]

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

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]

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

Comment 61

[Jo Hermans]

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

Comment 62

[alge]

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

Comment 63

[Bartosz Wucke]

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]

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]

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]

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]

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@)]

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]

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]

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

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]

*** Bug 205823 has been marked as a duplicate of this bug. ***

Comment 73

[Boris Zbarsky [:bzbarsky]]

*** Bug 208858 has been marked as a duplicate of this bug. ***

Comment 74

[Louie Zhao]

Attachment: 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]

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@)]

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]

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@)]

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@)]

Attachment: 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]

Attachment: updated patch for trunk

Comment 81

[Louie Zhao]

Attachment: 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]

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

Comment on attachment 125735 [details] [diff] [review]
updated patch for trunk

can you use diff -u please?

Comment 84

[Louie Zhao]

Attachment: updated patch using diff -u

same to previous one, using diff -u instead

Comment 85

[Jo Hermans]

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

Comment 86

[Louie Zhao]

Attachment: 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@)]

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

Comment on attachment 93030 [details] [diff] [review]
Better solution

clearing this review request as there are newer patches

Comment 89

[Boris Zbarsky [:bzbarsky]]

*** Bug 212424 has been marked as a duplicate of this bug. ***

Comment 90

[Jo Hermans]

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

Comment 91

[Joshua Mostafa]

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]

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

mozilla1.4 shipped. unsetting blocking1.4 request.

Comment 94

[Andrew Schultz]

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

Comment 95

[chris hofmann]

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

Comment 96

[Stuart Parmenter]

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

Comment 97

[chris hofmann]

any update?

Comment 98

[Andrew Schultz]

*** Bug 216839 has been marked as a duplicate of this bug. ***

Comment 99

[Asa Dotzler [:asa]]

Too late for beta, not final material, -> 1.6a (with Stuart's consent).

Comment 100

[Brian Ryner (not reading)]

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@)]

*** Bug 218702 has been marked as a duplicate of this bug. ***

Comment 102

[Boris Zbarsky [:bzbarsky]]

*** Bug 169244 has been marked as a duplicate of this bug. ***

Comment 103

[Asa Dotzler [:asa]]

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

Attachment: 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)]

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

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

Attachment: backport of gtk2 patch

Copy the VMS #ifdefs from xremote, and merge the same fix onto gtk2.

Comment 108

[Roland Mainz]

bryner:
Is it possible that this has caused bug 233317 ("Cannot paste from clipboard")?

Comment 109

[Bryce Mozilla Nesbitt]

Please test with Open Office cut & paste.  That's where it was most broken before.

Comment 110

[Leston Buell]

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

marking as fixed.

Comment 112

[Mike Kaply [:mkaply]]

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]

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]

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

Comment 115

[beanladen]

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

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]

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]

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

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]

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-4, no longer working on Mozilla)]

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-4, no longer working on Mozilla)]

Attachment: 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]

Attachment: 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]

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

a=chofmann for 1.7b

Comment 125

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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-4, no longer working on Mozilla)]

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