Bugzilla – Full Text Bug Listing
| Summary: | [Tooling] Selection in code snippet view causes exceptions | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Modeling] Papyrus-rt | Reporter: | Peter Cigehn <peter.cigehn> | ||||||||
| Component: | tool | Assignee: | Young-Soo Roh <ysroh> | ||||||||
| Status: | CLOSED FIXED | QA Contact: | |||||||||
| Severity: | normal | ||||||||||
| Priority: | P3 | CC: | charles, give.a.damus, sredding | ||||||||
| Version: | 0.9.0 | ||||||||||
| Target Milestone: | 1.0.0 | ||||||||||
| Hardware: | PC | ||||||||||
| OS: | Windows 7 | ||||||||||
| See Also: |
https://bugs.eclipse.org/bugs/show_bug.cgi?id=513257 https://git.eclipse.org/r/95414 https://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=cba328d9907a0849ec436eb1a3ff82d57c06211a https://git.eclipse.org/r/95834 https://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=dbda1a7b8b92837ea97473c23a249b97830789e6 |
||||||||||
| Whiteboard: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
Peter Cigehn
I guess these kinds of issues related to the NatTable used for the trigger table in the properties view is related to the question whether they shall be replaced by a JFace table or not, see Bug 513257. Another case where a selection in the code snippet view causes exceptions was identified as part of identifying Bug 514639. When testing repeated undo/redo for the scenario in Bug 514639 it works fine, with no exceptions. But strange enough, if a selection has been made in the code snippet view, then exceptions starts appearing after a while. Steps to reproduce: 1) Open the model in Attachment 267607 [details] (notice that this model is slight variant of the one attached to this bug, even though they have the same name). 2) Make sure to *not* select anything in the properties view or the code snippet view 3) Re-inherit the redefined opaque behavior in state-machine of Capsule2 4) Repeatably press Ctrl+X and Ctrl+Y to undo and redo a few times. 5) This seem work fine and no exceptions are thrown 6) Now open the state-machine diagram of Capsule2 7) Select the transition in the diagram 8) Select the trigger in the trigger table 9) Select the trigger code snippet in the code snippet view (at this point in time a few exceptions randomly gets thrown, have not investigated how to get this to repeat, and are not fully sure if/how they might be related to the following steps) 10) Now repeat step 4 with repeated undo/redo. 11) After two undo/redo cycles, an org.eclipse.emf.common.util.BasicEList$BasicIndexOutOfBoundsException: index=2, size=2 is thrown Contined undo/redo throws additional index out of bounds exceptions (with different index/size). So there is something really fishy going on when the code snippet view has "grabbed" some selection. I guess this could explain a lot of other strange behavior that can be seen, and possibly could explain several "random" and hard to repeat cases. Since it is such a pain with these "random" issues I can see in so many situations, it would be really good if this could be looked in rather soon, to avoid spending too much time understanding lots of random issues, and spending time on getting them repeatable in a consistent manner. New Gerrit change created: https://git.eclipse.org/r/95414 Created attachment 267963 [details] Screen shots showing a basic scenario editing trigger guards in legacy tooling Since the discussion in the Gerrit change https://git.eclipse.org/r/95414 became hard to follow, I made some screen shots in the legacy tooling showing the basic steps when editing multiple triggers guards for the same transition. The same kind of selection behavior is expected in Papyrus-RT. But if that for some reason, as indicated in the discussion in the Gerrit change, requires a completely own implementation of the properties view, then we need to rethink how the basic editing scenario shown in this attachment really is going to be performed in Papyrus-RT. It feels a bit too drastic to have to write a completely new properties view just for the sake of supporting this. Created attachment 267971 [details] Example model with multiple triggers When trying the corresponding scenario as in Attachment 26796 [details] attached to Comment 4 in Papyrus-RT there are a few notable differences. Steps to reproduce: 1) Open the attached model in a new fresh workspace 2) Make sure to put the Properties view and the Code Snippet view side-by-side in separate "view stacks", i.e. not on top of each other in the same view stack, to ensure that corresponding view layout as proposed in the Papyrus-RT specific perspective tracked by Bug 511829. 3) Open the state-machine diagram in Capsule1 4) Select the request+ transition 5) Observe how the Properties view indicates an element selected in a diagram with the presence of the "Style", "Appearance", and "Rules And Grid" tabs. 6) Select the anotherRequest trigger in the trigger table in the Properties view 6) Observe how the anotherRequest trigger row gets marked and the Code Snippet view shows the related trigger guard as expected 7) Now click in the Code Snippet view to start editing the guard code 8) Observer how immediately as you click in the Code Snippet view, it looks like the Properties view "flips" to some other selection. The "Style", "Appearance" and "Rulers and Grid" tabs is removed. The previous selection in the trigger table gets lost. 9) Now click again on the anotherRequest trigger in the trigger table in the Properties view 10) Now click in the Code Snippet view to start editing the code. 11) Now there is no "flipping" in the Properties view, the selection in the trigger table is kept as one would expect 12) Click on the transition in the diagram again 13) Observe the "flipping" in the Properties view and see how the "Style", "Appearance" and "Rulers And Grid" tabs are back. Also observer how the trigger table now seem to be back with the previous selection of anotherRequest. 14) Click on yetAnotherRequest trigger 15) The Code Snippet view follows along as expected 16) Now click in the Code Snippet view to start editing the guard for the yetAnotherRequest trigger 17) Observe how the "flipping" of the Properties view appears again, the diagram element related tabs is removed. 18) Also observe how the selection in the trigger table now indicates that the anotherRequest trigger is selected, even though it was the yetAnotherRequest trigger that was selected, and is now active in the Code Snippet view So the selection in the trigger table now does not match the selection in the Code Snippet view. All of this would make much more sense if the "flipping" of the Properties view did not happen whenever you click in the Code Snippet view causing some other selection to the made in the Properties view. I have not understood why clicking in the Code Snippet view need to forcie the Properties view to "flip" to some other selection, causing it to "loose" context, e.g. related to the selected trigger in the table. Gerrit change https://git.eclipse.org/r/95414 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=cba328d9907a0849ec436eb1a3ff82d57c06211a New Gerrit change created: https://git.eclipse.org/r/95834 Gerrit change https://git.eclipse.org/r/95834 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=dbda1a7b8b92837ea97473c23a249b97830789e6 I have tested this in the latest Papyrus-RT build (#592). And the initial issues with exceptions in Comment 0 are not possible to reproduce any longer, The steps Comment 2 is not even possible to perform. Not sure if it is due to that the steps to reproduce is not detailed enough or if the behavior with not "grabbing" the selection causes a completely different overall behavior. Anyway it is not possible to produce any exceptions with those steps either. Finally we have the additional aspects of "grabbing" a selection as discussed in Comment 5. This now behaves much better as already provided feedback on the Gerrit change. But when testing this a little bit more, unfortunately I am still able to get into a confusion situation, where it looks like the trigger table "flips" to some other selection. Steps to reproduce: 1) Open the model in Attachment 267971 [details] in a new fresh workspace 2) Make sure to put the Properties view and the Code Snippet view side-by-side in separate "view stacks", i.e. not on top of each other in the same view stack, to ensure that corresponding view layout as proposed in the Papyrus-RT specific perspective tracked by Bug 511829. 3) Open the state-machine diagram in Capsule1 4) Select the request+ transition 5) Select the anotherRequest trigger in the trigger table in the Properties view 6) Observe how the anotherRequest trigger row gets marked and the Code Snippet view shows the related trigger guard as expected 7) Now click in the Code Snippet view to start editing the guard code 8) Observe how, as you click in the Code Snippet view, it looks like the Properties view "flips" and gets refreshed. The previous selection in the trigger table gets lost. Expected would be that the selected row was still selected, but I guess it is acceptable. 9) Now click again on the anotherRequest trigger in the trigger table in the Properties view 10) Now click in the Code Snippet view to start editing the code. 11) Now there is no "flipping" in the Properties view, the selection in the trigger table is kept as one would expect. 12) Now click on some other element in the diagram, than the selected transition, e.g. a state, to get the properties view to refresh with completely different element and then click on the transition in the diagram again to re-select it. This now causes a trigger table with no selection. 13) Click on yetAnotherRequest trigger which marks it as selected 14) The Code Snippet view follows along as expected 15) Now click in the Code Snippet view to start editing the guard for the yetAnotherRequest trigger 16) Observe how the "flipping" of the Properties view appears again and how the selection in the trigger table now indicates that the anotherRequest trigger is selected, even though it was the yetAnotherRequest trigger that was selected, and is now active in the Code Snippet view This is partly the same kind of behavior that existed also before this fix, as described in Comment 5. But the "flipping" of the properties view does only happen for the trigger table itself (and not related to the tabs for diagram elements as it happened in the steps to reproduce in Comment 5). So we still seem to have some confusing behavior related to the selection in the trigger table. Not sure if this shall be covered in this bug, or if that would be covered by the other related improvements to the trigger table such as Bug 512955 or Bug 513257? Hi Peter, The problem is that the property view exist for each view separately so the flipping of the property view and the different selection in the table is normal. For example, try to select a transition from the diagram and select the trigger in the trigger table. Now select a same transition from the model explorer. Observe that the property view is flipped and the selection is different in the trigger table. There are three property tab for Model explorer, Diagram, and the Code snippet view. Without providing additional property tab for code snippet view it is not possible to use code snippet view side by side with property tab since you will have blank property tab as soon as you click on the code snippet view. If you really want to have the same selection on the trigger table then please raise a separate bug. Thanks. (In reply to Peter Cigehn from comment #9) > I have tested this in the latest Papyrus-RT build (#592). And the initial > issues with exceptions in Comment 0 are not possible to reproduce any > longer, The steps Comment 2 is not even possible to perform. Not sure if it > is due to that the steps to reproduce is not detailed enough or if the > behavior with not "grabbing" the selection causes a completely different > overall behavior. Anyway it is not possible to produce any exceptions with > those steps either. > > Finally we have the additional aspects of "grabbing" a selection as > discussed in Comment 5. This now behaves much better as already provided > feedback on the Gerrit change. But when testing this a little bit more, > unfortunately I am still able to get into a confusion situation, where it > looks like the trigger table "flips" to some other selection. > > Steps to reproduce: > > 1) Open the model in Attachment 267971 [details] in a new fresh workspace > 2) Make sure to put the Properties view and the Code Snippet view > side-by-side in separate "view stacks", i.e. not on top of each other in the > same view stack, to ensure that corresponding view layout as proposed in the > Papyrus-RT specific perspective tracked by Bug 511829. > 3) Open the state-machine diagram in Capsule1 > 4) Select the request+ transition > 5) Select the anotherRequest trigger in the trigger table in the Properties > view > 6) Observe how the anotherRequest trigger row gets marked and the Code > Snippet view shows the related trigger guard as expected > 7) Now click in the Code Snippet view to start editing the guard code > 8) Observe how, as you click in the Code Snippet view, it looks like the > Properties view "flips" and gets refreshed. The previous selection in the > trigger table gets lost. Expected would be that the selected row was still > selected, but I guess it is acceptable. > 9) Now click again on the anotherRequest trigger in the trigger table in the > Properties view > 10) Now click in the Code Snippet view to start editing the code. > 11) Now there is no "flipping" in the Properties view, the selection in the > trigger table is kept as one would expect. > 12) Now click on some other element in the diagram, than the selected > transition, e.g. a state, to get the properties view to refresh with > completely different element and then click on the transition in the diagram > again to re-select it. This now causes a trigger table with no selection. > 13) Click on yetAnotherRequest trigger which marks it as selected > 14) The Code Snippet view follows along as expected > 15) Now click in the Code Snippet view to start editing the guard for the > yetAnotherRequest trigger > 16) Observe how the "flipping" of the Properties view appears again and how > the selection in the trigger table now indicates that the anotherRequest > trigger is selected, even though it was the yetAnotherRequest trigger that > was selected, and is now active in the Code Snippet view > > This is partly the same kind of behavior that existed also before this fix, > as described in Comment 5. But the "flipping" of the properties view does > only happen for the trigger table itself (and not related to the tabs for > diagram elements as it happened in the steps to reproduce in Comment 5). > > So we still seem to have some confusing behavior related to the selection in > the trigger table. Not sure if this shall be covered in this bug, or if that > would be covered by the other related improvements to the trigger table such > as Bug 512955 or Bug 513257? (In reply to Young-Soo Roh from comment #10) > The problem is that the property view exist for each view separately so the > flipping of the property view and the different selection in the table is > normal. > For example, try to select a transition from the diagram and select the > trigger in the trigger table. Now select a same transition from the model > explorer. Observe that the property view is flipped and the selection is > different in the trigger table. There are three property tab for Model > explorer, Diagram, and the Code snippet view. Without providing additional > property tab for code snippet view it is not possible to use code snippet > view side by side with property tab since you will have blank property tab > as soon as you click on the code snippet view. > > If you really want to have the same selection on the trigger table then > please raise a separate bug. > Now I get confused once again. Yes, I can understand that you have different contents in the properties if you select the transition in the diagram vs. when you select it in the model explorer (hence the different sets of tabs related to diagram elements, like "Appearance", "Style" and so on, when selecting in the diagram). But why would there be a separate properties view content when clicking in the code snippet view? I don't understand. As discussed in the Gerrit change, the Properties view is following the selection in the model explorer and in the diagram, but I would not expect it follow the selection in the code snippet view. But I guess this is just how things work in the Eclipse then. I can (partly) see similar behavior in the legacy tooling, but then the selection in the table is lost at step 16, which is at least better since the user is not confused by an "old" and incorrect selection in the table. I think we just leave it as is then. I am not sure that we should bother. The behavior will be confusing for the user, but apparently it requires too much work to get this working. We have spent far too much time on this bug already, and I am not sure that we should spend any more time (the use of trigger guards in this way is rather seldom used anyway in my experience). Verified to be fixed in the latest Papyrus-RT build (#592). The initial issues with exceptions in Comment 0 are not possible to reproduce any longer. The steps to reproduce in Comment 2 is not even possible to perform. The remaining selection issues as discussed in Comment 9 are probably not worth fixing, since it seem to be some general issue with how Eclipse behaves. Putting this bug into verified fixed. Closing as verified fixed. |