macOS – Disappearance of Check Mark from UI Dropdowns

Actually i have found solution of this issue. It seems apple didn't handled unusual cases with new Favorites tab introduced in Yosemite as far as i remember - but this is actually easy to predict, shame on you apple.

I have quite a lot pages in bookmarks (old styled, dropdown menu), and favorites tab, in favorites i have subdirectory with bitcoin exchanges. Some of those exchanges use cloudflare to prevent ddos attacks, and form time to time ask for captcha verification. It seems each time user click on URL Field in safari, favorites bookmarks appear, and safari try to download icons and maybe other meta data for each page, and then in case unusual response, it stucks safari and waste cpu on creating many threads for nothing, im not sure if it actually retry and try download again or it's strictly connected to processing downloaded metadata from page but it just make uncountable number of threads and block cpu with junk calculations. Im not exactly sure if it's caused by cloudflare check or by any other corrupted response. But finally i have moved all bitcoin exchanges subdirectory do old styled bookmarks, where obviously metadata or/and image is not being downloaded.

In case someone will need to fix it, just monitor bookmarks and safari cpu usage, and remove one by one from favorites, restart safari, and again until eliminate issue.

ErikMH's answer gave me the idea to first just try to revert the sudoers file, without reverting/upgrading my whole system again. So in short:

1. Run this to get a root shell: sudo -s
2. Make a copy of /private/etc/sudoers
3. Run: cp /private/etc/sudoers\~orig /private/etc/sudoers
4. Fix permissions by running: chmod 440 /private/etc/sudoers ; chown root:wheel /private/etc/sudoers
5. Move any files in /private/etc/sudoers.d/ away from there
6. Test out sudo in another terminal
7. Don't forget to exit this shell to prevent inadvertently running commands as root when you don't mean to

Now running sudo should work again.

Next step is to check the differences between the old sudoers file (you copied away in step 2) and the current one and add those changes step by step back to /private/etc/sudoers or /private/etc/sudoers.d/, each time running a command using sudo to check if the change breaks it.

In my case, I had specified a nonexistent group in the sudoers file. Correcting that fixed my issue.