Bug 14406 - Rterm.exe doesn't work after unfocusing it and focusing it again
Summary: Rterm.exe doesn't work after unfocusing it and focusing it again
Status: CLOSED FIXED
Alias: None
Product: R
Classification: Unclassified
Component: Windows GUI / Window specific (show other bugs)
Version: R 2.11.1
Hardware: ix86 (32-bit) Windows 64-bit
: P5 minor
Assignee: R-core
URL:
Depends on:
Blocks:
 
Reported: 2010-10-14 15:43 UTC by Adal
Modified: 2016-07-07 13:50 UTC (History)
4 users (show)

See Also:


Attachments
patch to fix "stuck" alt key upon e.g. alt+tab (567 bytes, patch)
2016-07-07 12:39 UTC, jan-glx
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Adal 2010-10-14 15:43:53 UTC
start Rterm.exe
execute ls()
activate another window by Alt+Tab
activate Rterm again by Alt+Tab
try typing anything

When using Alt+Tab to switch between windows, Rterm enters some kind of locked state in which you can't type anymore. This doesn't happen if you use the mouse to switch the active window.

You can exit this locked mode by pressing the Alt key once.

This was testing using R 32 bit on Windows 7 64 bit.
Comment 1 Adal 2010-10-14 17:23:56 UTC
I tested just now this exact scenario using another two console applications that I have: python.exe and mysql.exe. I couldn't reproduce the issue in them, but I can in Rterm.exe each time.

I start rterm by first starting a console (cmd.exe or powershell.exe) and then typing "rterm" in them and pressing ENTER. The problem is reproductible in both cmd/powershell. It is also reproductible by starting Rterm directly from the Start menu or by using Win+R (Run).

I don't have time in the next 2 days to test RC 2.12, but I will do it after that.

BTW, I think I overreacted by making this bug critical. So I'll change it to normal. I just started using R last week, and I have no idea how much is Rterm used on Windows. The problem seems to appear only when using Alt+Tab once to switch away from Rterm, then another time to switch back to it. If you do anything in between (like using the application you switched to), the problem doesn't appear.
Comment 2 Adal 2010-10-14 19:09:31 UTC
I can reproduce the problem on another Win 7 64 machine.

I don't use an antivirus, and Process Explorer shows that no shell extension was loaded into the Rterm.exe process (no unusual DLL loaded).

Have you tried both Alt keys when testing this? I can only reproduce it with the Alt key on the same side as the Tab key.

I looked into the source code a bit. It seems that R uses this function to read from the console: https://svn.r-project.org/R/trunk/src/gnuwin32/getline/getline.c

Around line 100 you can see specific code to handle the Alt key (AltIsDown variable, ...). R (getline) seems to activate a special mode (ENABLE_PROCESSED_INPUT) of the ReadConsoleInput Win32 function in which normal Windows processing of Alt key is disabled. Maybe this interacts in some unfortunate way with the Alt+Tab combination which is always handled by the system, even in this mode.

Related info found on web:
==========================
http://www.adrianxw.dk/SoftwareSite/Consoles/Consoles5.html

The "trick" I have used here gets around the "ENABLE_PROCESSED_INPUT" mode, by which many "special" characters/sequences which are normally intercepted/handled and not reported/hidden by the OS can be "caught". If you intend to "get around" many of these features, it may be worth resetting the console mode to remove this flag, however, doing so will remove normal processing of things like tab and carriage return, you will have to process these yourself, (for this reason, I have elected not to use this technique in the tutorial).
Comment 3 Duncan Murdoch 2010-10-14 20:09:25 UTC
r-bugs@r-project.org wrote:
> https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=14406
>
>            Summary: Rterm.exe doesn't work after unfocusing it and
>                     focusing it again
>            Product: R
>            Version: R 2.11.1
>           Platform: PC/x86
>         OS/Version: Windows 64-bit
>             Status: NEW
>           Severity: critical
>           Priority: P5
>          Component: Windows GUI / Window specific
>         AssignedTo: R-core@R-project.org
>         ReportedBy: adal.chiriliuc@gmail.com
>    Estimated Hours: 0.0
>
>
> start Rterm.exe
> execute ls()
> activate another window by Alt+Tab
> activate Rterm again by Alt+Tab
> try typing anything
>
> When using Alt+Tab to switch between windows, Rterm enters some kind of locked
> state in which you can't type anymore. This doesn't happen if you use the mouse
> to switch the active window.
>
> You can exit this locked mode by pressing the Alt key once.
>
> This was testing using R 32 bit on Windows 7 64 bit.
>
>   


I'm not on Win 7 right now, but this looks like a Windows/other software 
bug, rather than an R bug.  R doesn't do a lot in the way of special I/O 
handling when run via Rterm, it's just a console application.  (It does 
do some fancy stuff to display plots, and it's possible that code could 
mess up, but your example didn't involve graphics).

In any case, I think you need to give more information before we can try 
to reproduce the problem.  Exactly how did you start Rterm.exe? 

And while you're at it, could you try the release candidate of 2.12.0?  
It's available from http://cran.r-project.org/bin/windows/base/rtest.html.


Duncan Murdoch


Comment 4 Duncan Murdoch 2010-10-14 22:14:02 UTC
  On 14/10/2010 12:23 PM, r-bugs@r-project.org wrote:
> https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=14406
>
> Adal<adal.chiriliuc@gmail.com>  changed:
>
>             What    |Removed                     |Added
> ----------------------------------------------------------------------------
>             Severity|critical                    |normal
>
> --- Comment #1 from Adal<adal.chiriliuc@gmail.com>  2010-10-14 12:23:56 EDT ---
> I tested just now this exact scenario using another two console applications
> that I have: python.exe and mysql.exe. I couldn't reproduce the issue in them,
> but I can in Rterm.exe each time.
>
> I start rterm by first starting a console (cmd.exe or powershell.exe) and then
> typing "rterm" in them and pressing ENTER. The problem is reproductible in both
> cmd/powershell. It is also reproductible by starting Rterm directly from the
> Start menu or by using Win+R (Run).
>
> I don't have time in the next 2 days to test RC 2.12, but I will do it after
> that.
>
> BTW, I think I overreacted by making this bug critical. So I'll change it to
> normal. I just started using R last week, and I have no idea how much is Rterm
> used on Windows. The problem seems to appear only when using Alt+Tab once to
> switch away from Rterm, then another time to switch back to it. If you do
> anything in between (like using the application you switched to), the problem
> doesn't appear.
>


I'm now on a 64 bit Win 7 machine, and I don't see any problems if I 
follow your instructions in the cmd shell.  I've tried both 2.11.1 and 
the 2.12.0 RC.  So I would check on the usual suspects:  anti-virus, 
Explorer add-ins, etc.

I'll leave the bug live for a few days in case someone else can 
reproduce it, but I think it's going to have to end up "not reproducible".

Duncan Murdoch


Comment 5 Brian Ripley 2010-10-15 06:03:48 UTC
Not easily reproducible.  I use Rterm almost all the time
rather than Rgui, and I've never experienced it.
Comment 6 Duncan Murdoch 2010-10-15 15:46:14 UTC
Martyn Plummer wrote:
> On Thu, 2010-10-14 at 13:14 -0400, Duncan Murdoch wrote:
>   
>> On 14/10/2010 12:23 PM, r-bugs@r-project.org wrote:
>>     
>>> https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=14406
>>>
>>> Adal<adal.chiriliuc@gmail.com>  changed:
>>>
>>>             What    |Removed                     |Added
>>> ----------------------------------------------------------------------------
>>>             Severity|critical                    |normal
>>>
>>> --- Comment #1 from Adal<adal.chiriliuc@gmail.com>  2010-10-14 12:23:56 EDT ---
>>> I tested just now this exact scenario using another two console applications
>>> that I have: python.exe and mysql.exe. I couldn't reproduce the issue in them,
>>> but I can in Rterm.exe each time.
>>>
>>> I start rterm by first starting a console (cmd.exe or powershell.exe) and then
>>> typing "rterm" in them and pressing ENTER. The problem is reproductible in both
>>> cmd/powershell. It is also reproductible by starting Rterm directly from the
>>> Start menu or by using Win+R (Run).
>>>
>>> I don't have time in the next 2 days to test RC 2.12, but I will do it after
>>> that.
>>>
>>> BTW, I think I overreacted by making this bug critical. So I'll change it to
>>> normal. I just started using R last week, and I have no idea how much is Rterm
>>> used on Windows. The problem seems to appear only when using Alt+Tab once to
>>> switch away from Rterm, then another time to switch back to it. If you do
>>> anything in between (like using the application you switched to), the problem
>>> doesn't appear.
>>>
>>>       
>> I'm now on a 64 bit Win 7 machine, and I don't see any problems if I 
>> follow your instructions in the cmd shell.  I've tried both 2.11.1 and 
>> the 2.12.0 RC.  So I would check on the usual suspects:  anti-virus, 
>> Explorer add-ins, etc.
>>
>> I'll leave the bug live for a few days in case someone else can 
>> reproduce it, but I think it's going to have to end up "not reproducible".
>>
>> Duncan Murdoch
>>     
>
> I can reproduce this with both R-2.11.1 and R-2.12.0rc on my Windows 7
> Desktop.  The bug does not manifest when I change the behaviour of
> "Windows Flip" to not use advanced graphics features. This can be done
> by 
>
> a) Going to control panel -> performance information and tools ->
>    adjust visual effects and unchecking the box "Use visual styles on
>    windows and buttons", or
>
> b) Using a simpler desktop theme such as "Windows classic"
>
> Hence this appears to be a graphics driver problem. My display adapter
> is an Intel 4 series internal chipset with driver  8.15.10.1872
> (13/08/2009).


Thanks, that's helpful advice.  Later today I'll see if I can reproduce 
it with that setting.  (I normally use Windows classic, so that might be 
why I didn't see it already).

The fact that it only affects R and not some other programs in the 
console suggests that Windows might be sending some message to R that is 
confusing it, so it could be something we can address.  I'll take a look.

Duncan Murdoch


Comment 7 Duncan Murdoch 2010-10-15 20:09:59 UTC
  On 15/10/2010 6:46 AM, Duncan Murdoch wrote:
> Martyn Plummer wrote:
> >  On Thu, 2010-10-14 at 13:14 -0400, Duncan Murdoch wrote:
> >
> >>  On 14/10/2010 12:23 PM, r-bugs@r-project.org wrote:
> >>
> >>>  https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=14406
> >>>
> >>>  Adal<adal.chiriliuc@gmail.com>   changed:
> >>>
> >>>              What    |Removed                     |Added
> >>>  ----------------------------------------------------------------------------
> >>>              Severity|critical                    |normal
> >>>
> >>>  --- Comment #1 from Adal<adal.chiriliuc@gmail.com>   2010-10-14 12:23:56 EDT ---
> >>>  I tested just now this exact scenario using another two console applications
> >>>  that I have: python.exe and mysql.exe. I couldn't reproduce the issue in them,
> >>>  but I can in Rterm.exe each time.
> >>>
> >>>  I start rterm by first starting a console (cmd.exe or powershell.exe) and then
> >>>  typing "rterm" in them and pressing ENTER. The problem is reproductible in both
> >>>  cmd/powershell. It is also reproductible by starting Rterm directly from the
> >>>  Start menu or by using Win+R (Run).
> >>>
> >>>  I don't have time in the next 2 days to test RC 2.12, but I will do it after
> >>>  that.
> >>>
> >>>  BTW, I think I overreacted by making this bug critical. So I'll change it to
> >>>  normal. I just started using R last week, and I have no idea how much is Rterm
> >>>  used on Windows. The problem seems to appear only when using Alt+Tab once to
> >>>  switch away from Rterm, then another time to switch back to it. If you do
> >>>  anything in between (like using the application you switched to), the problem
> >>>  doesn't appear.
> >>>
> >>>
> >>  I'm now on a 64 bit Win 7 machine, and I don't see any problems if I
> >>  follow your instructions in the cmd shell.  I've tried both 2.11.1 and
> >>  the 2.12.0 RC.  So I would check on the usual suspects:  anti-virus,
> >>  Explorer add-ins, etc.
> >>
> >>  I'll leave the bug live for a few days in case someone else can
> >>  reproduce it, but I think it's going to have to end up "not reproducible".
> >>
> >>  Duncan Murdoch
> >>
> >
> >  I can reproduce this with both R-2.11.1 and R-2.12.0rc on my Windows 7
> >  Desktop.  The bug does not manifest when I change the behaviour of
> >  "Windows Flip" to not use advanced graphics features. This can be done
> >  by
> >
> >  a) Going to control panel ->  performance information and tools ->
> >     adjust visual effects and unchecking the box "Use visual styles on
> >     windows and buttons", or
> >
> >  b) Using a simpler desktop theme such as "Windows classic"
> >
> >  Hence this appears to be a graphics driver problem. My display adapter
> >  is an Intel 4 series internal chipset with driver  8.15.10.1872
> >  (13/08/2009).
>
> Thanks, that's helpful advice.  Later today I'll see if I can reproduce
> it with that setting.  (I normally use Windows classic, so that might be
> why I didn't see it already).
>
> The fact that it only affects R and not some other programs in the
> console suggests that Windows might be sending some message to R that is
> confusing it, so it could be something we can address.  I'll take a look.
>
> Duncan Murdoch


Yes, now I can reproduce it.  I'll see if I can track down what's going 
wrong.

Duncan Murdoch


Comment 8 Marco Maier 2014-05-25 12:53:19 UTC
i've tried to reproduce this bug with the latest patched version of R (3.1.0 Patched 2014-05-18 r65651) on a win 8.1 x64 machine (Platform: x86_64-w64-mingw32/x64 64-bit) and, as mentioned above, Rterm does not respond when switching windows with ALT + TAB (point-and-click switching, e.g. in the taskbar, does not produce this behavior).

anyway, i've found a workaround: if your Rterm session gets stuck, you can "interrupt" this by pressing CTRL + ALT + PAUSE/BREAK.
it's not a real solution, but at least you don't have to kill the process and lose your work.
Comment 9 Brad Eck 2016-06-13 10:40:05 UTC
I'm seeing this behavior using R 3.3.0 but only since upgrading to this version. Running windows 7, 64 bit.
Comment 10 jan-glx 2016-07-05 12:02:07 UTC
now I see why people complain about R-core...
How can such an issue still (6 years later) be there (3.3.1)?
Thanks Marco-Mayer, your workaround saved my life (coding without accidentally clicking alt-tab once in while is impossible)
I find "critical" quite suitable - just consider the time one spends to figure out that alt-tab is the problem.
Comment 11 Duncan Murdoch 2016-07-05 13:11:42 UTC
Comment 10 is unnecessarily rude.

Nobody on R Core sees this bug in our normal way of working.  I did manage to reproduce it once and tried to track it down six years ago, but was unsuccessful.

Someone who is affected by it is going to have to go after this one.  Perhaps you could recruit Microsoft to help.
Comment 12 jan-glx 2016-07-06 19:17:03 UTC
@Duncan Murdoch, yes it was a little rude. I was mad. Sorry, @r-core.
Anyway, I don't know where to find Microsoft so I investigated the issue further:

The freeze can not only be stopped by Ctrl+Alt+Break but also just by pressing the Alt key once.
It is not only occurring when alt+tab-bing but also when holding the alt key while switching to another window with the mouse.

=> R memorizes alt key down but does not receive the corresponding up event


Only the left alt key is affected and problems can be avoided by pressing first both alt keys, then releasing the right one and finally pressing tab.
These observations indicate that the problem is indeed related to the function gl_getc in getline (https://github.com/wch/r-source/blob/e5b21d0397c607883ff25cca379687b86933d730/src/gnuwin32/getline/getline.c#L150). Through I can't figure where/how/if it is used by Rterm.

adding 'AltIsDown = (st & LEFT_ALT_PRESSED)' before line 150 instead of the assignment in line 152 would -as far as I can think- alleviate all problems. (you could even quickly check the alt + three keys combo again that you just googled  while performing it :)

Unfortunately, R for windows is not so easy to build - therefore I cannot test my proposal... but I could not make a PR anyway, right?
Thanks to whomever will look into it (again)! - Jan
Comment 13 Duncan Murdoch 2016-07-06 19:56:00 UTC
Thanks for your detective work here.  No, we don't accept Github pull requests, but since the weekend we have posted instructions on how to produce a patch file:  see <https://www.r-project.org/bugs.html>.

I can't test your suggestion today, but will try to do it tomorrow.  If you want to put together a patch file and attach it to this bug report, go ahead, but your verbal description seems clear enough.
Comment 14 jan-glx 2016-07-07 12:39:37 UTC
Created attachment 2115 [details]
patch to fix "stuck" alt key upon e.g. alt+tab

Tested on revision 70865. Works like a charm.

Only the promised possibility to alt+tab during typing a alt key combo is not working but could be fixed by making nAlt and bbb global static variables too... but I don't think that's worth it.
Comment 15 Duncan Murdoch 2016-07-07 13:50:05 UTC
Will commit the attached patch to R-devel and R-patched after testing.