[squeak-dev] losing mouse clicks
Locked
[squeak-dev] losing mouse clicks
 
|
On 08.05.2008, at 11:14, Adrian Lienhard wrote:
> Hi, > > From time to time it happens that the image gets into a weird state where click > events are only honored after moving the mouse. For example, in the code > browser you click on a method but nothing happens until you start moving the > cursor. The problem does not seem to go away again. > > Has anybody else seen this problem? If yes, does a Mantis report exist that I > have not found? Gah, this has been biting me constantly in one image after another over the past 6 weeks (never seen it until then). First It thought it was a particular image, then it happened in another. So I thought it was the Windows VM but then it happened with the Mac VM. So then I figured it must be something MC2 was doing but now it just happened in a Seaside image. And that was a Pharo image so it's not even specific to the base image I'm using. Did anybody ever figure out what the heck is causing this? It's driving me nuts!! I did spend a bit of time in one image trying to track it down and it seemed like lots of mouse events were getting put into the EventSensor's eventQueue but not being pulled out before #flushNonKbdEvents was called (it's called often). Changing that method to leave mouse clicks as well helped for a bit but mouse ups weren't getting generated. I again hacked around that a bit but it never worked very well and then it seemed to start getting worse again. Help! Julian |
[squeak-dev] Re: losing mouse clicks
|
|
Julian Fitzell wrote:
> Did anybody ever figure out what the heck is causing this? It's > driving me nuts!! It's users of Sensor>>mouseButtons, Sensor>>shiftPressed etc. The main suspect in this regard is TransferMorph which does this: TransferMorph>>step self shouldCopy: Sensor shiftPressed. self updateCopyIcon A lingering TransforMorph (which can happen after DnD errors) will happily eat all your events. One thing you can try in such a situation is to see whether there is a TransferMorph hidden somewhere. In addition you could just do a stack dump whenever someone calls flushNonKbdEvents: EventSensor>>flushNonKbdEvents WorldState addDeferredUIMessage: (MessageSend receiver: Transcript selector: #show: argument: thisContext longStack). [no block in the above since you need the stack eagerly] Cheers, - Andreas |
Re: [squeak-dev] Re: losing mouse clicks
|
|
On Sun, Dec 21, 2008 at 8:38 PM, Andreas Raab <[hidden email]> wrote:
> Julian Fitzell wrote: >> >> Did anybody ever figure out what the heck is causing this? It's >> driving me nuts!! > > It's users of Sensor>>mouseButtons, Sensor>>shiftPressed etc. The main > suspect in this regard is TransferMorph which does this: > > TransferMorph>>step > self shouldCopy: Sensor shiftPressed. > self updateCopyIcon > > A lingering TransforMorph (which can happen after DnD errors) will happily > eat all your events. Thank you, thank you, thank you. This fixed it: TransferMorph allInstances do: [:ea | ea delete] (there was a lingering one - it had an omnibrowser method node as a passenger) Not sure why this is happening so much to me right now but at least I have a fix. Julian |
Re: [squeak-dev] Re: losing mouse clicks
|
|
On 21.12.2008, at 21:06, Julian Fitzell wrote: > On Sun, Dec 21, 2008 at 8:38 PM, Andreas Raab <[hidden email]> > wrote: >> Julian Fitzell wrote: >>> >>> Did anybody ever figure out what the heck is causing this? It's >>> driving me nuts!! >> >> It's users of Sensor>>mouseButtons, Sensor>>shiftPressed etc. The >> main >> suspect in this regard is TransferMorph which does this: >> >> TransferMorph>>step >> self shouldCopy: Sensor shiftPressed. >> self updateCopyIcon >> >> A lingering TransforMorph (which can happen after DnD errors) will >> happily >> eat all your events. > > Thank you, thank you, thank you. This fixed it: > > TransferMorph allInstances do: [:ea | ea delete] > > (there was a lingering one - it had an omnibrowser method node as a > passenger) > > Not sure why this is happening so much to me right now but at least I > have a fix. Oh great! We have encountered this from time to time but never got down to the cause. Thanks Andreas! - Bert - |
Re: [squeak-dev] Re: losing mouse clicks
|
|
So maybe the TransferMorph>>step should have a 'self delete' if owner
is not a hand morph? Or is there cases where transferMorphs live by them self ? Karl On 12/21/08, Bert Freudenberg <[hidden email]> wrote: > > On 21.12.2008, at 21:06, Julian Fitzell wrote: > >> On Sun, Dec 21, 2008 at 8:38 PM, Andreas Raab <[hidden email]> >> wrote: >>> Julian Fitzell wrote: >>>> >>>> Did anybody ever figure out what the heck is causing this? It's >>>> driving me nuts!! >>> >>> It's users of Sensor>>mouseButtons, Sensor>>shiftPressed etc. The >>> main >>> suspect in this regard is TransferMorph which does this: >>> >>> TransferMorph>>step >>> self shouldCopy: Sensor shiftPressed. >>> self updateCopyIcon >>> >>> A lingering TransforMorph (which can happen after DnD errors) will >>> happily >>> eat all your events. >> >> Thank you, thank you, thank you. This fixed it: >> >> TransferMorph allInstances do: [:ea | ea delete] >> >> (there was a lingering one - it had an omnibrowser method node as a >> passenger) >> >> Not sure why this is happening so much to me right now but at least I >> have a fix. > > > Oh great! We have encountered this from time to time but never got > down to the cause. Thanks Andreas! > > - Bert - > > > > |
Re: [squeak-dev] Re: losing mouse clicks
|
|
No, it should be changed to not use Sensor directly.
- Bert - On 22.12.2008, at 00:12, karl ramberg wrote: > So maybe the TransferMorph>>step should have a 'self delete' if owner > is not a hand morph? Or is there cases where transferMorphs live by > them self ? > > Karl > > On 12/21/08, Bert Freudenberg <[hidden email]> wrote: >> >> On 21.12.2008, at 21:06, Julian Fitzell wrote: >> >>> On Sun, Dec 21, 2008 at 8:38 PM, Andreas Raab <[hidden email]> >>> wrote: >>>> Julian Fitzell wrote: >>>>> >>>>> Did anybody ever figure out what the heck is causing this? It's >>>>> driving me nuts!! >>>> >>>> It's users of Sensor>>mouseButtons, Sensor>>shiftPressed etc. The >>>> main >>>> suspect in this regard is TransferMorph which does this: >>>> >>>> TransferMorph>>step >>>> self shouldCopy: Sensor shiftPressed. >>>> self updateCopyIcon >>>> >>>> A lingering TransforMorph (which can happen after DnD errors) will >>>> happily >>>> eat all your events. >>> >>> Thank you, thank you, thank you. This fixed it: >>> >>> TransferMorph allInstances do: [:ea | ea delete] >>> >>> (there was a lingering one - it had an omnibrowser method node as a >>> passenger) >>> >>> Not sure why this is happening so much to me right now but at >>> least I >>> have a fix. >> >> >> Oh great! We have encountered this from time to time but never got >> down to the cause. Thanks Andreas! >> >> - Bert - >> >> >> >> > |
[squeak-dev] Re: losing mouse clicks
|
|
Bert Freudenberg wrote:
> No, it should be changed to not use Sensor directly. Indeed. This is also subtly broken in the presence of multiple hands. What it should do is determine the hand that is dragging it, remember that hand and then use "hand shiftPressed". Unfortunately, this requires the users of TransferMorph to be fixed so that they pass a valid hand in the drag process since TransferMorph itself can't easily figure out which hand is responsible. Cheers, - Andreas > - Bert - > > On 22.12.2008, at 00:12, karl ramberg wrote: > >> So maybe the TransferMorph>>step should have a 'self delete' if owner >> is not a hand morph? Or is there cases where transferMorphs live by >> them self ? >> >> Karl >> >> On 12/21/08, Bert Freudenberg <[hidden email]> wrote: >>> >>> On 21.12.2008, at 21:06, Julian Fitzell wrote: >>> >>>> On Sun, Dec 21, 2008 at 8:38 PM, Andreas Raab <[hidden email]> >>>> wrote: >>>>> Julian Fitzell wrote: >>>>>> >>>>>> Did anybody ever figure out what the heck is causing this? It's >>>>>> driving me nuts!! >>>>> >>>>> It's users of Sensor>>mouseButtons, Sensor>>shiftPressed etc. The >>>>> main >>>>> suspect in this regard is TransferMorph which does this: >>>>> >>>>> TransferMorph>>step >>>>> self shouldCopy: Sensor shiftPressed. >>>>> self updateCopyIcon >>>>> >>>>> A lingering TransforMorph (which can happen after DnD errors) will >>>>> happily >>>>> eat all your events. >>>> >>>> Thank you, thank you, thank you. This fixed it: >>>> >>>> TransferMorph allInstances do: [:ea | ea delete] >>>> >>>> (there was a lingering one - it had an omnibrowser method node as a >>>> passenger) >>>> >>>> Not sure why this is happening so much to me right now but at least I >>>> have a fix. >>> >>> >>> Oh great! We have encountered this from time to time but never got >>> down to the cause. Thanks Andreas! >>> >>> - Bert - >>> >>> >>> >>> >> > > > > > |
[squeak-dev] Re: losing mouse clicks
|
|
I've added a mantis report and proposed fix here:
http://bugs.squeak.org/view.php?id=7251 Cheers, - Andreas Andreas Raab wrote: > Bert Freudenberg wrote: >> No, it should be changed to not use Sensor directly. > > Indeed. This is also subtly broken in the presence of multiple hands. > What it should do is determine the hand that is dragging it, remember > that hand and then use "hand shiftPressed". Unfortunately, this requires > the users of TransferMorph to be fixed so that they pass a valid hand in > the drag process since TransferMorph itself can't easily figure out > which hand is responsible. > > Cheers, > - Andreas > >> - Bert - >> >> On 22.12.2008, at 00:12, karl ramberg wrote: >> >>> So maybe the TransferMorph>>step should have a 'self delete' if owner >>> is not a hand morph? Or is there cases where transferMorphs live by >>> them self ? >>> >>> Karl >>> >>> On 12/21/08, Bert Freudenberg <[hidden email]> wrote: >>>> >>>> On 21.12.2008, at 21:06, Julian Fitzell wrote: >>>> >>>>> On Sun, Dec 21, 2008 at 8:38 PM, Andreas Raab <[hidden email]> >>>>> wrote: >>>>>> Julian Fitzell wrote: >>>>>>> >>>>>>> Did anybody ever figure out what the heck is causing this? It's >>>>>>> driving me nuts!! >>>>>> >>>>>> It's users of Sensor>>mouseButtons, Sensor>>shiftPressed etc. The >>>>>> main >>>>>> suspect in this regard is TransferMorph which does this: >>>>>> >>>>>> TransferMorph>>step >>>>>> self shouldCopy: Sensor shiftPressed. >>>>>> self updateCopyIcon >>>>>> >>>>>> A lingering TransforMorph (which can happen after DnD errors) will >>>>>> happily >>>>>> eat all your events. >>>>> >>>>> Thank you, thank you, thank you. This fixed it: >>>>> >>>>> TransferMorph allInstances do: [:ea | ea delete] >>>>> >>>>> (there was a lingering one - it had an omnibrowser method node as a >>>>> passenger) >>>>> >>>>> Not sure why this is happening so much to me right now but at least I >>>>> have a fix. >>>> >>>> >>>> Oh great! We have encountered this from time to time but never got >>>> down to the cause. Thanks Andreas! >>>> >>>> - Bert - >>>> >>>> >>>> >>>> >>> >> >> >> >> >> > > > |
Re: [squeak-dev] Re: losing mouse clicks
|
|
In reply to this post by Bert Freudenberg
...and while on the "subject":
When hacking on Blackfoot (my SimpleCGI implementation) I have noticed that banging on Blackfoot through Nginx (a web server) using ab (apache benchmark) the image seem to inevitably (but definitely not immediately) end up in a state where it does not take mouse/keyboard events nor redraws when being resized. However - it still cranks out SCGI responses like before. So it doesn't seem to happen easily, but when pushing it with thousands of requests it eventually happens. So somehow the UI died but Socket and the listening Process etc works just fine. I presume this can happen using KomHttpServer or whatever, intuitively it can't be something Blackfoot does - anyone seen it? Using... oh darn, the VM is way old :) It is a 3.9-8, and a 3.9 7067 image. I will see if it still appears with the newest VM/image combo. regards, Göran |
|
|
Göran Krampe wrote:
> ...and while on the "subject": > > When hacking on Blackfoot (my SimpleCGI implementation) I have noticed > that banging on Blackfoot through Nginx (a web server) using ab > (apache benchmark) the image seem to inevitably (but definitely not > immediately) end up in a state where it does not take mouse/keyboard > events nor redraws when being resized. However - it still cranks out > SCGI responses like before. So it doesn't seem to happen easily, but > when pushing it with thousands of requests it eventually happens. > > So somehow the UI died but Socket and the listening Process etc works > just fine. > > I presume this can happen using KomHttpServer or whatever, intuitively > it can't be something Blackfoot does - anyone seen it? > > Using... oh darn, the VM is way old :) It is a 3.9-8, and a 3.9 7067 > image. I will see if it still appears with the newest VM/image combo. > > regards, Göran Which I fixed in the old days by going back to a 3.7.7 vm. More recently we had a load of fixes to Semaphores and friends which (I think) made it into 3.10 Keith |
[squeak-dev] Re: losing mouse clicks
|
|
In reply to this post by Göran Krampe
Hi Göran -
The first thing to check is what priorities these various processes are at. I would guess that if you keep hitting your listener loop hard enough it would at some point consume all available CPU. And if any of the processes keeps eating CPU at high priority your UI will become unresponsive at some point (note that the effect can be hidden - for example if you have a gazillion Delays they could conceivably block the timer event handler adding/removing Delays from the lists etc). A good thing to do is when the whole UI is unresponsive is to ask the VM what it is currently doing by calling printCallStack or printAllStacks. In our server VMs -USR1 is hooked up to do this but you can run the VM under gdb (or attach gdb --pid when it's in this state) and ask gdb to call printCallStacks(). Do this a couple of times to give the result a bit more statistical validity and at the end you can be pretty sure that's where it is spending time. Cheers, - Andreas Göran Krampe wrote: > ...and while on the "subject": > > When hacking on Blackfoot (my SimpleCGI implementation) I have noticed > that banging on Blackfoot through Nginx (a web server) using ab (apache > benchmark) the image seem to inevitably (but definitely not immediately) > end up in a state where it does not take mouse/keyboard events nor > redraws when being resized. However - it still cranks out SCGI responses > like before. So it doesn't seem to happen easily, but when pushing it > with thousands of requests it eventually happens. > > So somehow the UI died but Socket and the listening Process etc works > just fine. > > I presume this can happen using KomHttpServer or whatever, intuitively > it can't be something Blackfoot does - anyone seen it? > > Using... oh darn, the VM is way old :) It is a 3.9-8, and a 3.9 7067 > image. I will see if it still appears with the newest VM/image combo. > > regards, Göran > > > |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |