paste item of context menu is not updated correctly

RESOLVED INVALID

Status

()

Firefox
Menus
RESOLVED INVALID
11 years ago
9 years ago

People

(Reporter: son.two, Unassigned)

Tracking

2.0 Branch
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

11 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/20061201 Firefox/2.0.0.6 (Ubuntu-feisty)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/20061201 Firefox/2.0.0.6 (Ubuntu-feisty)

It is possible to have situation when "Paste" item of context menu is disabled but I can paste using Ctrl-V.  Here is an original bug filed against Java -
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6584971

I have also created small native test which only copy XA_STRING into clipboard and I've got the same result :(

Reproducible: Always

Steps to Reproduce:
1. compile the test 
(gcc -s -O -o xclipboard xclipboard.c -I /usr/X11R6/include -L /usr/X11R6/lib -lX11)
2. run it
3. open context menu in firefox (e.g. for address bar) verify that "paste" item is disabled
4. paste text into address bar using Ctrl-V you should see "It Works"
Actual Results:  
"paste" item is disabled, but it is possible to paste using clipboard

Expected Results:  
"paste" item should be enabled

here is the test:

#include <X11/Xlib.h>
#include <X11/Xatom.h>
#include <assert.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>

Atom XA_CLIPBOARD;

main()
{
  Display *dpy = XOpenDisplay(NULL);
  assert(dpy);
  Window w = XCreateSimpleWindow(dpy, DefaultRootWindow(dpy), 0, 0,
                                 200, 100, 0, 0, 0);
  XSelectInput(dpy, w, StructureNotifyMask);
  XMapWindow(dpy, w);
  XSelectionRequestEvent *req;
  XEvent e, respond;
  for(;;) {
    XNextEvent(dpy, &e);
    if (e.type == MapNotify) break;
  }
  XFlush(dpy);
  //
  XA_CLIPBOARD = XInternAtom(dpy, "CLIPBOARD", False);
  Atom a1, a2, a3, type;
  XSelectInput(dpy, w, StructureNotifyMask+ExposureMask);
  int format, result;
  unsigned long len, bytes_left, dummy;
  unsigned char *data;
  Window Sown;

  XSetSelectionOwner (dpy, XA_CLIPBOARD, w, CurrentTime);
  XFlush (dpy);

  for (;;) {
    XNextEvent (dpy, &e);
    if (e.type == SelectionRequest)
      //
      // Somebody wants our data
      //
    {
      req=&(e.xselectionrequest);
      printf ("Selection Request from Mr %i I am %i\n",
              (int)e.xselection.requestor, (int)w);
      printf ("prop:%i tar:%i sel:%i\n", req->property,
              req->target, req->selection);
      if (req->target == XA_STRING)
      {
        XChangeProperty (dpy,
                         req->requestor,
                         req->property,
                         XA_STRING,
                         8,
                         PropModeReplace,
                         (unsigned char*) "It Works",
                         8);
        respond.xselection.property=req->property;
      }
      else // Strings only please
      {
        printf ("No String %i\n",
                (int)req->target);
        respond.xselection.property= None;
      }
      respond.xselection.type= SelectionNotify;
      respond.xselection.display= req->display;
      respond.xselection.requestor= req->requestor;
      respond.xselection.selection=req->selection;
      respond.xselection.target= req->target;
      respond.xselection.time = req->time;
      XSendEvent (dpy, req->requestor,0,0,&respond);
      XFlush (dpy);
    }
  }
}
Reporter, is it still a problem with Firefox 3.5.2?
Whiteboard: [closeme 2009-09-09]
Version: unspecified → 2.0 Branch
No response from reporter. Closing as incomplete.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → INCOMPLETE
Whiteboard: [closeme 2009-09-09] → [closeme 2009-09-08]
(Reporter)

Comment 3

9 years ago
Sorry for late response, but I have not received update from 2009-09-02 (looks like gmail considered it as a spam :(

I've just retested the problem with 3.5.2 and it is still reproducible, so
I'm reopening this bug.
Status: RESOLVED → UNCONFIRMED
Resolution: INCOMPLETE → ---
So does it happen for all other applications too or only to specific ones? I just need simple steps to reproduce.
Whiteboard: [closeme 2009-09-08]
(Reporter)

Comment 5

9 years ago
The problem is reproducible with this particular test which, as far as I can see,
is a valid X11 program (and mimic behavior of some java programs).

I'm not sure what means "simple steps to reproduce" :(  
What kind of problems do you have with provided test and steps?
(Reporter)

Comment 6

9 years ago
BTW if firefox uses gtk (or some other library) and you can provide simple testcase which demonstrates that the problem is in this library, please share this code, so I could file bug against the library.
I cannot compile this program so that's the reason why I have asked you. It would be fantastic when you can tell us an applications on Ubuntu which makes this behavior visible.
(Reporter)

Comment 8

9 years ago
to build the test on Ubuntu you just need gcc (hope you already have it ;) and
X11 headers (package libx11-dev).
Ok, that did it. I can see that the context menu entry for paste is not enabled but Ctrl+V works. I also checked a couple of other gnome applications and none of them show an enabled context menu entry for paste. So this should really be a gnome issue.

Please file a bug against gnome.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 9 years ago9 years ago
Resolution: --- → INVALID
(Reporter)

Comment 10

9 years ago
before filing the bug, it would be great to write a simple test, if you have one please share it with me (I'm not expert in gtk, so it will take a time for me to write the test)
You have your application. That should be enough. Following steps have to be done:

1. Run your application once.
2. Start any other gnome application e.g. the default text editor
3. Use ctrl+v to paste the clipboard entry
4. Open the context menu over the text field => it's not enabled
(Reporter)

Comment 12

9 years ago
luckily, I have found an example of pure gtk code which demonstrates the problem
Thanks. Feel free to comment the url of the gtk bug report.
You need to log in before you can comment on or make changes to this bug.