Clicking labels should trigger click of associated element

[jonathansampson]

Test plan

#10470 (comment)

---

• Did you search for similar issues before submitting this one?
  Yes

• Describe the issue you encountered:
  Throughout Brave, many controls have an associated label. Clicking these labels doesn't trigger a click of the associated element.

• Platform (Win7, 8, 10? macOS? Linux distro?):
  Desktop

• Brave Version (revision SHA):
  61ae1a7

• Steps to reproduce:

  1. Open Brave Shields on GitHub.com
  2. Click HTTPS Everywhere label

• Actual result:
  Nothing happens

• Expected result:
  The associated element's state toggles

• Will the steps above reproduce in a fresh profile? If not what other info can be added?
  Yes

• Is this an issue in the currently released version?
  Yes

• Can this issue be consistently reproduced?
  Yes

• Extra QA steps:

  1. Match Case in Find on Page UI
  2. Many places throughout about:preferences

• Screenshot if needed:
  

[bsclifton]

Great first bug 🐛 😄 👍

Changes can be made to the SwitchControl component

[petemill]

I just took a look at this. Making the change to the switchControl to also perform the onClick for the text does fix this for some occurrences (e.g. the Brave panel, the Clear browsing data modal and the messageBox component).

However, in some other uses, a wrapper component is used which does not provide the label text as a prop to the switchControl component. These components render their own <label /> as a sibling to the switch. They expect switchControl to render an 'id' attribute, and add a 'for' attribute on the label, most likely expecting the click to happen that way. switchControl is not (anymore?) rendering an 'id' attribute. It's probably not the best idea anyway since it creates an expectation that a component will render html in a specific way, which of course can change (as it perhaps has in this case). The git history of switchControl (and others) was not preserved during the folder structure change, so I wasn't immediately able to see what came first. It's happening in these uses:

• SettingCheckbox in about:preferences
• caseSensitivityCheckbox in findbar.js

Since switchControl supports rendering text identically the same as these components are doing with their own <label /> element, including localization, it's probably best to convert these uses to the built-in text functionality. I also found that the entirety of the styles for switchControl is duplicated in less/about/preferences.less, with some additions and conflicting layout style that seem minor at first glance (inline-block vs flex), so I'll look at refactoring that and removing the duplication.