Open d3-X-t3r opened 7 months ago
Thanks for submitting this @d3-X-t3r! We're actively working on this issue so we appreciate your opening.
CC @daprahamian is working on this issue.
Hi @d3-X-t3r! Thank you for filing, I'm gonna ask a few questions.
Unable to open url
in your logsxdg-open https://app.warp.dev/signup/remote
and let me know if it properly opens the url in your browser?Thanks, Dan
hey, I also had this issue but just navigating to https://app.warp.dev/signup/remote (in the browser) was enough for it to work for me.
Using X11 btw Firefox is set as default browser
Other external links throughout warp also are not working for me (Discord, Docs, and Feedback buttons in Warp Essentials menu, "View Documentation" buttons)
Hi @d3-X-t3r! Thank you for filing, I'm gonna ask a few questions.
1. Can you confirm for me that you do not see a warning saying `Unable to open url` in your logs 2. Can you try running `xdg-open https://app.warp.dev/signup/remote` and let me know if it properly opens the url in your browser? 3. Are you running in any sort of environment (docker, vm, wsl)? 4. Do you still see this issue when running Warp without Wayfire?
Thanks, Dan
Hi Dan,
xdg-open https://app.warp.dev/signup/remote
opens the url in FirefoxThanks
It tries to open /opt/firefox/firefox-bin https://app.warp.dev/signup/remote
and stays there as an zombie process.
I'm on Arch linux with Gnome and have installed firefox-dev-edition manually. I do have /opt/firefox/firefox-bin
, but I don't think that is the binary that should be opened. It should try /opt/firefox/firefox
or better /usr/local/bin/firefox
xdg-open does work for me
xdg-open https://app.warp.dev/signup/remote
Here's the link to documentation that it "tries" to open from the app itself:
same issue im having, same exact circumstances except im running ubuntu. I tried installing warp through the official website (.deb file) and I was successfully able to until I hit the sign in page with the same bug.
Thank you so much for your help @d3-X-t3r @eboye @Felos9001 @vihangatheturtle! I have been able to reproduce some of this to a degree. It does appear that there is some sort of issue when attempting to spawn a firefox process from within rust that causes it to hang.
I have been able to replicate this by downloading the firefox tar manually from mozilla. I have NOT been able to replicate it using the snap or apt instances of firefox.
I will continue to investigate more tomorrow.
Exact same issue here on Fedora 39 with .rpm installation.
Running warp-terminal
in another terminal. This is the output:
$ warp-terminal
warp-terminal: /lib64/libcurl.so.4: no version information available (required by warp-terminal)
stdout is a tty true, in CI false. using logfile: false
11:22:29 [INFO] Spawning terminal server process...
/opt/warpdotdev/warp-terminal/warp: /lib64/libcurl.so.4: no version information available (required by /opt/warpdotdev/warp-terminal/warp)
11:22:29 [INFO] Running terminal server...
11:22:29 [WARN] Failed to load font: Hack due to error Font family Hack does not contain any valid fonts
11:22:29 [INFO] Failed to read User from secure storage NotFound
11:22:29 [INFO] Initializing crash reporting Some("stable_release") with tag "v0.2024.02.20.08.01.stable_01"...
11:22:29 [INFO] Starting warp with channel state ChannelState { channel: Stable, app_id: AppId { qualifier: "dev", organization: "warp", application_name: "Warp" }, additional_features: {}, firebase_api_key: "AIzaSyBdy3O3S9hrdayLJxJ7mriBR4qgUaUygAs", server_root_url: "https://app.warp.dev", ws_server_url: "wss://rtc.app.warp.dev/graphql", session_sharing_server_url: Some("wss://session-sharing-server-o3mgmiurkq-uk.a.run.app"), segment_write_key: "sTT9ZajzIaQ0phzLFOnqZ6VOqplJTlaJ", segment_root_url: "https://api.segment.io", releases_base_url: "https://releases.warp.dev", sentry_url: "https://0195a81da0714f55a93ee4624825f9ec@o540343.ingest.sentry.io/5658526", logfile_name: "warp.log", show_autoupdate_menu_items: true, skip_login: false } and version Some("v0.2024.02.20.08.01.stable_01")
11:22:29 [INFO] Performance metrics collector started
11:22:29 [INFO] Initializing app services
11:22:29 [INFO] Start to flush telemetry events to Segment
11:22:29 [INFO] Start to flush telemetry events to Segment
11:22:29 [WARN] Detected skylake derivative running on mesa i915. Clears to srgb textures will use manual shader clears.
11:22:29 [INFO] Connecting to SQLite database
11:22:29 [INFO] Checking for update on channel stable_release. Update id is I6g7VKT
11:22:29 [INFO] Fetching channel versions (without changelogs) from Warp server
11:22:29 [INFO] fetching team tester status
11:22:29 [INFO] dispatching global action for root_view:open_from_restored
11:22:29 [INFO] dispatching global action for root_view:open_new
11:22:29 [WARN] error getting team tester status: Failed to get access token for GraphQL request. Falling back to in-memory state.
11:22:29 [INFO] Guessed window scale factor: 1
11:22:29 [INFO] Enabled wgpu backends: Backends(VULKAN | GL | METAL | DX12 | DX11 | BROWSER_WEBGPU)
11:22:29 [INFO] Available wgpu adapters:
11:22:29 [WARN] Detected skylake derivative running on mesa i915. Clears to srgb textures will use manual shader clears.
11:22:29 [INFO] IntegratedGpu: Intel(R) Iris(R) Plus Graphics (ICL GT2)
11:22:29 [INFO] Driver: Intel open-source Mesa driver (Mesa 23.3.4)
11:22:29 [INFO] Cpu: llvmpipe (LLVM 17.0.6, 256 bits)
11:22:29 [INFO] Driver: llvmpipe (Mesa 23.3.4 (LLVM 17.0.6))
11:22:29 [INFO] IntegratedGpu: Mesa Intel(R) Iris(R) Plus Graphics (ICL GT2)
11:22:29 [INFO] Driver: Unknown
11:22:29 [WARN] Detected skylake derivative running on mesa i915. Clears to srgb textures will use manual shader clears.
11:22:29 [INFO] Using IntegratedGpu (Intel(R) Iris(R) Plus Graphics (ICL GT2)) for rendering new window.
11:22:29 [WARN] redraw_frame was called 2 times before the frame was drawn
11:22:29 [INFO] active window changed: Some(WindowId(0))
11:22:29 [INFO] dispatching global action for root_view:update_quake_mode_state
11:22:29 [INFO] dispatching global action for workspace:save_app
11:22:29 [WARN] redraw_frame was called 3 times before the frame was drawn
11:22:29 [INFO] Received channel versions from Warp server: dev: ChannelVersion { version_info: VersionInfo { version: "v0.2024.02.22.08.02.dev_00", update_by: None, soft_cutoff: Some("v0.2023.05.12.08.03.dev_00") }, overrides: [] }; preview: ChannelVersion { version_info: VersionInfo { version: "v0.2024.02.22.08.02.preview_00", update_by: None, soft_cutoff: None }, overrides: [] }; canary: ChannelVersion { version_info: VersionInfo { version: "v0.2022.09.29.08.08.canary_00", update_by: None, soft_cutoff: None }, overrides: [] }; beta: ChannelVersion { version_info: VersionInfo { version: "v0.2024.02.20.08.02.beta_00", update_by: None, soft_cutoff: None }, overrides: [] }; stable: ChannelVersion { version_info: VersionInfo { version: "v0.2024.02.13.08.02.stable_00", update_by: None, soft_cutoff: Some("v0.2023.12.19.08.02.stable_00") }, overrides: [VersionOverride { predicate: TargetOS(Linux), version_info: VersionInfo { version: "v0.2024.02.20.08.01.stable_01", update_by: None, soft_cutoff: None } }] }
11:22:29 [INFO] No update available
11:22:30 [INFO] Flushed telemetry events.
11:22:30 [INFO] Successfully flushed events to segment from disk
11:22:31 [INFO] active window changed: None
11:22:31 [INFO] dispatching global action for root_view:update_quake_mode_state
11:22:31 [INFO] dispatching global action for workspace:save_app
11:22:34 [INFO] active window changed: Some(WindowId(0))
11:22:34 [INFO] dispatching global action for root_view:update_quake_mode_state
11:22:34 [INFO] dispatching global action for workspace:save_app
11:22:36 [INFO] dispatching typed action: Signup
11:22:36 [WARN] redraw_frame was called 2 times before the frame was drawn
11:22:37 [INFO] active window changed: None
11:22:37 [INFO] dispatching global action for root_view:update_quake_mode_state
11:22:37 [INFO] dispatching global action for workspace:save_app
11:22:39 [INFO] active window changed: Some(WindowId(0))
11:22:39 [INFO] dispatching global action for root_view:update_quake_mode_state
11:22:39 [INFO] dispatching global action for workspace:save_app
11:22:40 [WARN] Suboptimal present of frame 0
11:22:40 [WARN] Suboptimal present of frame 1
11:22:40 [WARN] Suboptimal present of frame 2
11:22:42 [WARN] Suboptimal present of frame 3
11:22:42 [INFO] dispatching typed action: Signup
11:22:42 [WARN] Suboptimal present of frame 4
11:22:43 [WARN] Suboptimal present of frame 0
11:22:43 [INFO] active window changed: None
11:22:43 [INFO] dispatching global action for root_view:update_quake_mode_state
11:22:43 [INFO] dispatching global action for workspace:save_app
11:22:47 [INFO] active window changed: Some(WindowId(0))
11:22:47 [INFO] dispatching global action for root_view:update_quake_mode_state
11:22:47 [INFO] dispatching global action for workspace:save_app
11:22:47 [INFO] active window changed: None
11:22:47 [INFO] dispatching global action for root_view:update_quake_mode_state
11:22:47 [INFO] dispatching global action for workspace:save_app
I've installed liburl and liburl-devel to try again, the same log lines appear again:
warp-terminal: /lib64/libcurl.so.4: no version information available (required by warp-terminal)
stdout is a tty true, in CI false. using logfile: false
11:39:13 [INFO] Spawning terminal server process...
/opt/warpdotdev/warp-terminal/warp: /lib64/libcurl.so.4: no version information available (required by /opt/warpdotdev/warp-terminal/warp)
...
...
I've checked and /lib64/libcurl.so.4
actually exists in my system.
Some command output for your reference.
user@localhost ~ $ ldd /usr/bin/warp-terminal | grep curl
/usr/bin/warp-terminal: /lib64/libcurl.so.4: no version information available (required by /usr/bin/warp-terminal)
libcurl.so.4 => /lib64/libcurl.so.4 (0x00007f409ac79000)
user@localhost ~ $ ls -l /lib64/libcurl.so.4
lrwxrwxrwx. 1 root root 16 12月 6 08:00 /lib64/libcurl.so.4 -> libcurl.so.4.8.0*
I found in a forum thread that this is caused by the libcurl compiled without version information. This comment stated that install a curl by compiling from scratch with this command solves his issue:
./configure --with-openssl --enable-versioned-symbols
This can probably work for me too, but it would not be ideal for people who want leave their software installed to distro packages and all the updates. Since this seems to be happening on both Debian and Fedora, I guess major distro don't use the version symbol option for their stock packages.
It's best if warp-terminal have a different way to determine the libcurl version than this.
The standard way would be to use the package format provided dependency declarations:
Or you may use the library version information check function somehow:
My issues seems to be a bit different than the original post here. I've created #4255 for my issue.
And I am using the AppImage, also keeping me in the SignUp dialog, with firefox zombie threads in the background. Since AppImage should contain all libs as far as I know, it might not be an issue related to missing lib symbols.
Anyway, still beta:
The image above only shows the zombie threads in the right top corner. Down below was the recent output of the warp terminal AppImage. If you need further details, please let me know.
There are many reasons why something like this could fail, the user may just not have a default web browser configured. That's why you should always have the url written out for manual entry, especially when there's no login link to find on the website.
I ran into this issue while trying Warp for the first time on stock Ubuntu 22.04 LTS. Lots of zombie Firefox threads, forced me to restart the entire computer because Firefox failed to shutdown. No tabs opened after repeatedly clicking the Sign Up button. I was eventually able to see the signup URL in htop
and open it manually from there. Please just provide a URL for manual entry into the browser, or better yet get rid of the requirement to log in entirely.
or better yet get rid of the requirement to log in entirely.
@strophy see #900
I also noticed the multiple firefox processes in htop. It caused my computer to use 100% on all my CPU threads. My desktop environment was really sluggish and laggy, performance was garbage. Not sure exactly what is wrong with those firefox processes.
I also noticed the multiple firefox processes in htop. It caused my computer to use 100% on all my CPU threads. My desktop environment was really sluggish and laggy, performance was garbage. Not sure exactly what is wrong with those firefox processes.
same thing for me
Signup link does the same thing on Ubuntu 23.10 with X11 -- moves to page with auth token and that's all she wrote.
Firefox has, after several attempts, enough 100% CPU threads to choke a...um...CPU.
There is also absolutely no place I could find to create an account on the website and I looked, and looked, and looked.
So...dead in the water, have to kill firefox.
Signup link does the same thing on Ubuntu 23.10 with X11 -- moves to page with auth token and that's all she wrote.
Firefox has, after several attempts, enough 100% CPU threads to choke a...um...CPU.
There is also absolutely no place I could find to create an account on the website and I looked, and looked, and looked.
So...dead in the water, have to kill firefox.
And, after killing firefox, a dozen or more of those extra processes are still there and have to be individually killed.
Circling back to this, our current suspicion is that something in the recent firefox release (v123) is causing issues. We are seeing issues where the spawned firefox process is unable to connect to the compositor. Going to continue diving into this. We are not seeing this issue on Firefox 122.
Please let us know if you are seeing this issue and either
a. are not using firefox as your default browser, or b. are using a version of firefox earlier than v123
Firefox is indeed 123.0, Firefox is default browser, many (a full htop screen's worth) 100% processes left running even after quitting Firefox, and I confirmed that the stray processes are the same firefox-bin and that there are no other firefox executables on my system that might be getting inadvertently called and hung up "behind" the main firefox possibly waiting for the compositor to be released by the firefox browser invoked by the user .
The main "firefox" executable that throws off the usual "firefox-bin" is no longer running, but the "firefox-bin" processes that got spun up by the warp signup did not terminate when the main "firefox" executable was terminated. It looks like they're not owned by the main "firefox" process and perhaps that's why they're not getting any cooperation vis a vis the compositor.
123 dev edition as default and it's the only instance of it installed.
Thanks @eboye @ssteinerx ! To further track this down, do you still see the bug if you start warp with WARP_ENABLE_WAYLAND=1
?
WARP_ENABLE_WAYLAND=1 warp-terminal
Thanks @eboye @ssteinerx ! To further track this down, do you still see the bug if you start warp with
WARP_ENABLE_WAYLAND=1
?WARP_ENABLE_WAYLAND=1 warp-terminal
nope, started like that it actually works as it should.
I have some stray parts of wayland that got installed by default but I'm not using wayland.
But I'll try it anyway...
Well...that was exciting...It brought up the sign-up page right next to the other tabs in Firefox.
I'm sure that totally makes sense...to someone who is not me...
I fixed this by switching my default browser to brave, and the pop up works from the terminal, however, it does not work with Firefox. And as mentioned, i just copied the link from brave back to Firefox to continue to sign in.
Some useful comments from #4255 (which was closed as a duplicate of this issue )
https://github.com/warpdotdev/Warp/issues/4255#issuecomment-1960755233
https://github.com/warpdotdev/Warp/issues/4255#issuecomment-1961677011
hey folks, we just released an update (v0.2024.02.20.08.01.stable_02
) to the Linux client (for x11 only) that should help resolve some of the login issues with Firefox.
Please install the latest version and let us know if that helped.
x11 ... so no love for us on Wayland yet? Or is it going to work via xWayland as expected?
edit: Just tried it and it's still the same on Wayland.
WARP_ENABLE_WAYLAND=1 warp-terminal
works great for me.
I just copied the .desktop file from /usr/share/applications/dev.warp.Warp.desktop
to ~/.local/share/applications/dev.warp.Warp.desktop
and edited the command to include the env variable.
Also, FYI this bug was happening to me on Firefox 122 too.
WARP_ENABLE_WAYLAND=1 warp-terminal
works for my case (#4255) also. (Firefox 122, too)
hey folks, we just released an update (
v0.2024.02.20.08.01.stable_02
) to the Linux client (for x11 only) that should help resolve some of the login issues with Firefox.Please install the latest version and let us know if that helped.
New update seems to have fixed the issue for me, good job! Also opening other links (like the docs button) now which weren't before.
I am experiencing this issue on Fedora 39 with Firefox 122.0 using the latest RPM. Manually pasting https://app.warp.dev/signup/remote into Firefox fixed the issue for me.
@dannyneira @daprahamian I can confirm that the bug is fixed for me on v0.2024.02.20.08.01.stable_02
, if I launch Warp with WARP_ENABLE_WAYLAND=1 warp-terminal
.
I guess we can close off this bug if Warp can auto-detect Wayland (and therefore remove the need to manually set WARP_ENABLE_WAYLAND=1
)?
@dannyneira @daprahamian I can confirm that the bug is fixed for me on
v0.2024.02.20.08.01.stable_02
, if I launch Warp withWARP_ENABLE_WAYLAND=1 warp-terminal
.I guess we can close off this bug if Warp can auto-detect Wayland (and therefore remove the need to manually set
WARP_ENABLE_WAYLAND=1
)?
since that is part of an on-boarding process, I would say it's mandatory to either state it needs that env or remove the need for signup as most of linux distros are wayland by default these days and most of users would see this as broken app.
I simply changed my default to chrome and the issue went away.
Discord username (optional)
No response
Describe the bug
Upon launching Warp, the "Sign up" button is presented. Clicking on this once takes you to the second screen with another "Sign up" button and an "Auth Token" text field. However, clicking on button does nothing. There are no errors sent to stdout either. I also cannot find a sign-up link on the main website, so because of this I'm unable to use the terminal.
Package was installed from the AUR.
Machine is connected directly to the internet (no proxy)
Default browser is set (Firefox)
Opening links elsewhere works fine (eg using
xdg-open
from a terminal)OS: Arch Linux
DE/WM: Wayfire
stdout:
To reproduce
Expected behavior
Sign-up button should work
Screenshots
Operating system
Linux
Operating system and version
Arch Linux
Shell Version
No response
Current Warp version
0.2024.02.20.08.01.stable_01-1
Regression
No, this bug or issue has existed throughout my experience using Warp
Recent working Warp date
No response
Additional context
No response
Does this block you from using Warp daily?
Yes, this issue prevents me from using Warp daily.
Is this a Warp specific issue? (i.e. does it happen in Terminal, iTerm, Kitty, etc.)
Yes, this I confirmed this only happens in Warp, not other terminals.
Warp Internal (ignore): linear-label:b9d78064-c89e-4973-b153-5178a31ee54e
None