Locking up for about 30 seconds when I try to enter a web url in the address bar

Description of the issue:

In the last week or so, I start brave (fresh Windows session) and it appears to start normally. But when I try to enter an address, the entire browser locks up. I cannot resize it, select new-tab, or pull down any menus. This state lasts for 15 to 30 seconds before it functions normally. This also happens when I have not used the session for a few hours and return to it.

Steps to Reproduce (add as many as necessary): 1. 2. 3.

Please see above.

Actual Result (gifs and screenshots are welcome!):

Not applicable.

Expected result:

Not applicable.

Reproduces how often:

Every time.

Operating System and Brave Version(See the About Brave page in the main menu):

Windows 11. Brave-Browser-Beta 1.70.107 Chromium: 128.0.6613.120 (Official Build) beta (64-bit)

Additional Information:

Having this exact same issue, noticed it this week.

Windows 11, version 1.70.117 Chromium: 129.0.6668.59 (Official Build) (64-bit)

I am seeing exactly this same issue also about the last two weeks. It makes the browser unusable. Also Windows 11. Version 1.70.119 Chromium: 129.0.6668.70 (Official Build) (64-bit)

Notably the problem resolves itself when I restart my machine but will return at a random time. I assumed it could be related to how long the browser takes to make recommendations in the address bar so I disabled every type of search I can. I currently have to type in the entire address by hand without any suggestions and still this problem occurs although it does take many hours longer before it starts up again.

1 Like

I have the same issue. No extensions. I have 2 profiles enabled.
Windows 11
Version 1.70.119 Chromium: 129.0.6668.70 (Official Build) (64-bit)

I have the same issue :frowning:

Sorry for the late reply here everyone.
Can you all please try launching a Guest profile (Menu --> More tools --> Guest profile), closing the original profile window, then typing into the address bar of the Guest window and tell me if the issue persists there as well?

It still is the case in a guest window.

Can you please confirm that this behavior doesn’t occur in other browsers? Additionally, I’d be curious to know if the behavior occurs in the Beta build of the browser as well — note that downloading/installing the Beta will not overwrite or interfere with your current installation.

I’ve had the same issue - Linux Debian, brave-stable 1.70.123 and 1.70.119.
Issue went away by downgrading to 1.69.168.

I have used chromium and librewold successfully in the meantime.

I have used the beta build for a few minutes, so far so good but I am not sure how reliable that test is, as brave-beta uses a fresh new profile.

I am not an expert. Here is the end of strace before the program locks up.

pipe2([430, 441], 0)                    = 0
fcntl(441, F_DUPFD_CLOEXEC, 0)          = 443
close(441)                              = 0
sendmsg(136, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\1\0\0\377\1\0\24\0\7\0\0\0STRING\0\0", iov_len=20}], msg_iovlen=1, msg_control=[{cmsg_len=20, cmsg_level=SOL_SOCKET, cmsg_type=SCM_RIGHTS, cmsg_data=[443]}], msg_controllen=20, msg_flags=0}, MSG_DONTWAIT|MSG_NOSIGNAL) = 20
close(443)                              = 0
sendmsg(136, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\1\0\0\0\0\0\f\0001\0\0\0", iov_len=12}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, MSG_DONTWAIT|MSG_NOSIGNAL) = 12
poll([{fd=136, events=POLLIN}], 1, -1)  = 1 ([{fd=136, revents=POLLIN}])
recvmsg(136, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="1\0\0\0\0\0\f\0v{\0\0\1\0\0\0\1\0\f\0001\0\0\0", iov_len=1656}, {iov_base="", iov_len=2440}], msg_iovlen=2, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_CMSG_CLOEXEC) = 24
recvmsg(136, {msg_namelen=0}, MSG_DONTWAIT|MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resursen tillfälligt otillgänglig)
read(430, 

The call to read never returns.

If I read correctly (and it is very possible I don’t!!) brave creates the two file descriptors of a pipe (430 read, 441 write). It duplicates the write pipe (443) and sets some flag (CLOEXEC). then closes the original descriptor (441), leaving only the duplicate. Then closes the duplicate too (443). Then attempts to read from the read end (430) where nothing happens, since all write ends were closed.

It looks like Brave wants to run a command and capture the output but changes its mind about running the command.

Original poster here. I am using the beta version (Version 1.71.104 Chromium: 129.0.6668.89 (Official Build) beta (64-bit))

This problem does not occur with Chrome Version 129.0.6668.90 (Official Build) (64-bit)

So far I have not been able to repro with the guest profile.