Bug 502059 - [CSS] Order of stereotype applications influences CSS matching
Summary: [CSS] Order of stereotype applications influences CSS matching
Status: UNCONFIRMED
Alias: None
Product: Papyrus
Classification: Modeling
Component: Diagram (show other bugs)
Version: 2.0.2   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-09-23 08:25 EDT by Johan Van Noten CLA
Modified: 2019-05-08 18:38 EDT (History)
3 users (show)

See Also:


Attachments
Remove the <<Metaclass>> stereotypeapplication to see that the Block suddenly becomes Orange. (3.18 KB, application/x-zip-compressed)
2016-09-23 08:25 EDT, Johan Van Noten CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Johan Van Noten CLA 2016-09-23 08:25:47 EDT
Created attachment 264377 [details]
Remove the <<Metaclass>> stereotypeapplication to see that the Block suddenly becomes Orange.

Environment: Papyrus & SysML1.4 today's nightly

Scenario (reproduction model attached):
* You want to create a CSS style to color some elements based on stereotype properties.
* Create a css file and include for instance:
[appliedStereotypes~="SysML::Blocks::Block"][isEncapsulated] {
	fillColor : orange;
}
* Create a model that contains a Block, set its "isEncapsulated" property to true.
* Apply the given stylesheet.
* The Block is colored orange --> everything ok.

* Now remove the Block stereotype and apply for instance "Metaclass" from the StandardProfile (just as a test, any other stereotype will do).
* The element is not colored orange anymore --> ok.

* Now add the Block stereotype again (with isEncapsulated=true), leaving the Metaclass stereotype in place.
--> The element is _not_ colored orange --> Problem

Conclusion:
In case the stereotype field for which the CSS rule is filtering is not the first one in the list of stereotypeApplications, the rule fails to match.

Already tried:
Suppose you would leave out the property filter (isEncapsulted), the Block stereotype is found also if it is the second in the list.
It therefore really seems to be the additional property filter that makes the difference.

Potentially the cause is similar to #455620...
Comment 1 Klaas Gadeyne CLA 2016-10-17 08:58:01 EDT
Confirmed.
(Cumbersome) Workaround: Use the arrows in the profile tab of the properties to manually reorder the stereotype applications
Comment 2 Johan Van Noten CLA 2016-10-17 14:24:01 EDT
The workaround is of course only valid if your CSS depends on properties of one stereotype only.
Comment 3 Johan Van Noten CLA 2017-01-10 04:43:47 EST
Reproduced on Neon.2.
Comment 4 Alan Cook CLA 2019-05-08 18:38:37 EDT
Bug is in org.eclipse.papyrus.sysml14.diagram.common.css.dom.GMFSYSMLElementAdapter line 223 in doGetAttribute() (in org.eclipse.papyrus.sysml14.diagram.common 1.3.1).  Rather than checking all stereotypes, it only checks the first and then returns null.