You are viewing an historical archive of past issues. Please report new issues to the appropriate project issue tracker on GitHub.

Bug #52: Menu bar buttons don't respond to left-click events, but right-clicks work

Kind bug
Product Synergy
When Created , updated
Status open
Reporter Greg Hurrell
Tags no tags

Description

From a user email: "I'm using synergy 1.4 and have one button (play/pause) in the menu bar, using the TigerWhite button set. After a while (possibly after waking from sleep?) it begins to not respond to clicking on it to pause or play, although right-clicking still yields the Synergy menu, and the keyboard controls still work. Changing the button set and then changing back gets it working again. I don't know if it's specific to this button set or not as it's the only one I like and have used."

This issue sounds suspiciously similar to bug #39 and bug #50, but filing it as a separate report for now.

Comments

  1. Greg Hurrell

    It would be useful if you could use the Activity Monitor to take a sample the next time you see this hang, to see if this is related to bug #39 and/or bug #50.

    See:

    https://wincent.dev/a/knowledge-base/archives/2004/11/how_to_file_a_g.php

    Marking as ASSIGNED.

  2. Chris Decker

    I'm having the same problem, only I'm using Synergy 1.5b. I can't pin down when exactly the issue happens, but occasionally the buttons don't work. I can control-click and see the menu, but the buttons still won't work. iTunes works just fine the entire time BTW. The only way I can get the buttons to respond again is either to stop and start Synergy.

  3. Greg Hurrell

    It's good to have independent confirmation of this from another user. This makes it fairly clear that this is NOT a dupe of bug #39, which is a total hang.

    I haven't ever seen this on Panther (running 10.3.6). What version are you running on?

    Evidently something really weird is going on if left-clicks are not getting passed down to the Synergy NSView, but right-clicks are. At least the defect is a very specific one, so hopefully it can be tracked down. I'll bet control-click doesn't get through either (but you could confirm that for me?).

    Is anything written to the console? If something weird is happening Synergy might print a message there that helps us.

    Marking this as ASSIGNED again. (Please leave it that way!)

  4. Hans Tobeason

    The menu bar controls become non-responsive every so often, requiring a stop/start cycle in the pref pane. I can't reproduce this on demand, but it usually seems to happen overnight. This is a new problem, possibly post Synergy 1.6.1, possibly post OS X 10.3.7. I'm running on a PowerMac G4 AGP 450 768 Mb iTunes 4.7.1 (though this was happening with 4.7 as well).

  5. Greg Hurrell
    • ** Bug 116 has been marked as a duplicate of this bug. ***
  6. Hans Tobeason

    Right now, Synergy is frozen - not hung, per se, it just won't respond to any mouse input at all - there's no beach ball. iTunes is responsive, and, in fact, the Synergy menu icon for Play/Pause changes to reflect the current play/pause condition of iTunes. I've copied an Activity Monitor sample of Synergy below. The only way I'm aware of to snap Synergy out of its coma is to do something like Stop/Start cycle it in System Preferences (or change the button set).

    Analysis of sampling pid 467 every 10.000000 milliseconds Call graph: 

       6810 Thread_110b
     6810 _dyld_start
       6810 0x9470
         6810 0x92eba2b8
           6810 0x92dfdc30
             6810 0x92de98c8
               6810 0x92dd2e44
                 6810 0x927fe6a0
                   6810 0x927dc6c8
                     6810 0x927d5f60
                       6810 CFRunLoopRunSpecific
                         6810 __CFRunLoopRun
                           6810 mach_msg
                             6810 mach_msg_trap
                               6810 mach_msg_trap
   6810 Thread_1203
     6810 _pthread_body
       6810 __ape_agent
         6810 __ape_internal
           6810 mach_msg
             6810 mach_msg_trap
               6810 mach_msg_trap

    Total number in stack (recursive counted multiple, when >=5):

    Sort by top of stack, same collapsed (when >= 5):

           mach_msg_trap        13620

    Sample analysis of process 467 written to file /dev/stdout Sampling process 467 each 10 msecs 300 times

  7. Greg Hurrell
    • ** Bug 118 has been marked as a duplicate of this bug. ***
  8. Hans Tobeason

    Happened again. The Synergy process sample is identical to the sample I already submitted. Is there anything else I can supply that would help diagnose this?

  9. Greg Hurrell

    Not really that I can think of. I haven't been able to reproduce this even running Synergy 24 hours a day, 7 days a week. I can't fix it if I can't reproduce it.

  10. Greg Hurrell

    Changing assignment to reflect my new email address.

    https://wincent.dev/a/news/archives/2006/05/change_of_email.php

Add a comment

Comments are now closed for this issue.

Menu