Keyboard not responding in 1.2

Good morning Machines involved: Samsung N120 on Debian Jessie with lxqt version 0.9.0-1, dual core, 32 bit, 1Gb of memory, about 5 or so years old MedionPC Akoya quad core running Jessie with KDE full, 64 bit, 4Gb of memory about 3 or 4 years old Not using live development. The 32 bit version of Brackets is that at https://github.com/adobe/brackets/releases/download/linux-cef-2171/Brackets.Release.1.2.32-bit.deb - see thread https://github.com/adobe/brackets/issues/10255 Debian - libgcrypt version breaks Brackets. The 64 bit version is that in the same thread above - unknown by self if the same build as the 1.2 with requests for testing by @Sarath in the development channel, as no deb there and no idea how to build from source - have looked, head still spinning a little :) 32 bit version - zero keyboard response. Mouse appears to have full functionality. Fresh boot. Tested with extensions enabled and with extensions disabled, multiple opens and closes. No change on any opening of package. Also tried taking focus from window and giving it back (se 64 bit below) and no change. Do not have another 32 bit machine on which to test to see if hardware or software. 64 bit version has a similar problem, except is only very intermittant, and have not yet tried disabling extensions. Will add more to this when once done this part of testing - as occurs only over time, that may take a day or so. Issue seems to appear when there is a gap in usage of more than a couple of minutes (e.g. when I go for a meal, or answer nature). Keyboard has zero response, mouse appears to retain full functionality. After trying a few different things, found that by taking the focus away from the window and giving it back again (e.g. minimise/maximise, or open another application over the top then close it straight away) seems to resolve the issue in most occurances first time, but sometimes is stubborn and may need two or three unfocus/refocus attempts. Closing and restarting Brackets is not always a reliable fix in my experience to date. As I do a lot of copy/paste, tested by clearing all the entries stored (cacherd?) from previous copy/paste actions, makes no difference to result. Edit: note that cannot assure reproducable on the 64 bit, as sometimes after a break from the keyboard, it still functions. With greetings Romane

Later edit: Working with extensions disable. After posting the above edit about two or three minutes ago, on return to Brackets keyboard frozen. Placing the browser window back over the top of Brackets did not fix, but minimise/maximise Brackets did again allow keyboard input into Brackets.

@Romane-T All the builds linked above are prerelease/unstable builds. Can you try the official stable build from http://brackets.io/ and let us know if you're seeing the same problem there?

At times when the keyboard is not responding, does the editor area still look like it has keyboard focus? I.e. is there a blinking cursor? If you drag a text selection using the mouse, is it colored blue (focused) or gray (unfocused)? If you use the mouse to invoke a feature where focus would move elsewhere -- e.g. Find > Find or File > Open in the menu -- does typing work there?

OK, now I'm confused. You're telling me to work with 1.1, and Sarath is asking in Brackets-Dev for people to test 1.2. So who do I listen to? You or Sarath? Do you wish testers for 1.2, or do you not wish testers for 1.2? If you don't want testers for 1.2. tell me and I'll shut up. If you want testers for 1.2 and I am posting my report in the wrong place, then tell me where I should post instead of sending me discouragement.

If I am to look at 1.1, then I will simply downgrade to 1.0 and ignore 1.1, because from 1.1 on (and including 1.2) an extension that I rely on is broken - that makes my life difficult. That has already been reported to the extension developer. The only reason I have left, and continue to work with, 1.2 on my machine to date is to try and help with the testing.

I make no apology if I sound annoyed. I am annoyed. I expected better, less of the "developer attitude", more of a listener. Clearly I was mistaken.

There is (underlined next word) zero problem with the mouse in 1.2 64 bit. I can select text, I can reposition the blinking cursor with the mouse, I can operate the menus successfully with the mouse, right click works fine and so on. As I reported, the keyboard randomly freezes while the mouse continues to work OK. Sometimes it freezes when I open Brackets, sometimes it freezes when I walk away from the computer, sometimes it freezes when I go to another window or desktop and return. And then, sometimes it does not freeze.

The fix I have found is to simply minimise the window, then restore it. Appears to work every time.

I cannot give a way of reliably reproducing this bug, much to my regret.

Romane

On 18/02/15 18:32, Peter Flynn wrote:

@Romane-T https://github.com/Romane-T All the builds linked above are prerelease/unstable builds. Can you try the official stable build from http://brackets.io/ and let us know if you're seeing the same problem there?

At times when the keyboard is not responding, does the editor area still look like it has keyboard focus? I.e. is there a blinking cursor? If you drag a text selection using the mouse, is it colored blue (focused) or gray (unfocused)? If you use the mouse to invoke a feature where focus would move elsewhere -- e.g. /Find > Find/ or /File > Open/ in the menu -- does typing work there?

— Reply to this email directly or view it on GitHub https://github.com/adobe/brackets/issues/10598#issuecomment-74829195.

@Romane-T Sorry for the confusion. For Release 1.2, we have only so far provided builds for Mac & Windows here: https://github.com/adobe/brackets/releases/tag/release-1.2-prerelease1

We were hoping to get the Linux code for the builds that you tested into 1.2, but they're not yet ready so we decided to move on with Release 1.2 for Mac & Win, and provide Linux 1.2 builds soon.

Thanks for helping to test Brackets.

Good morning

On 19/02/15 02:40, Randy Edmunds wrote:

@Romane-T https://github.com/Romane-T Sorry for the confusion. For Release 1.2, we have only so far provided builds for Mac & Windows here: https://github.com/adobe/brackets/releases/tag/release-1.2-prerelease1

We were hoping to get the Linux code for the builds that you tested into 1.2, but they're not yet ready so we decided to move on with Release 1.2 for Mac & Win, and provide Linux 1.2 builds soon.

Thanks for helping to test Brackets.

— Reply to this email directly or view it on GitHub https://github.com/adobe/brackets/issues/10598#issuecomment-74897309.

A small explanation goes a loooong way. Thank you. An apology also to Peter - I know there is no excuse for my outburst, but still, a bad moment and a perception of being discouraged...

Unfortunately, the Windows .msi is not recognised by Wine - more research needed by self.

Will revert to the 1.1 release to be able to provide feedback on any issues associated, and await the distribution of the 1.2 release.

With thanks and with greetings

Romane

Thanks @Romane-T -- I am curious to hear if that 1.1 .deb has the same problem for you. For context, part of why this matters is that the "linux-cef-2171" native shell has major changes to the UI engine (Chromium) that could easily cause new bugs, so it's useful to compare. We respond to hundreds of bug reports every month, so I sometimes write quick replies and don't always provide as much detail as I could :-)

Even if you're only seeing the problem in the "linux-cef-2171" build, I'd still be curious to hear info regarding my second paragraph above -- more details on the symptoms may help get to the bottom of what's going on.

Thanks for helping us test out the bleeding edge builds!

Good morning

On 19/02/15 13:41, Peter Flynn wrote:

Thanks @Romane-T https://github.com/Romane-T -- I am curious to hear if that 1.1 .deb has the same problem for you. For context, part of why this matters is that the "linux-cef-2171" native shell has major changes to the UI engine (Chromium) that could easily cause new bugs, so it's useful to compare. We respond to hundreds of bug reports every month, so I sometimes write quick replies and don't always provide as much detail as I could :-)

Even if you're only seeing the problem in the "linux-cef-2171" build, I'd still be curious to hear info regarding my second paragraph above -- more details on the symptoms may help get to the bottom of what's going on.

Thanks for helping us test out the bleeding edge builds!

— Reply to this email directly or view it on GitHub https://github.com/adobe/brackets/issues/10598#issuecomment-74994686.

You are very gracious, Peter.

Just a quick note to affirm that 1.1 ( build 1.1.0-15558 (release ea908cae5) build timestamp: Wed Dec 17 2014 13:00:52 GMT-0800) has run without error or fault since install two days ago.

I will deal with your questions 1 by 1.

The 1.2 build am using is 1.2.0-15668 (master 027de3046) build timestamp: Tue Feb 10 2015 0907:43 GMT-0800

Chromium is not installed on my machine. Whether that may or may not affect results I do not know.

Peter: At times when the keyboard is not responding, does the editor area still look like it has keyboard focus? I.e. is there a blinking cursor? Romane: Yes. And am able to move blinking cursor to other places in the document with the mouse.

Peter: If you drag a text selection using the mouse, is it colored blue (focused) or gray (unfocused)? Romane: It is coloured as normal, blue (focussed).

Peter: If you use the mouse to invoke a feature where focus would move elsewhere -- e.g. /Find > Find/ or /File > Open/ in the menu -- does typing work there? Romane: This was one had not thought of thus not tested. Reinstalled 1.2 to test. On keyboard becoming non-functional (in case the information is useful, had been away from the computer for 30 minutes - screen saver running when reached chair, screen power saving kicked in as I sat down), tested for 'File->Save as' - able to type into save dialogue box fine, but without thinking used the mouse to OK, rather than tabbing to the OK. After this operation, keyboard was still non-functional. Tested for 'Find->Find in files', and able to type into find box OK. 'Enter' was recognised and the search was carried out successfully. On completion of operation, keyboard was functional, but as it accepted the 'Enter' for the find operation believe that the keyboard was functional again at that point.

Will continue running with 1.2 for the nonce to test this over a period of time, will report results in a week unless am advised otherwise, as that will/might show any consistencies/inconsistencies.

With greetings

Romane

Interesting -- sounds like maybe a case where CodeMirror is losing keyboard focus without realizing it.

When it stops working, does it start working again if you simply switch to a different app and then switch back to Brackets?
If not -- when it's not working, select Debug > Show Developer Tools, then go to the Console tab and type document.activeElement. What is displayed after that?
What kind of screensaver software are you using? If you switch to a different screensaver, or temporarily disable your screensaver (e.g. so the screen just powers off instead of displaying animation), does the problem go away?

Good morning Peter

Answers inline to your dot-points

On 22/02/15 13:34, Peter Flynn wrote:

Interesting -- sounds like maybe a case where CodeMirror is losing keyboard focus without realizing it.

When it stops working, does it start working again if you simply switch to a different app and then switch back to Brackets?

Both yes and no. Over the time have been running 1.2, the keyboard becomes non-functional usually when I switch away from Brackets and then back. And sometimes, it becomes functional again by switching to another application and back. But... Only sometimes - it is not predictable when it will do so either way. Sometimes it is to another application, sometimes when I switch to another desktop, sometimes when I do not touch the keyboard for a short while (as in Brackets still has focus while I may be looking at my next series of steps). Yet, other times (the more often scenario) when I do these things, the keyboard remains completely functional. Sometimes on starting Brackets, the keyboard is non-functional at start, yet most times it is functional.

The one thing that appears to be consistently reliable is to minimise Brackets then restore it in order to get the keyboard functional again.

In short words, am unable to provide a case where this condition of the keyboard losing focus can be invoked in a predictable manner.

If not -- when it's not working, select /Debug > Show Developer Tools/, then go to the Console tab and type |document.activeElement|. What is displayed after that?

First time ever that I tried to show Developer Tools that it has actually shown. In earlier version, I was left wondering what it was supposed to show. This would indicate further maturing of Brackets :)

Keyboard was functional on return to machine after 30 minutes (i.e. screen power saver had kicked in). Typed a few characters then switched to another application (grey hairs are showing, don't remember whether on same desktop or another). Noticed typing error at cursor position on return to Brackets, but keyboard had become non-functional - unable to backspace over error. Switched desktop to the email program to print out your last email, and on return, keyboard was functional, as accepted the 'Enter' key (which I struck in error :( ). Using mouse, 'Edit->Undo'. Keyboard again non-functional after this, but at least this time I had these directions in front of me (grinning). Results below.

I have included the last line showing before I typed 'document.activeElement. The 'x' was in a red circle. Have included the '<' and '>' which headed each of the line following entry of the command.

x Failed to load resource: net::ERR_UNKNOWN_URL_SCHEME
about:blank

document.activeElement < <textarea autocorrect="off" autocapitalize="off" spellcheck="false" tabindex="0" style="position: absolute; padding: 0px; width: 1000px; height: 1em; outline: none;">

I was scrolling back through the earlier entries, and found the following warning going back to when I started Brackets earlier this morning (around 8.00am - is now 7.00pm my time). Brackets had run without error till a short while ago, very roughly about an hour ago now, and that includes the things mentioned in the first dot-point. This may or may not be of any use, I leave that to your discretion. Am primarily posting for the entry about the editor but kept the other warnings in just in case useful anyway.

/utils/DeprecationWarning.js:88 Use MainViewManager.focusActivePane() instead of EditorManager.focusEditor(). at Object.focusEditor (/editor/EditorManager.js:516:28) at Object. (file:///home/romane/.config/Brackets/extensions/user/pflynn.lint-all-the-things/main.js:299:59) at j (file:///opt/brackets/www/thirdparty/thirdparty.min.js:559:26911) at Object.k.fireWith as resolveWith at Object.e.(anonymous function) as resolve at eval (/widgets/Dialogs.js:322:24)

Otherwise, all other entries appeared fine.

What kind of screensaver software are you using? If you switch to a different screensaver, or temporarily disable your screensaver (e.g. so the screen just powers off instead of displaying animation), does the problem go away?

An apology, I realised after had sent last email that that information was superfluous, as is evidenced by my response to your first dot-point above. I find that lack of predictability in when the keyboard becomes non-functional a little frustrating, in terms that I am unable to give you information that will make it reproducible at will :(

Just for information, am running Debian Jessie with the KDE (full) desktop, version 4.14.2, with Kernel 3.16.4-4, everything fully up-to-date with the repositories as at early afternoon today. Not running any non-repository software except for Brackets, and a copy of libgcrypt11 which I did not purge this time before installing Brackets 1.2, however issue was occurring even when libgcrypt11 purged previously. Screen saver and power saver as default with KDE.

— Reply to this email directly or view it on GitHub https://github.com/adobe/brackets/issues/10598#issuecomment-75417670.

With greetings

Romane

Good morning everyone, just to re-confirm the issue on Debian Jessie with Openbox. Using 1.1 is not an option because of the libgcrypto11 dependency (last night found the other thread). Using the latest linux prerelease, 64bit.

Just to add some details to this issue:

starting Brackets as normal or root user doesn't make a difference, having the same issue with keyboard focus
mouse works...if i make a selection and drag that in the editor, after releasing the text the window suddently gains focus (i can type); after using the mouse it looses focus again
if i open a new brackets window (Debug >> New Brackets Window) it works as expected...all windows opened this way seem to work.

edit ...it definitely seems like a CEF issue. Just downloaded cef_binary_3.2171.1979_linux64_client.7z, after installing the missing package of libgtkglextmm-x11-1.2-dev, and some hacking of libudev.so.1 to libudev.so.0, i got it running. The application opens up a new window with google homepage, but can not enter text inside the search input textfield (ie. same symptoms as in brackets)

Hi guys, Sorry Iam a total newby to programming... However, I do have the same issue here.. My keyboard is not responding, except when I click Debug and then --> New Brackets Window Can anyone tell me how to solve this issue in a simple way? Sorry the above is not really understandable to me :) Thank you very much indeed. Paul

adobe / brackets

Keyboard not responding in 1.2 #10598