Brave-browser: When typing in url bar in new tab, first few characters of url get deleted
Description
When trying to navigate to a url in a new tab, midway through typing the url, the whole address will get selected automatically, deleting the first few characters as the user continues typing. The auto select bug only occurs on the first time trying to type a url in a new tab.
Steps to Reproduce
Open a new tab, start typing a URL. Midway through, the auto complete will highlight the whole input, and thus interrupt the correct address
Actual result:
I begin typing brave.com. After I type b, the url bar auto selects the whole address which interrupts the full url.
Expected result:
Does not auto select the whole text midway through typing.
Reproduces how often:
Happens very often. Almost every new tab after switching from existing.
Brave version (brave://version info)
Brave | 0.61.51 Chromium: 73.0.3683.75聽(Official Build)聽(64-bit)
OS | Mac OS X
Reproducible on current release:
- Does it reproduce on brave-browser dev/beta builds?
N/A
Website problems only:
- Does the issue resolve itself when disabling Brave Shields?
No - Is the issue reproducible on the latest version of Chrome?
No.
Additional Information
Appears to be very similar to these old tickets:
(https://github.com/brave/browser-laptop/issues/2812)
(https://github.com/brave/browser-laptop/issues/2197)
andsnw
All 49 comments
Seconding this, I've been having this exact same issue for the last couple days as well!
samuelfine
on 18 Mar 2019
cc: @rebron
bsclifton
on 18 Mar 2019
seeing this happen when you start typing before the new tab page image is loaded. Its deleting the characters typed before the image load started
srirambv
on 19 Mar 2019
I'm also seeing this. As mentioned by srirambv, I believe it is the new tab page loading that clears out the address bar.
As a workaround, installing an extension to change the new tab page seems to work.
ryan3E0
on 19 Mar 2019
cc: @cezaraugusto
bsclifton
on 19 Mar 2019
For me, this appears to occur only when the tab immediately to the left of the new tab has a page already loaded. If creating a new tab from a blank new tab page, I don't experience this issue.
warwickmm
on 20 Mar 2019
This needs to be fixed very quickly, it is very irritating. I have to wait for a few seconds everytime after opening new tab.
TontyTon
on 20 Mar 2019
+1 from @servetcoskun via https://github.com/brave/brave-browser/issues/3835
bsclifton
on 21 Mar 2019
@bsclifton sorry about duplicate, I searched for similar issues and was not able to find this one, my bad! @andsnw +1 for that very accurate and descriptive explanation, much better than mine :)
servetcoskun
on 21 Mar 2019
@servetcoskun no worries- that's why I'm here 馃槃 Help guide folks to the right place, make sure we at Brave know what the important issues are
bsclifton
on 22 Mar 2019
Sorry, but is there any news on this? This is detrimental to UX by the minute.
servetcoskun
on 28 Mar 2019
Also cancels custom search engine searches on address bar
ravihlb
on 30 Mar 2019
@ravihlb can confirm it does the same for me. Atleast it is contained to dev version :)
servetcoskun
on 30 Mar 2019
I just realized that an extension that modifies the new tab page is a simple and very functional workaround.
Using New Tab about:blank but any other extension that modifies it should work, I guess.
ravihlb
on 31 Mar 2019
+1 community:
https://community.brave.com/t/problem-in-the-search-bar-with-the-most-recent-update/51374/2
Imgur post: https://imgur.com/a/elyeU01
Gif file: https://i.imgur.com/hYQNvzB.gifv
MacOS Mojave 10.14.3, Brave Version 0.61.52 Chromium: 73.0.3683.86 (Official Build) (64-bit)
Brave-Matt
on 1 Apr 2019
Priority P1 please!!
This is very annoying
WorldLanguages
on 2 Apr 2019
+1 Same issue. Came here for this exact problem encountered recently but had enough today.
matambanadzo
on 5 Apr 2019
Three +1's from Community (three different users in thread):
https://community.brave.com/t/slowness-with-new-tab/48566
Brave-Matt
on 6 Apr 2019
excited to see this fixed. :) :) thanks so much!
amark
on 6 Apr 2019
+1 from Community https://community.brave.com/t/address-bar-searches-getting-automatically-highlighted-at-slight-pause/52380?u=eljuno
eljuno
on 7 Apr 2019
ok happy to announce we moved this bug to p1 and it's being actively working on.
after investigation this is not related to webui rendering resources, since loading a white page (raw HTML) still reproduce the bug.
worth noting that ntp webui is shared across tabs so having one instance of ntp open doesn't make the bug reproducible. OP makes it clear in the screenshot.
seems that we have some calls in the back-end that are making this delay somehow. the workaround of adding an extension to replace ntp works because chromium override the page with the extension, so the call never happens.
steps to reproduce (fast):
- open Brave with a clear profile
- while in welcome page, use the shortcut (cmd+T on mac) to open a new tab
- start typing
cezaraugusto
on 8 Apr 2019
+1 from #4055 (Typing Too Fast Too Soon In Location Bar Problem)
cndouglas
on 9 Apr 2019
I'm able to reproduce this 100% of times in a dev environment (via npm start) but not using binary builds, neither on beta, dev, and nightly channels (prod environment).
if you are still facing this issue and you have not shared whether you are using a production version, please let me know. as far I can tell this isn't an issue anymore in newer builds. I'm keep an eye on this issue
cezaraugusto
on 9 Apr 2019
I experienced this problem several times yesterday. Nightly (0.65.x) production build (downloaded DMG from https://github.com/brave/brave-browser/releases) on macOS 10.14.4.
cndouglas
on 9 Apr 2019
@cndouglas are you able to reproduce it consistently somehow? just opening a new tab and typing fast doesn't repro to me in production.
cezaraugusto
on 9 Apr 2019
For me, this appears to occur only when the tab immediately to the left of the new tab has a page already loaded. If creating a new tab from a blank new tab page, I don't experience this issue.
warwickmm
on 9 Apr 2019
@cezaraugusto For me, it is nearly 100% reproducible if I type really fast.
- Press Cmd+T
- Start typing
brave - The
bis dropped.
Full version info:
Brave | 0.65.28 Chromium: 74.0.3729.61聽(Official Build)nightly聽(64-bit)
Revision | 5df2c8936783bd7575987e45d72a92fcf528496b-refs/branch-heads/3729@{#645}
OS | Mac OS X
@warwickmm What version of Brave and operating system are you using?
cndouglas
on 9 Apr 2019
I can reproduce this 100% of the time on Windows 7 (via RDP) with Brave 0.62.50.
I cannot reproduce this on Arch Linux (5.0.4 kernel) with Brave 0.62.50.
warwickmm
on 10 Apr 2019
Still happening to me after update the other day (Version 0.62.51 Chromium: 73.0.3683.103 (Official Build) (64-bit)). On a mac.
AdamGerthel
on 10 Apr 2019
In fact, the text is not "erased" : its state becomes "selected", so if you continue typing it will erase what you have typed before.
It seems to me that the text become "selected" when the background image has finished to be downloaded and is displayed.
I've got a slow internet connection and a slow computer.
Version 0.62.51 Chromium: 73.0.3683.103 (Build officiel) (64 bits) - Windows 10
MalikDE
on 10 Apr 2019
@MalikDE Yes, you are right this is exactly I observed.
Reproducing on
Brave | 0.62.51 Chromium: 73.0.3683.103聽(Official Build)聽(64-bit)
-- | --
OS | Windows聽10 OS Build 17763.437
TontyTon
on 10 Apr 2019
+1
Brave | 0.64.40 Chromium: 74.0.3729.61聽(Official Build)聽dev聽(64-bit)
-- | --
Revision | 5df2c8936783bd7575987e45d72a92fcf528496b-refs/branch-heads/3729@{#645}
OS | Windows聽10 OS Build 17134.648
lukemulks
on 10 Apr 2019
+1 from #4060 (Omnibar query gets selected after opening a new tab) by @dodas
cndouglas
on 11 Apr 2019
I'm not sure if this should be a new bug, but it seems similar enough to me.
I get the issue as directly described as above, but it also happens if I start typing while the browser is still white and loading, it then loads, showing typed text, but then the text is selected and typed over once the new tab loads.
Modelmat
on 11 Apr 2019
seems that we have some calls in the back-end that are making this delay somehow. the workaround of adding an extension to replace ntp works because chromium override the page with the extension, so the call never happens.
Is it okay to link the workaround here for folks coming here for a quick fix? :-)
Uristocles
on 11 Apr 2019
@Uristocles That extension seems to have fixed the problem for me. Thanks!
cndouglas
on 11 Apr 2019
This is an upstream bug, fixed here.
omyno
on 17 Apr 2019
Yep but upstream didn't port the fix to Chromium 74, so we did that. It'll be available in our 0.63.x which is Chromium 74 based.
bbondy
on 17 Apr 2019
Issue persists: Version 0.64.56 Chromium: 74.0.3729.75 (Official Build) dev (64-bit), are people not having this issue since its closed? If yes, please consider reopening the issue.
servetcoskun
on 22 Apr 2019
Verification passed on
Brave | 0.63.46 Chromium: 74.0.3729.91 (Official Build) (64-bit)
-- | --
Revision | 03844ed83e02b8add3f4b9cb859a7108d55b2e4d-refs/branch-heads/3729@{#860}
OS | Linux
- Verified opening a new and quickly typing in URL bar doesn't lose any chars
- Verified page image load doesn't affect typing of char in URL bar
Verification passed on
Brave | 0.63.46 Chromium: 74.0.3729.91聽(Official Build)聽(64-bit)
-- | --
Revision | 03844ed83e02b8add3f4b9cb859a7108d55b2e4d-refs/branch-heads/3729@{#860}
OS | Windows聽10 OS Build 17134.523
- Verified opening a new and quickly typing in URL bar doesn't lose any chars
- Verified page image load doesn't affect typing of char in URL bar
Verification PASSED on macOS 10.14.4 x64 using the following build:
Brave | 0.63.46 Chromium: 74.0.3729.91聽(Official Build)聽(64-bit)
-- | --
Revision | 03844ed83e02b8add3f4b9cb859a7108d55b2e4d-refs/branch-heads/3729@{#860}
OS | Mac OS X
- Verified opening a new and quickly typing in URL bar doesn't lose any chars
- Verified page image load doesn't affect typing of char in URL bar
srirambv
on 22 Apr 2019
Issue persists: Version 0.64.56 Chromium: 74.0.3729.75 (Official Build) dev (64-bit), are people not having this issue since its closed? If yes, please consider reopening the issue.
@servetcoskun the fix landed after 0.64.56 CR: 74.0.3729.75. Can you recheck once you get another update? Should be fixed in that version 馃憤
kjozwiak
on 22 Apr 2019
Having this very issue. Extremely annoying. Any fixes yet?
hawadjie
on 23 Apr 2019
You can download an RC for 0.63.x from Github or wait for the release coming very soon.
bbondy
on 23 Apr 2019
Having this issue as well. Very frustrating. Surprised to see this issue open for so long.
jayneyer
on 25 Apr 2019
Not sure why this issue was closed, still is persisting.
jayneyer
on 25 Apr 2019
@jayneyer It's apparently been fixed already, just not released. See https://github.com/brave/brave-browser/issues/3756#issuecomment-485851584
AdamGerthel
on 25 Apr 2019
The fix has been released now, if I'm not mistaken
FWDekker
on 25 Apr 2019
As @FWDekker shared, fix has been released with 0.63! 馃槃 Please grab a copy and let us know if this still happens
bsclifton
on 25 Apr 2019
Issue persists: Version 0.64.56 Chromium: 74.0.3729.75 (Official Build) dev (64-bit), are people not having this issue since its closed? If yes, please consider reopening the issue.
@servetcoskun the fix landed after
0.64.56 CR: 74.0.3729.75. Can you recheck once you get another update? Should be fixed in that version 馃憤
With Version 0.65.78 Chromium: 74.0.3729.108 (Official Build) dev (64-bit), I do not have the problem anymore. Good job guys.
servetcoskun
on 2 May 2019
Related issues
nomaed
路
63Comments
bsclifton
路
128Comments
Brave-Matt
路
85Comments
kenthunt
路
70Comments
LaurenWags
路
47Comments
Most helpful comment
This needs to be fixed very quickly, it is very irritating. I have to wait for a few seconds everytime after opening new tab.