Closed
Bug 56219
Opened 24 years ago
Closed 21 years ago
[Linux] Can't paste over 4000 bytes from another app into mozilla
Categories
(Core :: XUL, defect, P3)
Tracking
()
RESOLVED
FIXED
mozilla1.6alpha
People
(Reporter: spam, Assigned: bryner)
References
(Depends on 1 open bug)
Details
(Keywords: dataloss, helpwanted, platform-parity)
Attachments
(7 files, 5 obsolete files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
application/octet-stream
|
Details | |
(deleted),
text/plain
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
blizzard
:
review+
blizzard
:
superreview+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
bryner
:
review+
bryner
:
superreview+
chofmann
:
approval1.7b+
|
Details | Diff | Splinter Review |
(deleted),
text/plain
|
Details |
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.
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?
Assignee: beppe → akkana
Cc jfrancis@netscape.com since he was involved in some recent copy/paste
modifications.
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.
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.
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•24 years ago
|
||
Also cc jst in case it's a noxif bug.
Comment 7•24 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?
Comment 8•24 years ago
|
||
Looks like a GTK clipboard issue. Over to pavlov.
Assignee: akkana → pavlov
Component: Editor → XP Toolkit/Widgets
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•24 years ago
|
||
Adding akkana@netscape.com back to the Cc list.
Comment 11•24 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•24 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
Reporter | ||
Comment 13•24 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•24 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•24 years ago
|
||
I really want to fix this. This bug angers me.
Status: NEW → ASSIGNED
Target Milestone: Future → mozilla0.9
Comment 16•24 years ago
|
||
uncc'ing me
Comment 17•24 years ago
|
||
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•24 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.
Updated•24 years ago
|
Target Milestone: mozilla0.9 → mozilla1.0
Reporter | ||
Comment 19•24 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•24 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
syncronously...
Comment 21•23 years ago
|
||
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)
Target Milestone: mozilla1.0 → mozilla1.0.1
Reporter | ||
Comment 22•23 years ago
|
||
*** Bug 114968 has been marked as a duplicate of this bug. ***
Comment 23•23 years ago
|
||
Please check Netscape 4.77 source, where this bug doesn't exist.
See also [Bug 114968] New: paste of larger text impossible
Comment 24•23 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*
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 26•23 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•23 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•23 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•23 years ago
|
||
brade: To clarify mair's comment with respect to your question, there is no
truncation going on. Pasting just *doesn't work*.
Comment 30•23 years ago
|
||
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•23 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•23 years ago
|
||
*** Bug 150173 has been marked as a duplicate of this bug. ***
Comment 33•23 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•22 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•22 years ago
|
||
Similarly, SpamCop is mostly unusable from Mozilla because of this.
Comment 36•22 years ago
|
||
*** Bug 158067 has been marked as a duplicate of this bug. ***
Comment 37•22 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•22 years ago
|
||
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•22 years ago
|
||
The patch is against Mozilla 1.1b source.
Comment 40•22 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•22 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•22 years ago
|
||
This patch should also (help to) fix bug 83024 (I cannot measure that, though).
Reporter | ||
Comment 43•22 years ago
|
||
*** Bug 161419 has been marked as a duplicate of this bug. ***
Comment 44•22 years ago
|
||
*** Bug 166136 has been marked as a duplicate of this bug. ***
Comment 45•22 years ago
|
||
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•22 years ago
|
||
*** Bug 158052 has been marked as a duplicate of this bug. ***
Comment 47•22 years ago
|
||
Patch is needed ASAP.
This bug makes mozilla unusable for most of content managment systems (CMS).
Comment 48•22 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
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•22 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•22 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
Updated•22 years ago
|
Keywords: mozilla1.3
Reporter | ||
Comment 51•22 years ago
|
||
*** Bug 182553 has been marked as a duplicate of this bug. ***
Comment 52•22 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•22 years ago
|
||
This is a very important bug. You should try to correct it before releasing any
release.
Updated•22 years ago
|
Flags: blocking1.3a?
Updated•22 years ago
|
Flags: blocking1.3a? → blocking1.3a-
Updated•22 years ago
|
Attachment #93030 -
Flags: review?
Comment 54•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
mgabriel: try requesting the review from a specific person... like blizzard
Comment 57•22 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
magic.
Comment 58•22 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 59•22 years ago
|
||
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•22 years ago
|
||
*** Bug 190977 has been marked as a duplicate of this bug. ***
Comment 61•22 years ago
|
||
Bug 190977 claims that the reverse doesn't work either (copying from Mozilla
into another app).
Comment 62•22 years ago
|
||
yup, it (copy/paste to a different program) doesn't work for me (see comment 31)
Comment 63•22 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•22 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•22 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•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
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•22 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.
Updated•22 years ago
|
Flags: blocking1.4b?
Keywords: mozilla1.3
Updated•22 years ago
|
Flags: blocking1.4b? → blocking1.4b-
Comment 70•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
*** Bug 205823 has been marked as a duplicate of this bug. ***
Comment 73•22 years ago
|
||
*** Bug 208858 has been marked as a duplicate of this bug. ***
Comment 74•22 years ago
|
||
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•22 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
implementation.
Thanks very much.
Attachment #125490 -
Flags: review?(blizzard)
Comment 76•22 years ago
|
||
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•21 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.
Comment 78•21 years ago
|
||
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•21 years ago
|
||
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•21 years ago
|
||
Attachment #125490 -
Attachment is obsolete: true
Updated•21 years ago
|
Attachment #125490 -
Flags: review?(blizzard)
Updated•21 years ago
|
Attachment #125735 -
Flags: review?(blizzard)
Comment 81•21 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
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•21 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
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•21 years ago
|
||
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•21 years ago
|
||
same to previous one, using diff -u instead
Attachment #125735 -
Attachment is obsolete: true
Updated•21 years ago
|
Attachment #126099 -
Flags: review?(blizzard)
Updated•21 years ago
|
Flags: blocking1.4?
Comment 85•21 years ago
|
||
*** Bug 210473 has been marked as a duplicate of this bug. ***
Comment 86•21 years ago
|
||
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.
Attachment #126099 -
Attachment is obsolete: true
Updated•21 years ago
|
Attachment #126099 -
Flags: review?(blizzard)
Comment 87•21 years ago
|
||
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.
Updated•21 years ago
|
Attachment #126444 -
Flags: review?(blizzard)
Comment 88•21 years ago
|
||
Comment on attachment 93030 [details] [diff] [review]
Better solution
clearing this review request as there are newer patches
Attachment #93030 -
Flags: review?(blizzard)
Comment 89•21 years ago
|
||
*** Bug 212424 has been marked as a duplicate of this bug. ***
Comment 90•21 years ago
|
||
*** Bug 182596 has been marked as a duplicate of this bug. ***
Comment 91•21 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•21 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.
Comment 93•21 years ago
|
||
mozilla1.4 shipped. unsetting blocking1.4 request.
Flags: blocking1.4? → blocking1.5b?
Comment 94•21 years ago
|
||
*** Bug 214856 has been marked as a duplicate of this bug. ***
Comment 95•21 years ago
|
||
pav/blizzard, can we knock this one out for 1.5?
Comment 96•21 years ago
|
||
yes, I'll test this in the next day or two to make sure there are no extra problems
Comment 97•21 years ago
|
||
any update?
Comment 98•21 years ago
|
||
*** Bug 216839 has been marked as a duplicate of this bug. ***
Comment 99•21 years ago
|
||
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
Assignee | ||
Comment 100•21 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.
Comment 101•21 years ago
|
||
*** Bug 218702 has been marked as a duplicate of this bug. ***
Updated•21 years ago
|
Flags: blocking1.6a?
Comment 102•21 years ago
|
||
*** Bug 169244 has been marked as a duplicate of this bug. ***
Updated•21 years ago
|
Flags: blocking1.7a?
Comment 103•21 years ago
|
||
Bryner says he might know of a way to fix this without introducing the event
reentrancy problems for GTK1.
Assignee: pavlov → bryner
Status: ASSIGNED → NEW
Assignee | ||
Comment 104•21 years ago
|
||
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).
Assignee | ||
Updated•21 years ago
|
Attachment #140213 -
Flags: superreview?(blizzard)
Attachment #140213 -
Flags: review?(blizzard)
Comment 105•21 years ago
|
||
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-
Comment 106•21 years ago
|
||
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?
Assignee | ||
Comment 107•21 years ago
|
||
Copy the VMS #ifdefs from xremote, and merge the same fix onto gtk2.
Attachment #140213 -
Attachment is obsolete: true
Assignee | ||
Updated•21 years ago
|
Attachment #140466 -
Flags: superreview?(blizzard)
Attachment #140466 -
Flags: review?(blizzard)
Updated•21 years ago
|
Attachment #140466 -
Flags: superreview?(blizzard)
Attachment #140466 -
Flags: superreview+
Attachment #140466 -
Flags: review?(blizzard)
Attachment #140466 -
Flags: review+
Comment 108•21 years ago
|
||
bryner:
Is it possible that this has caused bug 233317 ("Cannot paste from clipboard")?
Comment 109•21 years ago
|
||
Please test with Open Office cut & paste. That's where it was most broken before.
Comment 110•21 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!
Assignee | ||
Comment 111•21 years ago
|
||
marking as fixed.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Updated•21 years ago
|
Flags: blocking1.7a?
Comment 112•21 years ago
|
||
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•21 years ago
|
||
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•21 years ago
|
||
*** Bug 223705 has been marked as a duplicate of this bug. ***
Comment 115•21 years ago
|
||
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•21 years ago
|
||
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•21 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•21 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.
Comment 119•21 years ago
|
||
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•21 years ago
|
||
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•21 years ago
|
||
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•21 years ago
|
||
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•21 years ago
|
||
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.
Updated•21 years ago
|
Attachment #144051 -
Flags: superreview?(bryner)
Attachment #144051 -
Flags: review?(bryner)
Attachment #144051 -
Flags: approval1.7b?
Assignee | ||
Updated•21 years ago
|
Attachment #144051 -
Flags: superreview?(bryner)
Attachment #144051 -
Flags: superreview+
Attachment #144051 -
Flags: review?(bryner)
Attachment #144051 -
Flags: review+
Comment 124•21 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 125•21 years ago
|
||
Comment on attachment 144051 [details] [diff] [review]
patch to avoid ++ inside macro
Checked in to trunk, 2004-03-16 13:08 -0800.
Comment 126•21 years ago
|
||
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.)
You need to log in
before you can comment on or make changes to this bug.
Description
•