| Commit-Queue | +1 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Will TAL after awado@ reviewed for security_page :)
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
disabled="[[!isHttpsFirstModeEnabled_(Does the disabled attribute need to be repeated for each controlled radio button if it's on the settings-radio-group? I'm not sure so if you can check it out and keep or remove based on your analysis that would be sweet!
await microtasksFinished();nit: I believe its preferred to use `await flushTasks()`
await microtasksFinished();nit: use `await flushTasks()`
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Commit-Queue | +1 |
Does the disabled attribute need to be repeated for each controlled radio button if it's on the settings-radio-group? I'm not sure so if you can check it out and keep or remove based on your analysis that would be sweet!
I tested some things and it looks like:
So I've removed the attribute from the `settings-radio-group` and updated the tests accordingly.
nit: I believe its preferred to use `await flushTasks()`
Done
await microtasksFinished();Joshua Hoodnit: use `await flushTasks()`
Done
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
#safeBrowsingRadioGroup, #httpsFirstModeRadioGroup {Nit: why not instead use the common element type?
#safeBrowsingRow, #passwordsLeakToggle {Recommendation: I'd recommend avoiding implicitly hardcoding which rows you expect to be on top, in the middle, or in the bottom. This can lead to unnecessary complexity, e.g. when further rows get added in the future behind a feature. I'd instead recommend to let CSS selectors handle that where possible, e.g. via something like `:first-of-type` (and its inverse via `:not(...)`)
(row as any).expanded, 'Initially, the row should be collapsed');Nit: Is this needed? I wouldn't expect it to
const expandButton =
page.$.httpsFirstModeRow.shadowRoot!
.querySelector<CrExpandButtonElement>('#expandButton');I think it would make sense to expose those buttons as part of the row's interface, so that tests don't consistently need to query them, and so that local variables like those one aren't needed. (Same below)
// Click on the expand button, expands content and we can see the radioNit: generally avoid "we". Where the entity is necessary, instead state the entity (e.g. company, product). In cases like this leave it out.
(Also, general tip for comments: the code should be written so that it explains the "what". Comments should focus on explaining only the "why". Sticking with that paradigm you might be able to remove some comments throughout those tests, and tweak some others to focus only on the "why".)
await microtasksFinished();Nit: Not needed? (Same below)
// Set to DISABLED initiallyNit: comments need period at the end
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Commit-Queue | +1 |
#safeBrowsingRadioGroup, #httpsFirstModeRadioGroup {Nit: why not instead use the common element type?
Done.
I thought that would end up affecting the styling of `#bundlesRadioGroup`, but I tried it out and it does not. Thanks!
Recommendation: I'd recommend avoiding implicitly hardcoding which rows you expect to be on top, in the middle, or in the bottom. This can lead to unnecessary complexity, e.g. when further rows get added in the future behind a feature. I'd instead recommend to let CSS selectors handle that where possible, e.g. via something like `:first-of-type` (and its inverse via `:not(...)`)
Done.
I thought about that, but it couldn't see a way to make it work with the page's current structure. I've wrapped the sections in divs now so that I can apply it in that way though.
I also have a follow-up [CL](crrev.com/c/7201464) in progress that will use some of the other shared settings styling and gets rid of the need for this.
(row as any).expanded, 'Initially, the row should be collapsed');Nit: Is this needed? I wouldn't expect it to
Actually looking deeper into this, chrome/test/data/webui/settings/security_page_feature_row_test.ts has tests that cover all of this behavior for the component already. This test is redundant and removing it should be fine.
const expandButton =
page.$.httpsFirstModeRow.shadowRoot!
.querySelector<CrExpandButtonElement>('#expandButton');I think it would make sense to expose those buttons as part of the row's interface, so that tests don't consistently need to query them, and so that local variables like those one aren't needed. (Same below)
Based on our offline conversation, right now this might not work well in practice since the expand button is switched when the row is expanded or collapsed.
This test case is redundant, so I'm removing it from this CL, but will expose the button as part of the row's interface in the same follow-up that makes sure there is only one expand button for each row.
// Click on the expand button, expands content and we can see the radioNit: generally avoid "we". Where the entity is necessary, instead state the entity (e.g. company, product). In cases like this leave it out.
(Also, general tip for comments: the code should be written so that it explains the "what". Comments should focus on explaining only the "why". Sticking with that paradigm you might be able to remove some comments throughout those tests, and tweak some others to focus only on the "why".)
Acknowledged
Nit: Not needed? (Same below)
Acknowledged
Nit: comments need period at the end
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Hi Avi, could you PTAL at the lint changes in chrome/browser/ssl/https_first_mode_settings_tracker.h?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
[Bundled Security Settings] Add "Secure connections" feature row
This CL adds a security settings feature row for "Secure connections"
(AKA HTTPS-First Mode) to the Bundled Security Settings version of the
chrome://settings/security page.
Currently, the toggle is only visible when the feature row's dropdown is
expanded. A subsequent CL will make the toggle always visible.
Screenshot: crbug.com/460195217#comment5
NO_IFTTT=changes to
`chrome/browser/ssl/https_first_mode_settings_tracker.h` are updates to
`LINT.ThenChange()` comment itself.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |