Also noted on 
SunOS espresso 5.10 s10_49 i86pc i386 i86pc
java full version "1.4.2_03-b02"

As discussed, this is more of a complex issue than it seems, and is different from the 
design and behavior of the new property sheet for about a year.  It is worth thinking about 
whether it should be changed (there is a line switch, I netbeans.ps.commitOnFocusLoss 
which turns this on), but we would have to reconsider some other aspects of the design 
(behavior when a bad value is entered, what to do with illegal input, what to do if a foreign 
dialog pops up while the user has a partially entered value, etc.)

Changing a value and then selecting a different element will also
leave the old value. This seems more odd if you take into account that
moving to a different attribute YES means you accepted the value.
Where is then the difference between moving to a different element
than to a diffrent property?

from my point of view it seems to be reasonable to _confirm_ entered
value by ENTER or by TAB. You have to confirm the value in other apps too.
I strongly agree with Tim's comment, what will we do with
"unconfirmed" inputs, how can we be sure that it's valid input when we
don't know when property editing phase is finished ...

Lluis, could you clarify your comment?  The *only* way to update the value from the 
property sheet (without using an inline editor) is by an expicit gesture (pressing enter to 
confirm the new value). 

*** Issue 39846 has been marked as a duplicate of this issue. ***

I'd like to add a comment.  This bug (IMHO) makes it more difficult
to, for example, edit GridBagLayout's in the form editor.  In 3.5.1, I
could quickly jump around controls and make changes in sheet to their
settings, by entering numbers in one hand and switching properties via
the mouse with the other.  Now, with this behavior, I have to hit
enter after each entry.  This easily triples or quadruples the amount
of time it takes me to make quick changes in this way.  Focus change
to another field should have been enough to commit the value (assuming
it is valid).

Adding Dusan to cc.  It looks like there's considerable demand for commit-on-focus-lost 
behavior.  Right now it's enablable via a startup line switch, but is much less tested and 
may have problems.

Dusan, let's talk next week - we *could* make this change for 3.6, though it's *very* late 
in the game to do it.  Honza, we would need to do pretty thorough excercising of the 
property sheet by QA to make sure everything was copacetic - it's changing some behavior 
that's very central to the way the property sheet works.

In the mean time - for those who want to try it without having to press enter, you can 
enable it by appending the following to your ide.cfg file (in $NB_HOME/bin):
-J-Dnetbeans.ps.commitOnFocusLoss=true  

Those who are lobbying for this to become the default:  Please try this switch and report 
any problems with it as comments on this issue.

Tim, please go ahead and switch the default. We'll test and see what
the feedback will be. I prefer to make the change now, because we
still have time to revert the default in case of any problems. That
would be much harder to do later.

My 2 cents - IMHO changing focus shouldn't be the way how user would
normally confirm changing value of some property. It should require
explicit gesture from user (enter, tab), not just changing focus.
Especially in java which is running in huge number of window managers,
which work with focus differently, e.g. consider focus follow mouse
setting (I don't want to even think about it :). I'd vote for having
this feature switchable by property and only interested people could
use it, but not being as default.

Hmm, I'm afraid Milan's point is valid. I didn't think about various
window managers and the 'focus follows mouse' behavior. We'll need to
spend more time on this after 3.6.

Tim, please revert the yesterday's change. The
netbeans.ps.commitOnFocusLoss property should be set to 'false' by
default. Thanks.

FWIW, focus-follows-mouse shouldn't be a big problem with such a change - the value 
would be taken if the mouse moves outside the property sheet, but as long as it is inside 
it, the editor should stay focused.

This is the sort of thing that led us to require an explicit gesture, but it may be worth 
leaving on - 99% of users do not use focus-follows-mouse, and the 1% that do are 
probably savvy enough to use a line switch.  That could be put in the release notes.  I think 
maybe we should let it stay as is and collect more data.  Honza, can you live with that?

hmmm, so what ? What'll be default value ? true/false ? I'd like to
know before tommorow q-build.

And one scenario (i tested with command line switch):
user expects commit on focus lost, and it works nice, but what about
SDI ? Try change value of some property in its own Properties window
and switch to different window (Editor).
I'd expect that the new value is propagated but it isn't. When you
switch back to Properties you will see that the focus is still in
property value  textfield. A little bit confusing...

I think that status when user has to confirm value is normal and is
common in others programs too.

Tim, I don't have any data on the percentage of users preferring one
or the other. I heard from both camps lately and both have some valid
arguments. The rule of thumb should be if we don't know what is the
right solution, let's stick with the one we've been using so far (ok,
until yesterday), because it's far more tested and most people are
already used to it.

Tim, please revert the change asap. Thanks.

*** Issue 40319 has been marked as a duplicate of this issue. ***

*** Issue 40702 has been marked as a duplicate of this issue. ***

*** Issue 41076 has been marked as a duplicate of this issue. ***

*** Issue 41134 has been marked as a duplicate of this issue. ***

*** Issue 42355 has been marked as a duplicate of this issue. ***

This change really needs to be made. Not that we had property changes
being committed on focus loss until 3.5.1, and did not get complaints
at that time (so far as I know). Note that there are 6 bugs marked as
duplicates of this one.

I agree. Any recommendations what should happen when the focus moves
while the entered value is invalid? I don't think it has been fully
resolved yet.

I think it should do the same thing  it does when you tab out and it
is invalid -- generally pops up an alert. I can see that this may be
sometimes unexpected, but not sure what the other options are. 

Honza, would QA be able to test it with the commit on focus loss
lineswitch turned on?

Yes. Is the -J-Dnetbeans.ps.commitOnFocusLoss=true option still
supposed to work?

Yup.

I tested today with the switch -J-Dnetbeans.ps.commitOnFocusLoss=true.
I have no new findings. The SDI mode still doesn't accept the switch.
The MDI mode is usefull, but I am not used to this approach of
properties changing. I will work with this switch for next few days to
find some potential problems.

Probably the biggest hurdle is going to be legacy property editors (the IMT had some, and 
I'm dealing with a P1 caused by the workarounds for it now), which assumed that if the 
value of a property was null, but getTags() returned non null, that what should be shown is 
getTags[0].  This practically guarantees that simply setting focus to such an editor will set 
the value to getTags()[0], which may be undesirable.  Simple example would be ColorEditor 
with null for a color - when you focus the editor, it becomes "white".  Pressing escape will 
set it to null, but anything else will change the value.  That may be livable.

My main regret is rewriting the propertysheet to be compatible with the old one - three 
generations of APIs, 5-6 non normative hints to change behavior * 4 possible interfaces 
implemented on top of those (of which a property editor can implement one or more), one 
of which allows about 4 additional hints to property 
editor behavior...do the math and consider the combinatorics...the possibilities of 
implementing this all in a perfectly compatible way...well, when you've got 20 years to 
spare it's not a problem.  We're not going to be corner-case-free - we're not now.

Probably best to fix this, understand that there will be corner cases and put out the fires 
as we find them.  There will be some either way, most will not be severe, and no worse 
than the current situation.

I won't pretend I understand everything you wrote in your last
comment, Tim.

A simple question: Do you see any reasons why the commit-on-focus-lost
change shouldn't be integrated right now? Do you know of any issues
users are likely to be unhappy about? What are they? IMT? Any
particular area you would still want testers to look at?

I can probably flip the bit next week.  I'll need to go through all
the property editor unit tests and flip the bit back for them, since
they will fail with the new behavior.  Sorry for rambling in my last
post on this.

The main problem case is where, you start with a value that is null. 
You click the editor.  It is a combo (a Color that starts out null
will do this).  The only way to get the null back is to press Esc - if
you just shift focus away, the value that is getTags()[0] will become
the value of the property.  I think that's the only serious issue, and
there are not many editors with such pathological behavior;  the IMT
is gone also.

Is it normal issuezilla procedure to revise "summary" descriptions?
Given that this is a general IDE wide Human Interface issue, it seems
a bit subtle to have this discussion subsumed under a summary "Tools |
Options ...". Perhaps if it were retitled "Property Editor commit
policy discrepancy" or something sufficiently descriptive of the
widespread impact of this feature, there would not be so many duplicat
bugs being entered.

Its funny how differently QA prioritizations are. In Studio land this
is listed as a P2 Bug based on seeming regressive behavior compared to
prior versions, here it is listed as a P3 RFE.

> Its funny how differently QA prioritizations are. In Studio land this
> is listed as a P2 Bug based on seeming regressive behavior compared to
> prior versions

Mike, it was a design decision in writing the new property sheet that an affirmative gesture 
should be required before any property value is written.  This issue is considering 
revisiting that decision.  That is why it is categorized and prioritized as it is.

I strongly suspect an equal number of users will complain if we change it to behave the 
other way - there is no right answer for everyone here.

This is clearly a defect and should be fixed for promoD. If the current state was a design 
decision then it was not correct. The reasons are following:

* the user wants to commit the change if she/he changed the value in Tools|Options and 
then clicked the close button
* the user wants to commit the change if she/he changed the value in the property sheet 
when designing a GUI form and then clicked into the form designer
* all other IDEs (I checked our major competitors) change the value in such case
* no IDE reverts the value in such case
* there is no difference from user point of view between using the Tab key and clicking out 
of the property sheet field using the mouse - both mean the same thing: "I am done with 
editing and want to keep the value!". The same is true when the user uses a mnemonic to 
move the focus to a different widget out of the property sheet.
* it should work exactly the same way as the in-place rename in the explorer tree

Thanks Jano,
so new question rises:

Do you want fix this for Beta 2 ?

I will need to update a large number of unit tests to make them not fail with this setting - 
(though I suppose I could just flip the bit on the beta branch).  When would this be needed 
by?

It should be fixed ideally for Beta2.

Ok, so Tim code freeze for Beta 2 is this Wednesday!

Flipped the bit in trunk and beta 2 branch

Tim,

What is the bit that you are flipping, so that we can backport this to
our 3.6 snapshot? Thanks

org.openide.explorer.propertysheet.PropUtils - look for commitOnFocusLoss, and invert 
the Boolean.getBoolean() logic.

*** Issue 37584 has been marked as a duplicate of this issue. ***

Marking as VERIFIED.

This issue had *2 votes* before move to platform component