[cookies] Add --cookies-from-browser support for Whale

[roeniss]

Description of your pull request and other information

Currently, yt-dlp doens't support --cookies-from-browser Naver Whale browser because the browser uses its own directory in Windows, macOS, and Linux.

Luckily, Naver Whale is based on Chromium, so thanksfully I could just add a little bit of code.

Fixes #9307

• I didn't add a test because cookie-related tests seems that it doens't test each of browsers. But If it's needed, please tell me then I'll try my best.
• I did dog-fooding with macOS 14.2, Ubuntu Desktop 22.04, Windows 11. I failed on Windows because of --cookies-from-browser errors when Chrome/chromium-based browser is open in Windows #7271 but the user data directory is confirmed

Before submitting a pull request make sure you have:

• At least skimmed through contributing guidelines including yt-dlp coding conventions
• Searched the bugtracker for similar pull requests
• Checked the code with flake8 and ran relevant tests

In order to be accepted and merged into yt-dlp each piece of code must be in public domain or released under Unlicense. Check all of the following options that apply:

• I am the original author of this code and I am willing to release it under Unlicense
• I am not the original author of this code but it is in public domain or released under Unlicense (provide reliable evidence)

What is the purpose of your pull request?

• Fix or improvement to an extractor (Make sure to add/update tests)
• New extractor (Piracy websites will not be accepted)
• Core bug fix/improvement
• New feature (It is strongly recommended to open an issue first)

edit: Add a mention for dog-fooding

[pukkandan]

#2903

[bashonly]

@pukkandan see #9307. Whale uses a different keyring name on linux and can't be supported as chromium/chrome

[pukkandan]

I see. Is this a common thing? Is #7805 similar issue? If so, it would be more beneficial to support passing keyring name in the CLI than adding just whale.

[bashonly]

Is #7805 similar issue?

Looks like possibly yes, but really there's no way to tell from the limited info in that issue.

If so, it would be more beneficial to support passing keyring name in the CLI than adding just whale.

Maybe? But cramming more into the --cookies-from-browser syntax would not be great IMO. Would the user even necessarily know what the keyring name is? I think it might be better to add proper support for these browsers, as the alternative is involuntarily maintaining some sort of knowledge bank of keyring names in our tracker that we direct users to every time we get a dupe issue opened about one

[pukkandan]

I am concerned the list will quickly grow too large, but I see your point. We can merge this for now and think of generalization if this keeps coming up

[roeniss]

Wait please, I'll review my PR within 24 hours from now. Some fix seems not merged.

[coletdjnz]

Is #7805 similar issue?

Looks like possibly yes, but really there's no way to tell from the limited info in that issue.

If so, it would be more beneficial to support passing keyring name in the CLI than adding just whale.

Maybe? But cramming more into the --cookies-from-browser syntax would not be great IMO. Would the user even necessarily know what the keyring name is? I think it might be better to add proper support for these browsers, as the alternative is involuntarily maintaining some sort of knowledge bank of keyring names in our tracker that we direct users to every time we get a dupe issue opened about one

I think at this point we should support more browsers for convenience of the user..

Large list of supported browsers doesn't matter imo. You could throw the full list into a section of the README, with only the main few listed on the option help string

[roeniss]

code check is done.

I think there must be serveral ways instead of adding one by one. We just temporarily need more browsers example to decide which way to go. This is one of them.

[roeniss]

Should I do something else to be merged?

[roeniss]

@pukkandan gentle ping