macOS + Firefox: opens `view-source` with certain URLs.
nathanhammond opened this issue · comments
In these conditions:
- On macOS.
- Firefox is your default browser.
- Your destination URL looks like this:
https://vercel.com/turborepo/token?redirect_uri=http://127.0.0.1:9789 - You attempt to launch a browser window using
webbrowser-rs. - You get directed to
view-source:https://vercel.com/turborepo/token?redirect_uri=http://127.0.0.1
Somewhere in the path from leaving webbrowser-rs (which successfully parses using Url::parse) and navigating to the URL it appears that there is a parsing failure which results in a misinterpretation of the URL.
For bonus points, it is not a consistent failure. I believe that it is related to Firefox being in the middle of a self-upgrade. We have two user reports of this behavior with it resolving itself following completion of the upgrade.
I can reproduce it consistently.
The code that calls it is here:
https://github.com/vercel/turbo/blob/4d07f1a9d139f4d697a54a8629a9bab072b4999c/crates/turborepo-lib/src/commands/login.rs#L122
The workaround is utf8_percent_encode("http://127.0.0.1:9789", NON_ALPHANUMERIC), but I'm still curious where in the process this is failing.
After additional testing: it's actually enough to simply obscure the trailing port. This can be done by appending an & or switching the : in the redirect_uri query param to %3A. No need to go so far as full URL encoding.
I don't know which parser is failing; maybe you can identify it?
An interesting issue. Thanks for taking the time to debug it. A few questions:
- You said you're able to reproduce it consistently, so does that mean it's happening irrespective of Firefox being in the middle of an upgrade?
- Can you share the steps that allow me to reproduce it consistently? I tried this on Firefox (108.01)/macOS and not able to reproduce right now.
- Can you use this gist to share more info when you're able to reproduce this?
Thanks for helping debug this.
- macOS 13.4.1 (22F82)
- I currently have Firefox sitting in a "completed upgrade but not yet restarted" (116.0.2 running process with 116.0.3 on disk) in order to be able to reproduce it.
- Your test case, exactly as provided, results in 100% reproducible failure in my current state.
running 1 test
[2023-08-22T07:51:36Z TRACE webbrowser::os] default browser is file:///Applications/Firefox.app/
[2023-08-22T07:51:36Z TRACE webbrowser::os] about to start browser: Default for https://vercel.com/turborepo/token?redirect_uri=http://127.0.0.1:9789
[2023-08-22T07:51:36Z TRACE webbrowser::os] received status: 0
test tests::test_open_default ... ok
Before reporting this issue I almost-completely ruled out this library contributing to the problem, and that it was instead something downstream.
Adding in dbg!(urls_arr):
[src/macos.rs:86] urls_arr = "(
"https://vercel.com/turborepo/token?redirect_uri=http://127.0.0.1:9789"
)"
So it's getting to LSOpenFromURLSpec with consistent (though improperly-escaped by me) inputs.
One additional piece of context: both reproductions are Vercel-internal people and we have fun system endpoint software like CrowdStrike running as well. Just realized that there may be an additional process interception required in order to trigger this outcome. I don't know if that is somehow hooking core services.
It's somehow losing the protocol, and then treating the port as line number.
Screen.Recording.2023-08-22.at.4.18.00.PM.mov
(I'm not sure this is actionable for you, so feel encouraged to close the issue, but the next person who encounters this and searches the Internet for this information will at least have one result, not zero.)
One additional piece of context: both reproductions are Vercel-internal people and we have fun system endpoint software like CrowdStrike running as well. Just realized that there may be an additional process interception required in order to trigger this outcome. I don't know if that is somehow hooking core services.
Can you share if running open 'https://vercel.com/turborepo/token?redirect_uri=http://127.0.0.1:9789' runs into the same issue or not?
Fantastic thought. It does indeed result in the same, buggy behavior.
Then definitely sounds like an issue in a different layer - probably the CrowdStrike thing doing something funny, or simply a bug in Firefox getting triggered in specific circumstances.
I'll be closing the issue. Thanks for helping debug this promptly. Feel free to reopen if new evidence comes up that points to a problem in this crate.