Falling back to "open_new" feels like "errors passing silently" to me. Why was this choice made?

As a user of the API I'd be disappointed if an URL is opened in regular mode when I explicitly asked to open it in incognito mode. I'd therefore prefer to raise an exception when incognito mode isn't available.

For use cases where incognito mode is preferred but optional the user can code this themselves, whereas you cannot build my preferred semantics on top of the current implementation.

The two API use cases are different: open_new_tab vs open_new is "just" a different look and feel. "open_incognito" has semantic differences in the browser state (such as not storing the page in long term history and separate cookie stores). Opening a page in a regular window when an incognito window was requested can result in unwanted side effects.

I wouldn't mind a keyword argument to enable a fallback to open_new, but it shouldn't be the default. Just like exists_ok defaults to false in os.makedirs. Something like def open_incognito(url, *, regular_ok=False).

I agree with @ronaldoussoren: if a user is asking to keep their private URL secret, we must not "leak" that to the open internet, which could have extremely serious consequences for some people. Let's raise an exception instead.

Regarding Opera: if the user asks for a regular tab and it opens in private tab, that's fine, nothing is leaked.

We've plenty of time: 3.13 will be released in October 2024 with a May 2024 deadline to get new features in.

For documentation, something like:

webbrowser.open_private(url)
Open url in a private/incognito window of the default browser, if possible, otherwise raise RuntimeError.

@ronaldoussoren has already made the proposal, @kr-g please could you update this PR?

I have no preference on whether it should be an exception of a separate method or a permissive argument.

I can agree with others about the issue in general only because a user who is supposed to get the incognito mode most likely will be unaware of it. So we have a choice between "always show user a warning in advance" vs "let the application gracefully treat a failure by showing an absolutely relevant warning with instructions (or an error if the very fact of page visitation must not be leaked)". Personally, I prefer the second option.

The exact interface choice is out of my competence.

Why do we have -b and -l added? I am not opposed to this, but again: this feature is not related.

If you feel like adding this feature is a good idea (it looks like it might be), please open a new issue: explain the use-case and the "why".

But, let's keep this PR simple: only incognito mode.

it is related to the cmdline interface when webbroser main() func is called.
they belong also to the newly added incognito method.
therefore it is not a new feature from my perspective.

This is not resolved at all. These are separate new additions.

Agreed

We do appreciate your contribution here!
As the PR author, you are in the best place to address the review by removing the code added to support --browser.
That can be discussed in a separate issue. But if you don’t have the time, then someone else could complete the PR.

for me this is a migration topic. the experts do know better what to do here. myself i dont see here in the working loop since i dont have this detailed knowledge of what being best on master code baseline

Sorry, I don’t understand «migration». There are clear requests to remove some code that was added, to keep this PR focused on one thing. If you don’t want to pursue it, then someone else will have to volunteer.