This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 255700 - loss of focus
Summary: loss of focus
Status: NEW
Alias: None
Product: platform
Classification: Unclassified
Component: Window System (show other bugs)
Version: 8.1
Hardware: Macintosh Mac OS X
: P2 normal (vote)
Assignee: Stanislav Aubrecht
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-10-05 17:04 UTC by pbelbin
Modified: 2016-03-30 16:53 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description pbelbin 2015-10-05 17:04:49 UTC
[ JDK VERSION : 1.8.0_45 ]

While using the editor, sometimes, the editor appears to loose input focus.

there are several symptoms which become evident when this happens.

a) the mouse pointer does not show that the split bar you're pointing at can be
dragged by way of changing the pointer.

b) when debugging, pointing at items in the source code will not show the value
of the object on the screen

c) copying text will not work

d) unable to set/remove breakpoints.

the 'fix' appears to be to click on a location outside of the application
window, then click on the application again, after which, everything reverts
back to 'normal' behavior.

there is no clear triggering behavior that I can see so far to make this easily
demonstrable.
Comment 1 Jiri Kovalsky 2015-10-07 07:43:53 UTC
Peter, is this also the case in El Capitan? How often do you experience this behavior? Does it mean that you for example keep double clicking some word in Editor but it is not selected?
Comment 2 pbelbin 2015-10-07 16:12:10 UTC
Yes, that can happen.  Also, for example, even though I may be clicking on the correct place in the gutter, the break-point does not get set or cleared.  Clicking away from NetBeans and then making NetBeans the app with focus always returns the behavior to 'normal'.

I have seen this behavior under Yosemite, but I am currently using El Capitan, and it happens here too.

The thing that makes this difficult to fix is that it's difficult to see how to reproduce the issue.

It happens on a seemingly irregular basis, but, with a frequency that it's very annoying to have to deal with.
Comment 3 Jiri Kovalsky 2015-10-07 16:39:51 UTC
OK, so you experience this several times a day? Please try to monitor this and always write down what you were doing just before this happens. After say 10 occurrences attach here your usecases so that we try to reproduce it.
Comment 4 pbelbin 2015-10-09 21:18:23 UTC
with a maven web app project, and, adding a custom maven goal (ie: secondary-click on the project, custom, Goals... or the goal that was previously created) so that it will run in tomcat instead of the default glassfish server, that, once this custom maven goal has been initiated (ie: selected from the menu) that at this point, moving the mouse to a vertical split within NetBeans will not have the mouse pointer change to show the split.

also, moving the pointer to below / outside the netbeans window, that the mouse pointer will continue to show the mouse pointer that indicates a vertical move is possible.

very odd behavior, but, very reproducible.
Comment 5 pbelbin 2016-03-24 21:11:04 UTC
another reproducible way to see this happen is:

a) open a finder window, such that you can see an .xml file that has all text in one line (for example).
b) debug an app, and set a breakpoint.
c) wait for the debugger to stop at the breakpoint.
d) drag the .xml file to the browser
e) secondary-click, and choose 'format'.  you should notice that nothing has happened.  xml is still all in one line.
f) at this point, you can navigate to some java code, and click in the gutter where you should expect a breakpoint to be added.  nothing happens.
g) at this point, you can click onto the background, then back to netbeans, and now, netbeans will behave normally.  ie: you can set a breakpoint, and, ask netbeans to format the xml, and it will respond normally.
Comment 6 pbelbin 2016-03-24 21:14:01 UTC
(In reply to pbelbin from comment #5)
> another reproducible way to see this happen is:
> 
> a) open a finder window, such that you can see an .xml file that has all
> text in one line (for example).
> b) debug an app, and set a breakpoint.
> c) wait for the debugger to stop at the breakpoint.
> d) drag the .xml file to the browser
> e) secondary-click, and choose 'format'.  you should notice that nothing has
> happened.  xml is still all in one line.
> f) at this point, you can navigate to some java code, and click in the
> gutter where you should expect a breakpoint to be added.  nothing happens.
> g) at this point, you can click onto the background, then back to netbeans,
> and now, netbeans will behave normally.  ie: you can set a breakpoint, and,
> ask netbeans to format the xml, and it will respond normally.

correction:

d) drag the .xml file to the netbeans window and drop it.  Netbeans will show the .xml file contents.
Comment 7 pbelbin 2016-03-24 21:21:01 UTC
(In reply to pbelbin from comment #5)
> another reproducible way to see this happen is:
> 
> a) open a finder window, such that you can see an .xml file that has all
> text in one line (for example).
> b) debug an app, and set a breakpoint.
> c) wait for the debugger to stop at the breakpoint.
> d) drag the .xml file to the browser
> e) secondary-click, and choose 'format'.  you should notice that nothing has
> happened.  xml is still all in one line.
> f) at this point, you can navigate to some java code, and click in the
> gutter where you should expect a breakpoint to be added.  nothing happens.
> g) at this point, you can click onto the background, then back to netbeans,
> and now, netbeans will behave normally.  ie: you can set a breakpoint, and,
> ask netbeans to format the xml, and it will respond normally.

correction:

d) drag the .xml file to the netbeans window and drop it.  Netbeans will show the .xml file contents.

I am using mac osx 10.11.4 (El Capitan) and it is *still* happening.
Comment 8 Jiri Kovalsky 2016-03-30 16:53:59 UTC
Reproduced by Stepan Zebra on his Mac OS X ElCapitan. Stando, can you please evaluate this and reassign if you believe this is not a Window System issue. Thanks.