Closed Bug 233317 Opened 21 years ago Closed 20 years ago

Cannot paste from clipboard

Categories

(Core Graveyard :: GFX: Gtk, defect)

Product:
Core Graveyard
Component:
GFX: Gtk
Platform:
All
Linux
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: roland.mainz, Assigned: blizzard)

References

Details

(Keywords: crash, regression, Whiteboard: Most commonly seen on Solaris+CDE, Solaris+GNOME, and Solaris+Xvnc)

Attachments

(1 file)

suggested patch to fix this problem
818 bytes, patch
Details | Diff | Splinter Review 
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
Flags: blocking1.7a?
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.
Severity: blocker → major
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.
Flags: blocking1.7a? → blocking1.7a-
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. ***
Flags: blocking1.7b?
Flags: blocking1.7b? → blocking1.7b+
Mats: only drivers can set (+) blocking flags.  You can request (?) them (like
Roland did).
Flags: blocking1.7b+
Flags: blocking1.7b?
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. ***
Keywords: regression
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.
Flags: blocking1.7b? → blocking1.7b-
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.
Flags: blocking1.7b- → blocking1.7b?
(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.
OS: Linux → Solaris
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 ?!
OS: Solaris → Linux
Tweaked summary and made a platform note in Status Whiteboard.  Feel free to
tweak if you find that inaccurate Roland.
Summary: Cannot paste from clipboard → Cannot paste from clipboard in CDE apps
Whiteboard: Only appears to affects CDE (on any platform running CDE)
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.
QA Contact: ian → nobody
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
Keywords: crash
Reverting summary since this has been seen in other window managers/desktop
environments.
Summary: Cannot paste from clipboard in CDE apps → Cannot paste from clipboard
Whiteboard: Only appears to affects CDE (on any platform running CDE) → Most commonly seen on Solaris+CDE, Solaris+GNOME, and Solaris+Xvnc
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
Status: NEW → RESOLVED
Closed: 20 years ago
Flags: blocking1.7b? → blocking1.7b+
Resolution: --- → FIXED
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)
Product: Core → Core Graveyard
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
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: