This is odd.  I reprod for me when I tried it at my home network (in incognito).  It didn't repro for me when I try it at work.  I wonder if this is some sort of proxy or network thing.

For now, kicking to the networking bug queue for them to investigate.  If it's not a networking issue, throw it back to me.

Able to reproduce the issue on reported chrome version 63.0.3239.132 and on the latest canary 66.0.3327.0 using Mac 10.13.1 and Ubuntu 14.04. 
Note: The issue is not seen on Windows .
As the issue is seen from M60(60.0.3072.0) considering it as non-regression and marking as Untriaged.

Thanks!

rsleevi / davidben: Since you've helped us with networking issues on Omnibox before -- send as Mark said in c#2, send back if it's on us.

The networking team has a triage rotation that watches this component. Don't assign bugs to individual folks like this or they'll just slip through the cracks. The current triager will get to this.

Although, in this case, the triager would ask:

Can you please attach a NetLog per these instructions?
https://dev.chromium.org/for-testers/providing-network-details

Oh, I missed that the bug is in the UI losing focus. Yeah, we can't help you with UI problems. You're on your own there.

davidben@, well the core of the bug is that the navigation stops without an error or indication to the user.  The loss of focus is a side effect.

netlog attached

Deleted: chrome-net-export-log.json 149 KB

chrome-net-export-log.json 149 KB View Download

Ah, I see. Sorry, I missed that. Yeah, actually, what does the address bar losing focus have to do with anything? It seems the address bar tends to lose focus as soon as one presses enter.

The NetLog says that the request hit ERR_ABORTED, which usually means some layer outside the net stack decided to abort the request for some reason. Layers above don't participate in NetLog, so I don't know if I can tell anything beyond that. :-/ I'm also not able to reproduce this on my machine, Ubuntu or macOS.

Interestingly, it got aborted quite quickly, before we went to the network or anything.

> It seems the address bar tends to lose focus as soon as one presses enter.

Er, by that I meant that losing focus seems to be expected here. Or am I still misunderstanding the original report?

mmenke points out it's probably coming from this codepath here:
https://cs.chromium.org/chromium/src/net/url_request/url_request.cc?rcl=48d11bca7c8fa940fdda1498e6dca7ff7088ad19&l=702

Which, yeah, just means someone decided to cancel us for whatever reason. If you can repro, you could maybe set a breakpoint or print the stacktrace at that point to see what's doing it. (I can't repro, so I can't try it myself.)

I was a bit lazy and simply but a breakpoint as URLRequest::DoCancel().  When I do a navigation to the address in question, it gets hit twice, with the two different stack traces below.  Let me know if there are any particular values you want me to inspect at this point.

For context, I'm running this in a fresh profile, using checkout fb56b10e5f89627c69e4ba96473e7044beb83604 (from mid-December), on Linux.

(gdb) where
#0  0x00007ffff5819bf3 in net::URLRequest::DoCancel(int, net::SSLInfo const&) (this=0x3866888ec020, error=-3, ssl_info=...)
    at ../../net/url_request/url_request.cc:700
#1  0x00007ffff581298b in net::URLRequest::Cancel() (this=0x3866888ec020)
    at ../../net/url_request/url_request.cc:683
#2  0x00007ffff5812c49 in net::URLRequest::~URLRequest() (this=0x3866888ec020)
    at ../../net/url_request/url_request.cc:182
#3  0x00007ffff5813249 in net::URLRequest::~URLRequest() (this=0x3866888ec020)
    at ../../net/url_request/url_request.cc:173
#4  0x00007ffff1f24626 in content::ResourceLoader::~ResourceLoader() (this=0x386688a22748, __ptr=0x3866888ec020)
    at ../../buildtools/third_party/libc++/trunk/include/memory:2233
#5  0x00007ffff1f24626 in content::ResourceLoader::~ResourceLoader() (this=0x386688a22748, __p=0x0)
    at ../../buildtools/third_party/libc++/trunk/include/memory:2546
#6  0x00007ffff1f24626 in content::ResourceLoader::~ResourceLoader() (this=0x386688a22748) at ../../buildtools/third_party/libc++/trunk/include/memory:2500
#7  0x00007ffff1f24626 in content::ResourceLoader::~ResourceLoader() (this=0x386688a22720) at ../../content/browser/loader/resource_loader.cc:243
#8  0x00007ffff1f246f9 in content::ResourceLoader::~ResourceLoader() (this=0x386688a22720) at ../../content/browser/loader/resource_loader.cc:235
#9  0x00007ffff1893954 in std::__1::pair<int const, std::__1::unique_ptr<content::CacheStorageBlobToDiskCache, std::__1::default_delete<content::CacheStorageBlo-------Typ---Type <retur---Type <return>---Type <return>---Type <return> to continue---Type <retur---T---Type <return> to continue, or q <return> to quit---
bToDiskCache> > >::~pair() (this=0x3866879d39e8, __ptr=0x386688a22720)
    at ../../buildtools/third_party/libc++/trunk/include/memory:2233
#10 0x00007ffff1893954 in std::__1::pair<int const, std::__1::unique_ptr<content::CacheStorageBlobToDiskCache, std::__1::default_delete<content::CacheStorageBlobToDiskCache> > >::~pair() (this=0x3866879d39e8, __p=0x0)
    at ../../buildtools/third_party/libc++/trunk/include/memory:2546
#11 0x00007ffff1893954 in std::__1::pair<int const, std::__1::unique_ptr<content::CacheStorageBlobToDiskCache, std::__1::default_delete<content::CacheStorageBlobToDiskCache> > >::~pair() (this=0x3866879d39e8)
    at ../../buildtools/third_party/libc++/trunk/include/memory:2500
#12 0x00007ffff1893954 in std::__1::pair<int const, std::__1::unique_ptr<content::CacheStorageBlobToDiskCache, std::__1::default_delete<content::CacheStorageBlobToDiskCache> > >::~pair() (this=0x3866879d39e0)
    at ../../buildtools/third_party/libc++/trunk/include/utility:312
#13 0x00007ffff1f15644 in std::__1::__tree<std::__1::__value_type<content::GlobalRequestID, std::__1::unique_ptr<content::ResourceLoader, std::__1::default_delete<content::ResourceLoader> > >, std::__1::__map_value_compare<content::GlobalRequestID, std::__1::__value_type<content::GlobalRequestID, std::__1::unique_ptr<content::ResourceLoader, std::__1::default_delete<content::ResourceLoader> > >, std::__1::less<content::GlobalRequestID>, true>, std::__1::allocator<std::__1::__value_type<content::GlobalRequestID, std::__1::unique_ptr<content::ResourceLoader, std::__1::default_delete<content::ResourceLoader> > > > >::erase(std::__1::__tree_const_iterator<---Ty---Type <return> to continue, or q ---Type <return> to continue, or q <return> to qui---Type <return> to continue, or q ---Type <return> to continue, ---Type <return---Type <r---Type <return> to continue, ---Type <r---Ty---Ty---Ty---Ty---Ty---Ty---Ty---Type <return> to continue, or q <return> to quit---
nique_ptr<content::ResourceLoader, std::__1::default_delete<content::ResourceLoader> > >, std::__1::__tree_node<std::__1::__value_type<content::GlobalRequestID, std::__1::unique_ptr<content::ResourceLoader, std::__1::default_delete<content::ResourceLoader> > >, void*>*, long>) (__p=0x3866879d39e0)
    at ../../buildtools/third_party/libc++/trunk/include/memory:1687
#14 0x00007ffff1f15644 in std::__1::__tree<std::__1::__value_type<content::GlobalRequestID, std::__1::unique_ptr<content::ResourceLoader, std::__1::default_delete<content::ResourceLoader> > >, std::__1::__map_value_compare<content::GlobalRequestID, std::__1::__value_type<content::GlobalRequestID, std::__1::unique_ptr<content::ResourceLoader, std::__1::default_delete<content::ResourceLoader> > >, std::__1::less<content::GlobalRequestID>, true>, std::__1::allocator<std::__1::__value_type<content::GlobalRequestID, std::__1::unique_ptr<content::ResourceLoader, std::__1::default_delete<content::ResourceLoader> > > > >::erase(std::__1::__tree_const_iterator<std::__1::__value_type<content::GlobalRequestID, std::__1::unique_ptr<content::ResourceLoader, std::__1::default_delete<content::ResourceLoader> > >, std::__1::__tree_node<std::__1::__value_type<content::GlobalRequestID, std::__1::unique_ptr<content::ResourceLoader, std::__1::default_delete<content::ResourceLoader> > >, void*>*, long>) (__a=..., __p=0x3866879d39e0)
    at ../../buildtools/third_party/libc++/trunk/include/memory:1550


(gdb) where
#0  0x00007ffff5819bf3 in net::URLRequest::DoCancel(int, net::SSLInfo const&) (this=0x38668633d820, error=-3, ssl_info=...)
    at ../../net/url_request/url_request.cc:700
#1  0x00007ffff581298b in net::URLRequest::Cancel() (this=0x38668633d820)
    at ../../net/url_request/url_request.cc:683
#2  0x00007ffff5812c49 in net::URLRequest::~URLRequest() (this=0x38668633d820)
    at ../../net/url_request/url_request.cc:182
#3  0x00007ffff5813249 in net::URLRequest::~URLRequest() (this=0x38668633d820)
    at ../../net/url_request/url_request.cc:173
#4  0x00007ffff5805ad5 in net::URLFetcherCore::ReleaseRequest() (this=0x3866892cc960, __ptr=0x38668633d820)
    at ../../buildtools/third_party/libc++/trunk/include/memory:2233
#5  0x00007ffff5805ad5 in net::URLFetcherCore::ReleaseRequest() (this=0x3866892cc960, __p=0x0) at ../../buildtools/third_party/libc++/trunk/include/memory:2546
#6  0x00007ffff5805ad5 in net::URLFetcherCore::ReleaseRequest() (this=0x3866892cc820) at ../../net/url_request/url_fetcher_core.cc:824
#7  0x00007ffff58053f0 in net::URLFetcherCore::OnReadCompleted(net::URLRequest*, int) (this=0x3866892cc820, request=0x38668633d820, bytes_read=0)
    at ../../net/url_request/url_fetcher_core.cc:484
#8  0x00007ffff5804d24 in net::URLFetcherCore::ReadResponse() (this=0x3866892cc820) at ../../net/url_request/url_fetcher_core.cc:901
#9  0x00007ffff5804c3f in net::URLFetcherCore::OnResponseStarted(net::URLRequest*, int) (this=0x3866892cc820, request=0x38668633d820, net_error=0)
---Type <return> to continue, or q <return> to quit---
    at ../../net/url_request/url_fetcher_core.cc:437
#10 0x00007ffff581a93c in net::URLRequest::NotifyResponseStarted(net::URLRequestStatus const&) (this=0x38668633d820, status=...)
    at ../../net/url_request/url_request.cc:837
#11 0x00007ffff58527dc in net::URLRequestJob::NotifyHeadersComplete() (this=0x3866868d9fa0) at ../../net/url_request/url_request_job.cc:469
#12 0x00007ffff58447cc in net::URLRequestHttpJob::NotifyHeadersComplete() (this=0x3866868d9fa0) at ../../net/url_request/url_request_http_job.cc:451
#13 0x00007ffff584801a in net::URLRequestHttpJob::SaveCookiesAndNotifyHeadersComplete(int) (this=0x3866868d9fa0, result=0)
    at ../../net/url_request/url_request_http_job.cc:727
#14 0x00007ffff5846fe5 in net::URLRequestHttpJob::OnStartCompleted(int) (this=0x3866868d9fa0, result=0) at ../../net/url_request/url_request_http_job.cc:934
#15 0x00007ffff4f2739f in base::internal::FunctorTraits<void (net::ClientSocketHandle::*)(int), void>::Invoke<net::ClientSocketHandle*, int>(void (net::ClientSocketHandle::*)(int), net::ClientSocketHandle*&&, int&&) (method=
    (void (net::ClientSocketHandle::*)(net::ClientSocketHandle * const, int)) 0x7ffff5846830 <net::URLRequestHttpJob::OnStartCompleted(int)>, receiver_ptr=<unknown type in /usr/local/google/home/mpearson/chromium/src/out/Default/./libnet.so, CU 0x0, DIE 0x16f4f>, args=<unknown type in /usr/local/google/home/mpearson/chromium/src/out/Default/./libnet.so, CU 0x0, DIE 0x16f5b>)
    at ../../base/bind_internal.h:211
#16 0x00007ffff4f272ff in base::internal::InvokeHelper<false, void>::MakeItSo<vo---Type <return> to continue, or --------Type---Type---Type <re---Type---------Ty---Ty---Ty-----Type <return> to continue, or q <return> to quit---
id (net::ClientSocketHandle::* const&)(int), net::ClientSocketHandle*, int>(void (net::ClientSocketHandle::* const&)(int), net::ClientSocketHandle*&&, int&&) (functor=
    @0x386688f91f90: (void (net::ClientSocketHandle::*)(net::ClientSocketHandle * const, int)) 0x7ffff5846830 <net::URLRequestHttpJob::OnStartCompleted(int)>, args=<unknown type in /usr/local/google/home/mpearson/chromium/src/out/Default/./libnet.so, CU 0x0, DIE 0x16ebb>, args=<unknown type in /usr/local/google/home/mpearson/chromium/src/out/Default/./libnet.so, CU 0x0, DIE 0x16ec8>)
    at ../../base/bind_internal.h:294
#17 0x00007ffff4f27295 in base::internal::Invoker<base::internal::BindState<void (net::ClientSocketHandle::*)(int), base::internal::UnretainedWrapper<net::ClientSocketHandle> >, void (int)>::RunImpl<void (net::ClientSocketHandle::* const&)(int), std::__1::tuple<base::internal::UnretainedWrapper<net::ClientSocketHandle> > const&, 0ul>(void (net::ClientSocketHandle::* const&)(int), std::__1::tuple<base::internal::UnretainedWrapper<net::ClientSocketHandle> > const&, std::__1::integer_sequence<unsigned long, 0ul>, int&&) (functor=
    @0x386688f91f90: (void (net::ClientSocketHandle::*)(net::ClientSocketHandle * const, int)) 0x7ffff5846830 <net::URLRequestHttpJob::OnStartCompleted(int)>, bound=..., unbound_args=<unknown type in /usr/local/google/home/mpearson/chromium/src/out/Default/./libnet.so, CU 0x0, DIE 0x12e63>)
    at ../../base/bind_internal.h:368
#18 0x00007ffff4f271cb in base::internal::Invoker<base::internal::BindState<void (net::ClientSocketHandle::*)(int), base::internal::UnretainedWrapper<net::Clien---Type <return> to continue, or q <return> to quit---q

Hrm, okay, that was less enlightening than I'd hoped. :-(

The ResourceLoader one appears to just be destructing the object, so that's probably not it. But it is probably the URLRequest we want... navigation doesn't go through URLFetcher, so I'm guessing that's the omnibox or sync or whoever pinging something.

Maybe it's being cancelled at a different place? +mmenke, have you debugged an errant URLRequest cancel before?

Oh, or maybe that is the right spot and some parts of the stack just destroy their ResourceLoaders to cancel these days. I haven't seen the //content loader stack for years. Though it appears to have been off a PostTask, so that's unhelpful. :-/

I have.  It generally involves breakpoints and backtracing what called cancel.

If it's over the Mojo interface, the only way to cancel is to destroy it.

I'm a bit confused on what the problem is here, and why this was declared a network bug.  The network stack doesn't use any APIs to set the focus.

Clarifying summary.

Problem is in "Network", maybe because no one know why its failing. And
maybe it's more about validation of URL before run then UI.

Tested different subdomains too (wvw.3t; 3w.3t and etc), everything works
except www.3t.lt

Thank you guys for trying.

Have a nice day!

mmenke@, who is a good person to investigate this?  I don't know anything about ResourceLoaders, the content loader stack, or anything.  This definitely isn't part of the omnibox.  (We don't cancel requests.)

I can't reproduce.

I don't quite understand the problem description. Are we showing an error page? Is it just a white page? Or something else.

The NetLog in comment #7 doesn't show how/why the request is being cancelled.

The callstacks in comment #11 are exactly what I would want to see too!

The first one is probably the interesting one. Can you show us what is beyond frame #18? (I don't know enough about the ResourceLoader stack to immediately rule that out as benign. I would start by trying to blame an unexpected destruction of that ResourceLoader cancelling the request).

Some other general debugging stuff:

 * Does this only happen when typing address in omnibox?
   - What if instead you create a bookmark and click that?
   - Or load an HTML page and click a link.

 * From the NetLog I don't see any suspicious looking extensions. But also worht trying to disable all extensions.

 * The fact that this only happens from home is interesting. Is the only difference the network you are on?

My guess is a navigation bug. The navigation stack is the one driving the resource loader if this is coming from the omnibox.

Found fix MAYBE:
 1) Enter www.3t.lt, wait for some time and then press enter.
 2) OR first time press enter go back to address bar, wait some time and then press enter. Then it works.

Okay, per c#19, I'm clearing this off the Omnibox triage list... Feel free to re-add UI>Browser>Omnibox if it seems to be coming from there.

+pasko, are prerenders still firing from the omnibox? Comment #20 sounds suspiciously like the sort of trigger prerender would cause. I don't see evidence of it in NetLog, but I'm not sure if the new chrome://net-export path still samples prerender (mmenke?).

For the record, I cannot reproduce in either place I reproduced this issue before.  It's possible my browser updated / restarted in the meantime.

vamshi.kommuri@, you managed to reproduce it.  Does it still reproduce for you?

re #22: nostate-prefetch could fire. It now should be enabled on 100% of clients, no need to tweak experiments for reproducing

.. and prerender is disabled on desktop

Could anyone that can reproduce this capture a chrome://tracing trace with the "navigation" category enabled? It will tell us what navigation thinks is happening under the hood and if this is being cancelled by a NavigationThrottle.

It already works. 

#27 To verify, you are no longer experiencing problems in the latest version of Chrome?

Closing as obsolete.  Please tell me if you can still reproduce this issue.