2004-02-05-21-trunk on Solaris2.8/SPARC and in today's Linux nightly. Pasting from clipboard is no longer working. Steps to reproduce: 1. Open Nedit and copy text to clipboard 2. Open WWW page with a form widget or use chatzilla 3. Paste text via menu (or via the "Paste" key on Sun's keyboard) Result: Nothing happens Expected result: Text should be pasted to the widget

Is Nedit the only program that shows this problem? I have tested the Linux nightly (on Mandrake 9.1), and i can't reproduce the problem pasting from jEdit, Konqueror, or Konsole into a Mozilla textfield. Unfortunately, i don't have Nedit to test it.

So far I can reproduce this with all CDE and Motif2-based applications (e.g. cut/copy from Motif2 application, paste into Mozilla). I didn't test Qt/KDE applications yet...

this worksforme with linux trunk 2004020607 Roland: have you tried backing out the patch from bug 56219?

Not a blocker.

Is this related to bug 233255 or vice versa?

I have this problem using Mozilla 1.6, RedHat 9, and KDE. (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113) 1. Cutting and pasting among other applications (not involving Mozilla) is working as expected. 2. X-windows level pasting works to paste from another window into to Mozilla (highlight, then paste with mouse button-2). 3. Putting text on the clipboard from a non-Mozilla application (e.g. Xemacs) and using Mozilla's Edit/Paste or CTRL-V into a web form or a mail message body does not work: no pasted text appears. 4. I can "copy" (CTRL-C) text being viewed in a Mozilla window and then paste it (CTRL-V) into a Mozilla (or other application) window. But I can't copy from another app and paste into Mozilla.

After more investigation it seems the behavior description in in comment #6 isn't quite accurate, and the paste problem I have is specific to the mail-news composition window (message body) only. I can copy and paste from almost any application into Mozilla text fields, URL fields, mail address fields, and mail subject lines, but not into the mail composition message body under certain specific circumstances. See bug 233556 for the details.

No one else has reproduced this. Not a blocker.

as of mozilla 1.7a (both Solaris 2.8/SPARC contrib builds) i'm seeing the same behavior as mentioned in comment 6, with the exception that his case 2 doesn't work for me: there's no way to paste into mozilla from external windows. copying from mozilla works fine, and pasting text selected within mozilla works fine. possibly due to bug 56219? everything worked fine in 1.6 final.

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

Mats: only drivers can set (+) blocking flags. You can request (?) them (like Roland did).

Hmmm mouse slipping...

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

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

I see this on 1.7a Solaris Sparc (Sun contributed) Solaris 8. The following detail may be of interest: If I paste from another app directly into a mail composer window via mouse button 2, the paste does not work at all or is successful (no clue yet when what happens). But if I click into the composer window before pasting the text with mouse button 2, Mozilla always crashes with this text on the console: X Error of failed request: BadAtom (invalid Atom parameter) Major opcode of failed request: 17 (X_GetAtomName) Atom id in failed request: 0x2f0075 Serial number of failed request: 98315 Current serial number in output stream: 98315

This is severely harming everyone and should be a blocker for 1.7.

I see this same problem with Mozilla 1.6 and 1.7a on Solaris x86 on both Solaris 9 and Solaris 10. Kind of interesting that FireFox dosn't have the same problem.

Hmm, it's definitely not present for 1.6 on Solaris Sparc. I once saw it on one of 1.6a or 1.5a/b (could not paste,but no crash), but 1.6 Sparc is clean.

BTW, Crash is 'critical'.

Unless a solaris champion steps forward with a fix soon, this isn't going to happen for beta.

Asa Dotzler wrote: > Unless a solaris champion steps forward with a fix soon, this isn't going to > happen for beta. This is a regression caused by bug 56219 affecting *ALL* Unix platforms, not only Solaris.

(In reply to comment #20) > Unless a solaris champion steps forward with a fix soon, this isn't going to > happen for beta. The fix is easy: back out the changes for 56219 until they can be redone correctly without introducing serious regressions. I've applied the anti-fix for 56219 in my build trees for mozilla/firefox/thunderbird and X11 cut'n'paste works as well as it always has.

foobarbz(In reply to comment #21) > This is a regression caused by bug 56219 affecting *ALL* Unix platforms, not > only Solaris. It does not affect all unix platforms: a trunk build from today works fine for me on pentium4 hardware running fedora core.

Christopher A. Aillon wrote: > > This is a regression caused by bug 56219 affecting *ALL* Unix platforms, not > > only Solaris. > > It does not affect all unix platforms: a trunk build from today works fine for > me on pentium4 hardware running fedora core When I mean "Unix" I mean stuff like AIX, HP-UX, Solaris etc. ... I usually use "Unix/Linux" when I want to cover Linux, too.

This only seems to be a problem for people running CDE (which includes many Unix OSes). Comment #6 doesn't really apply because he is running 1.6, and the checking for Bug 56219 occurred after 1.6 was released.

Not a linux bug then.

Christopher A. Aillon wrote: > Not a linux bug then. Again, this bug has NOTHING "Solaris"-specific (it even happens with Linux builds when they run on a Solaris Xserver in a CDE session). Why are you changing the OS ?!

Tweaked summary and made a platform note in Status Whiteboard. Feel free to tweak if you find that inaccurate Roland.

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.

In thebug call I placed that was closed as a duplicate 236205 I also stated that cut and paste did not work on a Gnome 2.0.2 login. tested: Mozilla 1.7a OS: Solaris 9 Update 5 and Update 4 WM: CDE and Gnome 2.0.2 Results: First Cut and paste fails A second paste results in 1.7a crashing I also offered a truss file

Reverting summary since this has been seen in other window managers/desktop environments.

My crash is on Xsun Solaris 8 Sparc with fvwm2. Can somebody back out bug 56219 and reopen that to get a sane fix there ? The symptom in that bug is not so severe as the situation we have now. We really need a remedy before 1.7b gets out.

I'm not able to reproduce this using Xvnc on Fedora Core 1 (using twm, not fvwm2, but chances that the window mangager is involved are slim). What would really be helpful here is a stack track of the crash on the second paste attempt. The BadAtom message hints at the problem but isn't quite enough information.

Also, has anyone observed this problem on hardware other than Sparc? I'd like to rule out weird byte ordering problems.

(In reply to comment #34) > Also, has anyone observed this problem on hardware other than Sparc? I'd like > to rule out weird byte ordering problems. Yes I've reported seeing the problem on Solaris x86 versions 8 and 9. I've seen the problem using CDE, Gnome and KDE on Solaris.

This is a bug with old X servers on non-Linux platforms, in all likelihood. It is not a "Linux" bug per se. Who owns such old-X-server-burdened platforms? The Mozilla code is portable only to the extent that owners step up and maintain ports. Bryner trying to reproduce this on a Mozilla Foundation Solaris/x86 machine, maybe he'll succeed -- but if not, then again: those who see the bug and can help, must do so for it to be fixed. /be

Brendan Eich wrote: > This is a bug with old X servers on non-Linux platforms, in all likelihood. > It is not a "Linux" bug per se. This is no "old Xserver problem". Current Solaris Express builds (e.g. "trunk" builds Solaris operating system) has the problem, too - and that comes with a state-of-the-art Xserver. The same problem happens with Xorg Xservers which are the _reference_ _implementation_ of X11. It seems something non-portable was introduced with bug 56219, breaking everything-except-Linux.

> This is no "old Xserver problem". Current Solaris Express builds (e.g. "trunk" > builds Solaris operating system) has the problem, too - and that comes with a > state-of-the-art Xserver. Opinions vary. Some X servers have very old bugs; even new implementations reinvent old bugs. Sorry if I guessed wrong. Anyway, either bryner will be able to diagnose and find a fix today, or he'll need help from someone who can reproduce. /be

Just as a point of reference, I tested on HPUX B.10.20 (I think that's the version, anyway) and pasting into mozilla works fine from dtterm.

There's a problem indroduced with the fix for bug 56219: A macro parameter with a side effect (``cnumber++'') is used as argument for the FD_SET() macro. Depending on the implementation of the FD_SET() macro, we might end up 'select'ing on the wrong file descriptor. The attached patch seems to fix the clipboard paste problem on Solaris.

Great ! Can somebody r and sr and check in so that this one makes it into 1.7b ?

(In reply to comment #41) > Great ! Can somebody r and sr and check in so that this one makes it into 1.7b ? mozilla/widget/src/gtk2/nsClipboard.cpp has the same problem, and probably needs the same fix. one of the attachments for bug 56219 contains a patch for both source files.

My apologies to X servers, old and new. And thanks again to Jürgen Keil. It looks like dbaron fixed both gtk and gtk2 nsClipboard.cpp. Marking fixed, please verify in 1.7b. /be

problem exists in: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7b) Gecko/20040323 Mozilla/1.5.0.3l FreeBSD 4.8-RELEASE XFree86 Version 4.3.0 Qt: 3.1.1 KDE: 3.1.0 GTK: 1.2.10 - cut and paste (left, middle) from xterm to mozilla works - cut and paste (left, middle) from mozilla to mozilla works - cut and paste (explicit using menu) from mozilla to xterm works - cut and paste (left, middle) from mozilla to xterm DOES NOT work

clarification of comment #44: #2 is wrong. cut and paste (left, middle) from mozilla to mozilla DOES NOT works.

re: comment #44, comment #45: restart of X server seems to have fixed the problem! (1.7b)

also verified fixed mozilla 1.7rc1, freebsd-4.8 (private build at this point)

This is back to being an issue Linux (X11-Xorg Debian 1:7.7+7) (Firefox 59 and up). Firefox does not paste from the primary selection (for example highlight text in terminal)

This actually looks identical to https://bugzilla.mozilla.org/show_bug.cgi?id=1070518