Skip to content

test_webbrowser failure on MacOS if BROWSER set to "open" #131254

Closed

Description

@smontanaro

Bug report

Bug description:

I just noticed a new-to-me failure on main for the test_webbrowser unit test. Here's the rundown:

% ./python.exe -E  -m test test_webbrowser
Using random seed: 3730311481
Raised RLIMIT_NOFILE: 256 -> 1024
0:00:00 load avg: 4.38 Run 1 test sequentially in a single process
0:00:00 load avg: 4.38 [1/1] test_webbrowser
test test_webbrowser failed -- Traceback (most recent call last):
  File "/Users/skip/src/python/cpython/Lib/test/test_webbrowser.py", line 334, in test_default
    assert isinstance(browser, webbrowser.MacOSXOSAScript)
           ~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError

0:00:00 load avg: 4.38 [1/1/1] test_webbrowser failed (1 failure)

== Tests result: FAILURE ==

1 test failed:
    test_webbrowser

Total duration: 48 ms
Total tests: run=48 failures=1 skipped=4
Total test files: run=1/1 failed=1
Result: FAILURE
% env | grep BROWSER
BROWSER=open
% unset BROWSER     
% ./python.exe -E  -m test test_webbrowser
Using random seed: 2541583609
Raised RLIMIT_NOFILE: 256 -> 1024
0:00:00 load avg: 3.19 Run 1 test sequentially in a single process
0:00:00 load avg: 3.19 [1/1] test_webbrowser
0:00:00 load avg: 3.19 [1/1] test_webbrowser passed

== Tests result: SUCCESS ==

1 test OK.

Total duration: 50 ms
Total tests: run=48 skipped=4
Total test files: run=1/1
Result: SUCCESS

In short, if the BROWSER environment variable is set to open, the test fails. (This didn't used to be the case as far as I can recall. The entire test suite passed a couple days ago with the expected skips, no failures.) If I unset BROWSER, the test succeeds.

I suspect this commit is the culprit: 96492785b202a92af1b71f8c011ea839ca3ebb07

CPython versions tested on:

CPython main branch

Operating systems tested on:

macOS

Linked PRs

Feature was introduced in #130535.

Activity

  1. smontanaro commented on Mar 14, 2025

    @smontanaro
    ContributorAuthor
  2. picnixz commented on Mar 14, 2025

    @picnixz
    Member

    AFAIU, I suggest using EnvironmentVarGuard and unset the env var, leaving it to an unset BROWSER.

  3. ned-deily commented on Mar 14, 2025

    @ned-deily
    Member

    The test should guard as @picnixz suggests. But just out of curiosity, why is BROWSER set to open in the first place? Is it for something other than python?

  4. smontanaro commented on Mar 14, 2025

    @smontanaro
    ContributorAuthor

    But just out of curiosity, why is BROWSER set to open in the first place? Is it for something other than python?

    That's the most obvious choice to me on MacOS. I don't need to include a full path to a browser (Brave, Safari, whatever). To wit:

    % type safari
    safari not found
    % type Safari
    Safari not found
    

    If I want to switch to a different default browser, MacOS allows me to do that in the settings app. No need to mess with any environment variables.

  5. minrk commented on Mar 15, 2025

    @minrk
    Contributor

    Thanks for fixing the test, @picnixz! Sorry for missing it the first time around.

    @smontanaro I think the question was about why override BROWSER to open explicitly when this already matches the default behavior, unless the reason is for something other than Python where maybe it doesn't match.

  6. smontanaro commented on Mar 15, 2025

    @smontanaro
    ContributorAuthor

    @smontanaro I think the question was about why override BROWSER to open explicitly when this already matches the default behavior, unless the reason is for something other than Python where maybe it doesn't match.

    I'm not entirely sure, but... I have the same setting on my old Dell (predecessor to my Mac). It runs Ubuntu, which has /usr/bin/open. It's likely the setting just came along for the ride. (I keep my config files in Git.) I don't think it's Python-specific either:

    https://askubuntu.com/questions/27447/google-earth-and-browser-environment-variable

    Edit: Which is to say maybe there are other tools which use BROWSER but don't default to open if unset.

  7. picnixz commented on Mar 16, 2025

    @picnixz
    Member

    @smontanaro Can you have a look at the PR to check if it works? I can't request you for review. TiA

  8. smontanaro commented on Mar 16, 2025

    @smontanaro
    ContributorAuthor

    I looked at the diff, but the code in that section of my latest pull didn't look at all like it. I assumed it had already been merged to main, so didn't try. In any case, test_webbrowser passes once again on main, so it seems the fix worked.

  9. picnixz commented on Mar 16, 2025

    @picnixz
    Member

    I assumed it had already been merged to main, so didn't try.

    I don't think I've merged it but maybe it's because of some side-effects that it's still passing? anyway, I think it doesn't hurt to simply unset the environment variable temporarily. Or @hugovk (you're the only other one I know who's using a mac, sorry for the ping...) maybe you could check if it passes on your mac if you do BROWSER=open python -m test test_webbrowser?

  10. smontanaro commented on Mar 16, 2025

    @smontanaro
    ContributorAuthor

    I looked at the diff, but the code in that section of my latest pull didn't look at all like it. I assumed it had already been merged to main, so didn't try. In any case, test_webbrowser passes once again on main, so it seems the fix worked.

    Ack! I had unset BROWSER at one point, so that's why it was passing...

    I can confirm that applying the change from your PR fixes the test.

  11. hugovk commented on Mar 16, 2025

    @hugovk
    Member

    Or @hugovk (you're the only other one I know who's using a mac, sorry for the ping...) maybe you could check if it passes on your mac if you do BROWSER=open python -m test test_webbrowser?

    Likewise confirmed!

  12. added a commit that references this issue on Mar 16, 2025
  13. picnixz commented on Mar 16, 2025

    @picnixz
    Member

    As I said on the PR, no need for bp as the test was added in #130535. Thanks for the report and for testing my fix!

  14. added a commit that references this issue on Mar 17, 2025
  15. added 2 commits that reference this issue on May 8, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    3.14bugs and security fixesOS-mactestsTests in the Lib/test dirtype-bugAn unexpected behavior, bug, or error

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions