[squeak-dev] VM sending keystrokes on mouse-wheel?

[Chris Muller]

Hi Eliot and all,

I have just noticed in Squeak 5.2 that attempting to scroll a text
pane beyond its scroll limit causes the text cursor to start moving.
So, for example, when I have a selected expression in the debugger,
and I simply scroll the text pane, I hit the end and lose the
selection, which is incredibly annoying.

Does anyone kno

[Chris Muller]

The bug doesn't exist in the 5.0-201807260206 VM. This affects the
input events coming in, which manifests in ways no one can predict.

Honestly guys, we literally threw away all the months of accumulated
confidence value from testing that VM. This software is too complex
to safely release any other way than long test cycles. There isn't
any extra cost to the "wait" approach, whereas slamming in untested
code potentially costs a lot -- everybody now has broken binaries out
there, and now we have to put out yet another release of 5.2. :(
It's just not worth the risk...
On Sat, Nov 3, 2018 at 4:45 PM Chris Muller <***@gmail.com> wrote:
>
> Hi Eliot and all,
>
> I have just noticed in Squeak 5.2 that attempting to scroll a text
> pane beyond its scroll limit causes the text cursor to start moving.
> So, for example, when I have a selected expression in the debugger,
> and I simply scroll the text pane, I hit the end and lose the
> selection, which is incredibly annoying.
>
> Does anyone know why this is

[tim Rowledge]

> On 2018-11-03, at 4:24 PM, Chris Muller <***@gmail.com> wrote:
>
> The bug doesn't exist in the 5.0-201807260206 VM. This affects the
> input events coming in, which manifests in ways no one can predict.

I do't seem to be able to replicate this on a 5.2 image running on a 5.2 Pi vm.

Specifically
Squeak5.2beta
latest update: #18199
Current Change Set: Unnamed1
Image format 6521 (32 bit)
&
/home/pi/Squeak/sqcogspurlinuxhtRPi/lib/squeak/5.2-201810190412/squeak

I opened a debugger (with cmd-. just in case that might matter) and EventSensor>processEvent: selected some code near the top (event at: 8 put: window) and then scrolled down using the mouse wheel (Apple Mighty mouse). The selection was retained as I'd expect.

Do you have a good example I can try out?


tim
--
tim Rowledge; ***@rowledge.org; http://www.rowledge.org/tim
Don't compare floating point numbers solely for equality.

[Chris Muller]

Surefire way to reproduce:

1) launch Squeak5.2 or Squeak5.1 with the 5.0-201810190412 VM.

2) Click "Skip" to remove the "Welcome To Squeak" banner. The
"Welcome To Squeak" window is there.

3) Click somewhere in the text pane to give it keyboard focus.

4) Click and drag to select 4 or 5 lines of text in the second paragraph.

5) Using mouse wheel, scroll down a few lines.

6) Using mouse wheel, scroll up *really fast*, ensuring to slam to the
top. The selection is gone text cursor is one or more words to the
left of the original selection.

7) If the selection is still there, keep scrolling up as fast/hard as
you can, and watch the text cursor move in increments of one word to
the left, as if Control+[Left Arrow] is being pressed.

- Chris


On Sat, Nov 3, 2018 at 7:27 PM tim Rowledge <***@rowledge.org> wrote:
>
>
>
> > On 2018-11-03, at 4:24 PM, Chris Muller <***@gmail.com> wrote:
> >
> > The bug doesn't exist in the 5.0-201807260206 VM. This affects the
> > input events coming in, which manifests in ways no one can predict.
>
> I do't seem to be able to replicate this on a 5.2 image running on a 5.2 Pi vm.
>
> Specifically
> Squeak5.2beta
> latest update: #18199
> Current Change Set: Unnamed1
> Image format 6521 (32 bit)
> &
> /home/pi/Squeak/sqcogspurlinuxhtRPi/lib/squeak/5.2-201810190412/squeak
>
> I opened a debugger (with cmd-. just in case that might matter) and EventSensor>processEvent: selected some code near the top (event at: 8 put: window) and then scrolled down using the mouse wheel (Apple Mighty mouse). The selection was retained as I'd expect.
>
> Do you have a good example I can try out?
>
>
> tim
> --
> tim Rowledge; ***@rowledge.org; http://www.rowledge.org/tim
> Don't compare floating point numbers solely

[tim Rowledge]

> On 2018-11-03, at 6:20 PM, Chris Muller <***@gmail.com> wrote:
>
> Surefire way to reproduce:

Weird. Tried that and simply can't replicate it. What platform are you using?


tim
--
tim Rowledge; ***@rowledge.org; http://www.rowledge.org/tim
Breakthrough: It finally booted

[Chris Muller]

> > Surefire way to reproduce:
>
> Weird. Tried that and simply can't replicate it. What platform are you using?

Linux x64.

Give how little time there has been since the 20180726 VM, I hoped
Eliot would have a good suspect for the cause based on his knowledge
of the changes that went in since then, and my account of the symptom.

I've gone back to the 20180726 VM on my machines but, IMO, this seems
significant enough to be worth fixing in the 5.2 release. We could
simply revert to the VM we tested, 20180726.



>
>
> tim
> --
> tim Rowledge; ***@rowledge.org; http://www.rowledge.org/tim
> Breakthrough: It finally bo

[Eliot Miranda]

Hi Chris,

On Tue, Nov 6, 2018 at 4:44 PM Chris Muller <***@gmail.com> wrote:

> > > Surefire way to reproduce:
> >
> > Weird. Tried that and simply can't replicate it. What platform are you
> using?
>
> Linux x64.
>
> Give how little time there has been since the 20180726 VM, I hoped
> Eliot would have a good suspect for the cause based on his knowledge
> of the changes that went in since then, and my account of the symptom.
>
> I've gone back to the 20180726 VM on my machines but, IMO, this seems
> significant enough to be worth fixing in the 5.2 release. We could
> simply revert to the VM we tested, 20180726.
>

I'm n to Aware off any changes to event handling in X11 between those two
VMs. Since the bug seems to be timing related it is not inconceivable that
the issue iOS that the newer VM is faster and that hence the bug manifests
because the newer VM is faster, not that it processes mouse wheel events
any different. SO before we condemn the current VM can we please look for
candidate changes and do some more careful analysis of the bug. So far
we're identifying symptoms not causes, and until the bug is explained
simply reverting the VM is not being objective.


>
>
>
> >
> >
> > tim
> > --
> > tim Rowledge; ***@rowledge.org; http://www.rowledge.org/tim
> > Breakthrough: It finally booted on the first try.
> >
> >
> >
>
>

--
_,,,^..^,,,_
best, Eliot

[Beckmann, Tom]

Hi,

I'm also on Linux-x64, experiencing the same issue. If I'm not missing something, it should boil down to this PR https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/155/files? and the fact that HandMorph>>filterEvent:for: only translate Ctrl+up/down, while passing on Ctrl+left/right as normal key events.

So the VM now generates Ctrl+left/right whenever you (accidentally) scroll horizontally, this moves the cursor by a word, which in turn instructs the text view to scroll back to the area where the cursor currently is.

Best,
Tom


________________________________
From: Squeak-dev <squeak-dev-***@lists.squeakfoundation.org> on behalf of Eliot Miranda <***@gmail.com>
Sent: Wednesday, November 7, 2018 3:50 AM
To: Chris Muller; The general-purpose Squeak developers list
Subject: Re: [squeak-dev] VM sending keystrokes on mouse-wheel?

Hi Chris,

On Tue, Nov 6, 2018 at 4:44 PM Chris Muller <***@gmail.com<mailto:***@gmail.com>> wrote:
> > Surefire way to reproduce:
>
> Weird. Tried that and simply can't replicate it. What platform are you using?

Linux x64.

Give how little time there has been since the 20180726 VM, I hoped
Eliot would have a good suspect for the cause based on his knowledge
of the changes that went in since then, and my account of the symptom.

I've gone back to the 20180726 VM on my machines but, IMO, this seems
significant enough to be worth fixing in the 5.2 release. We could
simply revert to the VM we tested, 20180726.

I'm n to Aware off any changes to event handling in X11 between those two VMs. Since the bug seems to be timing related it is not inconceivable that the issue iOS that the newer VM is faster and that hence the bug manifests because the newer VM is faster, not that it processes mouse wheel events any different. SO before we condemn the current VM can we please look for candidate changes and do some more careful analysis of the bug. So far we're identifying symptoms not causes, and until the bug is explained simply reverting the VM is not being objective.




>
>
> tim
> --
> tim Rowledge; ***@rowledge.org<mailto:***@rowledge.org>; http://www.rowledge.org/tim
> Breakthrough: It finally booted on the first try.
>
>
>



--
_,,,^..^,,,_
best, Eliot

[Eliot Miranda]

Hi Tom, Hi Chris,

see commit d964e7 which has the X11 code do the same as the iOS code. I'd
love it if someone who knows Windows would test the same thing there-on.
Also, are the "#ifndef NO_WHEEL_MOUSE" defines necessary (eg perhaps
required for WINCE) ? It would be lovely just to include the code
unadorned by the noise, or to use something less tacky such as "#if
defined(WM_MOUSEWHEEL)". Chris, can you see if this fixes your issue?

On Tue, Nov 6, 2018 at 7:16 PM Beckmann, Tom <
***@student.hpi.uni-potsdam.de> wrote:

> Hi,
>
> I'm also on Linux-x64, experiencing the same issue. If I'm not missing
> something, it should boil down to this PR
> https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/155/files​ and the
> fact that HandMorph>>filterEvent:for: only translate Ctrl+up/down, while
> passing on Ctrl+left/right as normal key events.
>
> So the VM now generates Ctrl+left/right whenever you (accidentally) scroll
> horizontally, this moves the cursor by a word, which in turn instructs the
> text view to scroll back to the area where the cursor currently is.
>
> Best,
> Tom
>
>
> ------------------------------
> *From:* Squeak-dev <squeak-dev-***@lists.squeakfoundation.org> on
> behalf of Eliot Miranda <***@gmail.com>
> *Sent:* Wednesday, November 7, 2018 3:50 AM
> *To:* Chris Muller; The general-purpose Squeak developers list
> *Subject:* Re: [squeak-dev] VM sending keystrokes on mouse-wheel?
>
> Hi Chris,
>
> On Tue, Nov 6, 2018 at 4:44 PM Chris Muller <***@gmail.com> wrote:
>
>> > > Surefire way to reproduce:
>> >
>> > Weird. Tried that and simply can't replicate it. What platform are you
>> using?
>>
>> Linux x64.
>>
>> Give how little time there has been since the 20180726 VM, I hoped
>> Eliot would have a good suspect for the cause based on his knowledge
>> of the changes that went in since then, and my account of the symptom.
>>
>> I've gone back to the 20180726 VM on my machines but, IMO, this seems
>> significant enough to be worth fixing in the 5.2 release. We could
>> simply revert to the VM we tested, 20180726.
>>
>
> I'm n to Aware off any changes to event handling in X11 between those two
> VMs. Since the bug seems to be timing related it is not inconceivable that
> the issue iOS that the newer VM is faster and that hence the bug manifests
> because the newer VM is faster, not that it processes mouse wheel events
> any different. SO before we condemn the current VM can we please look for
> candidate changes and do some more careful analysis of the bug. So far
> we're identifying symptoms not causes, and until the bug is explained
> simply reverting the VM is not being objective.
>
>
>>
>>
>>
>> >
>> >
>> > tim
>> > --
>> > tim Rowledge; ***@rowledge.org; http://www.rowledge.org/tim
>> > Breakthrough: It finally booted on the first try.
>> >
>> >
>> >
>>
>>
>
> --
> _,,,^..^,,,_
> best, Eliot
>
>

--
_,,,^..^,,,_
best, Eliot

[Bob Arning]

Not sure if this is the same, but it sounds similar to something I have
experienced in recent squeaks. See if this helps at all:

'From Squeak5.1 of 23 August 2016 [latest update: #16548] on 3 November
2018 at 9:50:50 pm'!

!TextMorphForEditView methodsFor: 'event handling' stamp: 'raa 11/3/2018
21:50'!
keyStroke: evt
    | view |
    editView deleteBalloon.
    (editView scrollByKeyboard: evt) ifTrue: [^self].


    [(evt controlKeyPressed
        and: [evt commandKeyPressed]
        and: [evt keyValue = 28 or: [evt keyValue = 29]]
    ) ifTrue: [
        ^self    "funky trackpad code scrolls - yecch"
    ].] on: Error do: [ :ex | ].



    self editor model: editView model.  "For evaluateSelection"
    view := editView.  "Copy into temp for case of a self-mutating doit"
    (acceptOnCR and: [evt keyCharacter = Character cr])
        ifTrue: [^ self editor accept].
    super keyStroke: evt.
    view scrollSelectionIntoView.

    "Make a cheap check and guess editing. (Alternative would be to
copy the old contents and then compare them against the new ones. Maybe
add a better hook in the TextEditor."
    (self readOnly not and: [evt keyCharacter isAlphaNumeric or: [evt
keyCharacter isSeparator]])
        ifTrue: [view textEdited: self contents].! !


On 11/3/18 5:44 PM, Chris Muller wrote:
> Hi Eliot and all,
>
> I have just noticed in Squeak 5.2 that attempting to scroll a text
> pane beyond its scroll limit causes the text cursor to start moving.
> So, for example, when I have a selected expression in the debugger,
> and I simply scroll the text pane, I hit the end and lose the
> selection, which is incredibly annoying.
>
> Does anyone know why this is and how to fix it?
>
> Thanks
>