Created attachment 1824128 [details] Issue Description of problem: The switch status of the button "Show default project" is not revealed correctly in code. For example when we switch off the "Show default project" button, both class "no-label-switch-on-on" and "no-label-switch-on-off" can be found in HTML code. It will be hard for automation to identify the element.(Check attachment for more information) Version-Release number of selected component (if applicable): 4.9.0-0.nightly-2021-09-17-210126 How reproducible: Always Steps to Reproduce: 1. Log into OCP, navigate to Pods page 2. Click on the dropdown list for select project 3. Open developer mode on browser for tracking the HTML code 4. Switch on/off the button on "Shown default projects" 5. Verify if the code has correct elements and attributes Actual results: 5. The code of HTML is not dynamic, Even if the switch button is on 'off' status, but the class of "no-label-switch-on-on" can still be found on HTML code Expected results: 5. HTML code should reveal the actual status of the element, when the component is in 'off' states 1) the code as below should not shown <span class="pf-c-switch__label pf-m-on" id="no-label-switch-on-on" aria-hidden="true">Show default projects</span> 2) the label 'checked' should have 'false' value or use unchecked label <input id="no-label-switch-on" class="pf-c-switch__input" type="checkbox" aria-labelledby="no-label-switch-on-on" data-test="showSystemSwitch" aria-label="" checked=""> Additional info:
I've had a chance to take a look at this one and there are a couple of things going on. First, this is a PatternFly element and outputted HMTL is coming from PatternFly. Any changes would need to be sent to the PatternFly team. As a note, you can submit bugs for PatternFly at: https://github.com/patternfly/patternfly-react/issues With that said, I don't think there is an issue. If I wanted to know if the status of the switch, I would need to look at the input tag with the ID of 'no-label-switch-on' which is seen in the attached screenshot. It looks like the "Elements" tab of the Chrome Dev Console doesn't update the checked status when the switch is checked. I think this is an issue with Chrome. If, in Chrome, I move over to the Console tab and enter `document.getElementById('no-label-switch-on').checked`, I will get the correct checked state. The switch actually has two labels: one that is shown when the switch is checked and one when the switch is unchecked with IDs "no-label-switch-on-on" and "no-label-switch-on-off". You see both in the HTML, but the visibility is controlled through CSS. This is a common approach (to have both label states in the HTML) because it makes the application feel more responsive to the end-user. In this use of the switch, the labels for checked and unchecked happen to be the same text. I can get the visibility status of the label that is shown when the switch is checked (span with ID of "no-label-switch-on-on"), by entering the following in the browser's developer console `window.getComputedStyle(document.getElementById('no-label-switch-on-on')).display` Likewise I can get the visibility status of the label that is shown when the switch is unchecked (span with ID of "no-label-switch-on-off"), by entering the followign in the browser's developer console `window.getComputedStyle(document.getElementById('no-label-switch-on-off')).display` By using the IDs and some Javascript statements I can programmatically identify the switch and labels along with their corresponding statuses. @
Please let me know if the comments provided don't address your concerns. @xiyuzhao
@kdoberst Thanks for your quick and clear response The suggestion command like 'document.getElementById('no-label-switch-on').checked' is a good way to get the correct checked state, but it is hard to merge it into current automation case. Base on the current structure of the automation, if it is possible, I think the changes on the code side to make HTML return the corresponding statuses of the switch button will be a better choice。 Right now, I will continue try to merge your suggestion command to current case
After further discussion, it was determined that adding a data attribute would make testing easier.
This bug has been verified on payload 4.10.0-0.nightly-2021-10-12-203611 Verification Steps: 1. Log into OCP, navigate to Pods page 2. Click on the dropdown list for select project 3. Open developer mode on browser for tracking the HTML code 4. Switch on/off the button on "Shown default projects" 5. Verify if the attributes 'data-checked-state' is added for tracking the state of 'show default projects' button. 6. Navigate to other pages, like 'DeploymentConfigs', 'Services' 7. Verify if the changes are working on all 'showSystemSwitch' component Result: 5,7. The new attributes 'data-checked-state' is added for the component whose data-set is 'showSystemSwitch'. When the user switches on/off the button, the new attribute 'data-checked-state' will show 'true' and 'false' to help user tracking the state of the button easily
@amagrawa I somehow missed your note. Normally we don't backport low priority bugs, but since this is impacting testing and there is no functionality change, I am going to make a case to add this one. Backport PR is https://github.com/openshift/console/pull/10252
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Moderate: OpenShift Container Platform 4.10.3 security update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2022:0056