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 33686 - JSP names changed without users actions
Summary: JSP names changed without users actions
Status: VERIFIED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: Explorer (show other bugs)
Version: 3.x
Hardware: All All
: P3 blocker (vote)
Assignee: _ tboudreau
URL:
Keywords:
Depends on: 29447 33296
Blocks:
  Show dependency tree
 
Reported: 2003-05-16 14:04 UTC by sva
Modified: 2008-12-23 11:16 UTC (History)
3 users (show)

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 sva 2003-05-16 14:04:49 UTC
Steps to reproduce:
1. Create 2 JSP files.
2. Select these JSP's in Explorer.
3. Note, that <Different Values> displayed as Name in 
properties window.
4. Click on "..." button for Name property.

Result: JSP name for 1st selected JSP changed 
to "<Different Values>". 

Reproduced with Nevada 030512 under Linux & Solaris.
Comment 1 _ rkubacki 2003-05-16 15:02:42 UTC
I observed different behaviour: an exception is thrown when customizer
is opened. Nothing is renamed. Also it is the same for Java files so
it doesn't seems to be a problem in web module. Tim, can you look into
this?
Comment 2 _ tboudreau 2003-05-16 15:20:37 UTC
I'd say if the files are getting renamed, that may be worthy of fixing
in 3.5 (the use case for opening the name customizer when
multiple items are selected is questionable anyway).  In 4.0, there 
will be no customizer button for DataObject names, so this is 
already effectively fixed in the NetBeans trunk.

Probably customizers should be disabled when multiple objects are
selected - there's no useful value they can display.  That's a 
pretty easy thing to fix in ProxyNode if necessary.

Comment 3 Marian Mirilovic 2003-05-20 09:09:24 UTC
I don't think we need a fix for 3.5/S1S5. 

Renaming two files at once isn't "common" action, but it isn't good if
you push "Cancel" button and first file is renamed.

I propose to decrease priority to P3, or ask for waiver.
Comment 4 _ tboudreau 2003-05-20 10:29:18 UTC
The question remains what *should* be the behavior of 
invoking a custom editor when there are multiple items
selected.  Should this even be possible?

The property sheet knows about the package-private
DifferentValuesException thrown when you call getValue()
and two nodes with different values are selected.
This exception (along with ProxyNode which throws it)
are package-private to the Explorer class, and the
property sheet is designed to handle this condition.

Custom editors do not know about such a state, so
their behavior is pretty much undefined.  Since the
custom editor only allows one value to be selected
and doesn't know about multiple values for one property,
it is not surprising that the property value of all 
selected nodes is forced to a single value when the 
custom editor is invoked.

This issue can also be reproduced as follows:
 - Set one file to internal execution
 - Set another to external
 - Select them both
 - Open and cancel the execution custom editor
Both now are set to external execution

I propose a relatively easy, one-line fix - proxied
properties with different values shall not display the custom editor
button.

I can't think of any places this could cause a problem.

I have implemented this in the new property sheet branch,
and am adding a dependancy on the property sheet rewrite
umbrella issue.
Comment 5 Marian Mirilovic 2003-05-20 14:27:42 UTC
I thing, it's not necessary fix it for 3.5/S1S5.

Trung, Honza: what do you think ? 
Comment 6 _ ttran 2003-05-20 16:38:12 UTC
I would leave it to QA to decide whether or not we want to fix it in
release35.

Tim, pls fix it in trunk so we'll be prepared
Comment 7 Jan Chalupa 2003-05-20 18:45:11 UTC
I don't think this is a showstopper. IMO, renaming multiple files
simultaneously using this approach is a very unlikely user scenario.
Moreover, this is not the kind of problem users would run into repeatedly.

Too late to fix this in release35. Please put the fix into trunk only.
Should be waived for S1S5.
Comment 8 _ tboudreau 2003-05-21 10:08:48 UTC
Technically, the name property issue is already
fixed, since property editors for DataNode names now suppress the
custom editor button - see issue 33296.

The more general fix for all customizers is already in the
PropertySheet branch - I'll mark this issue fixed once we merge it.

Setting target to 4.0 and dropping priority to P3.
Comment 9 _ tboudreau 2003-07-16 19:46:24 UTC
Fixed - new property sheet committed.

Custom editor button now suppressed for multi-selection.
Comment 10 sva 2003-07-17 14:16:36 UTC
Verified. But some problems still exist. See bug 34982