Use Firefox profile folder names for browser cookies

[anhtahaylove]

Summary

• Resolve Firefox profiles from profiles.ini to the actual profile directory basename used by yt-dlp.
• Keep the human-readable Firefox profile Name as display text only.
• Migrate previously saved Firefox display-name selections to the matching folder name when profiles load.

Why

Firefox profiles.ini separates Name from Path. yt-dlp browser cookies expect the profile directory name, so selecting a profile like default-release can fail when the actual folder is i879pxds.default-release.

Reproducer

A Firefox profile entry can look like Name=default-release with Path=Profiles/i879pxds.default-release. Passing default-release to yt-dlp misses the actual profile directory; passing i879pxds.default-release works.

Verification

• bun run biome check --write src-tauri/src/commands/dependencies.rs src/components/settings/sections/NetworkSection.tsx
• bun run tsc -b
• cargo test firefox_profile_uses_the_real_directory_name --lib
• cargo check in src-tauri

Screenshots

Not included; this is a value-mapping fix and the existing settings UI remains visually unchanged.

[anhtahaylove]

Quick re-check against current upstream/main: upstream already has BrowserProfile { folder_name, display_name }, but get_firefox_profiles() still maps Name= into both fields.

For Firefox, profiles.ini can look like Name=default-release and Path=Profiles/i879pxds.default-release. yt-dlp needs the profile directory basename from Path, while Name is only display text. This PR keeps display_name user-facing and stores the real Path basename in folder_name, plus migrates old selected display names in the settings UI.

[vanloctech]

I reviewed this more closely. The PR is directionally correct and needed, but I think we should handle two cases before merging:

1. The Firefox profile migration currently only runs when the user opens Settings > Network. If a user updates the app and starts a download immediately, download/metadata/channel/polling flows can still use the legacy localStorage value, so the old bug may remain. It would be safer to migrate at the cookie settings load/sync layer, or normalize on the backend before building --cookies-from-browser.

2. Firefox profiles with IsRelative=0 or an absolute Path are currently reduced to just the basename. yt-dlp supports passing a profile path, so if the profile lives outside Firefox’s default profile root, the basename will make yt-dlp search the wrong location. We should parse IsRelative: for relative Profiles/<dir> paths, use the basename; for absolute paths, preserve the full path. The tests should cover this case too.

Overall, the PR is good and narrowly scoped. Separating the display name from the value passed to yt-dlp is the right fix, but these two edge cases would make the behavior more robust for existing users and custom Firefox profiles.

[anhtahaylove]

Updated this PR against current upstream/main and addressed both review points:\n\n- Firefox profile resolution now happens in the Rust cookie-arg path before yt-dlp receives --cookies-from-browser, so downloads/metadata/channel/polling flows no longer depend on opening Settings first.\n- \profiles.ini\ parsing now handles \IsRelative=0\ by preserving the full profile path, while relative Firefox paths still pass the real profile folder basename.\n\nAlso kept the Settings-side legacy display-name migration so the UI self-heals when users open Network settings. Added targeted Rust tests for relative paths, absolute paths, and legacy display-name resolution.

[vanloctech]

Thanks for the update. I rechecked the latest version and the two previous concerns are addressed: Firefox profile normalization now happens in the backend cookie-arg path, and IsRelative=0 / absolute profile paths are preserved instead of being reduced to a basename.

The scope looks good to me: the PR keeps the existing UI behavior, separates display name from the value passed to yt-dlp, and adds focused tests for relative paths, absolute paths, and legacy display-name migration.

I verified locally with cargo test firefox_profile --lib, cargo check, and bun run tsc -b; all passed.

The only blocker I see now is that GitHub reports the PR as conflicting with main. After rebasing/resolving the conflict and rerunning CI, I’m okay with merging this.