Add CSS selector integration tests for tab selection, .active class, and preference pseudo#3983
Open
vogella wants to merge 1 commit intoeclipse-platform:masterfrom
Open
Conversation
vogella
force-pushed
the
css-tests-selector-integration
branch
from
1c9d07b to
3cb397e
Compare
Contributor
…and preference pseudo Locks in three engine behaviours that the existing matcher and parser unit tests do not exercise end-to-end: - CTabItem:selected matched rules surface on the parent CTabFolder via getSelectionForeground/Background. Programmatic CTabFolder#setSelection does not fire the SWT selection listener that CTabFolderElement registers, so the listener-driven reapply is exercised by dispatching an SWT.Selection event. - CTabFolder.active rules apply when WidgetElement#setCSSClass marks the folder as active, and a folder without that class is not painted by the rule. Clearing the class and reapplying does not revert the previously painted background, which is pinned as current behaviour. - IEclipsePreferences#node:pseudo (the contributor namespace tag form used by shipped themes per Bug 466075) matches the node and lets the preferences declaration write the keys. When two equal-specificity rules under the same pseudo write the same key, the later rule wins because viewCSS resolves the duplicate property before EclipsePreferencesHandler runs (standard CSS source-order tiebreak). Trims overlong block javadocs on the three test classes to short descriptions and inline comments.
vogella
force-pushed
the
css-tests-selector-integration
branch
from
3cb397e to
6468cbd
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds three JUnit 5 tests under
tests/org.eclipse.e4.ui.tests.css.swtthat pin engine behaviours not covered end-to-end today: howCTabItem:selectedrules surface onCTabFolder#getSelectionForeground/Backgroundand how theCTabFolderElementSWT selection listener triggers a reapply, howCTabFolder.activerules toggle onWidgetElement#setCSSClass, and how theIEclipsePreferences#node:contributorpseudo selector form (Bug 466075) lets multiple stylesheets contribute to the same preference node.Two scenarios were adjusted to match observed behaviour rather than the originally drafted expectation. The selected-foreground assertion runs against
folder.getSelectionForeground()(consistent with the existingCTabItemTest#testSelectionForeground) instead ofCTabItem#getForeground(), and the listener path is exercised by dispatching anSWT.Selectionevent because programmaticCTabFolder#setSelectiondoes not fire it. The "clearing .active reverts the background" case was flipped: the folder retains the previously painted background after the class is cleared, so the test pins that behaviour with a comment so a future revert fix shows up as a failure.The third scenario (
IEclipsePreferences#node:key) was reframed: the pseudo slot in shipped CSS is a contributor namespace tag (Bug 466075), not a preference key, andEclipsePreferencesHandleronly acts on thepreferences:declaration. An additional cascade-override test pins the source-order tiebreak: when two equal-specificity rules under the same pseudo write the same preference key, the later rule wins becauseviewCSSresolves the duplicatepreferences:property before the handler runs. The class javadocs were trimmed to single sentences with the non-obvious context kept as inline comments next to the relevant assertions.