It seems this issue was reported 3 days ago: https://productforums.google.com/forum/#!topic/chrome/kQThshRB8Nw

The users said that desktop Chrome MaxOSX works just like on AmazonFireTablet, so the issue seems to be coming from Android Chrome.

I tried it in Desktop Chrome on MacOS and the https://www.google.com/searchbyimage/upload link worked for me.
Here's a video: https://photos.app.goo.gl/m9ESygTJRclztkn83.

Raising priority here given the circumstances described in user report and multiple Googlers reproducing.  I can't repro on my Pixel 2 XL on O MR1 FWIW.

We should have someone try to repro on dev (https://play.google.com/store/apps/details?id=com.chrome.dev&hl=en) to see if this reproduces in M64 as well or just M63 stable.  We should also have someone attach a bug report (to the internal bug).

I am able to repro consistently on Pixel 1 Android 8.1.0, Chrome 63.0.3239.111

issue 795813 seems similar. But it is being reproted on M62. We are trying and will update here if we can repro.

FWIW, the bug is *not* present on iOS w/ Chrome version 63.0.3239.73.

hongchichang@ is there any user feedback about this issue?

Also repros consistently on Pixel 1 Android 8.1.0, Chrome 64.0.3282.29

I can reproduce the issue consistently on my Pixel 1 XL Chrome 63.0.3239.111 on Android 8.1.0. 

Build number: Marlin-userdebug 8.1.0 OPM1.171019.012 4470837 dev-keys

 Issue 795833  has been merged into this issue.

I see this when the issue happens via remote Chrome debugging:

The FetchEvent for "https://www.google.com/searchbyimage/upload" resulted in a network error response: an object that was not a Response was passed to respondWith().
Promise resolved (async)
sw_xb @ serviceworker?pwa=search:71
(anonymous) @ serviceworker?pwa=search:70

(that was on Pixel 1 XL Chrome 63.0.3239.111 on Android 8.1)

I am able to repro this issue on M63 as well as M62. on Pixel / 8.0 and Samsung S6 / 5.1.1
It doesn't happen for images on any site first. It starts happening only after I do this,
1. Open a Tab and search for something like 'flowers'
2. Tap on 'Images' from the SRP
3. Longpress on the image and choose 'Search Google for this image'

Observed: 'This site cannot be reached'

After this it repros on images on other sites too.

Reports start coming in in 12/15 late afternoon. Here are some reports with system log:

https://listnr.corp.google.com/report/84811900345
https://listnr.corp.google.com/report/84811860837
https://listnr.corp.google.com/report/84810623240
https://listnr.corp.google.com/report/84810623240
https://listnr.corp.google.com/report/84809104329

Here are link to all play review & in-app feedback reprots:
https://listnr.corp.google.com/product/282/reports?searchText=search%20image&filter=0&dateRange=30&sources=8590027391,8590013633&versions=63.0.3239.111

All reports are on 63.0.3239.111 Can we bisect this issue? Please try to reproduce on 63.0.3239.107 and also 63.0.3239.83 if possible.

From c#13: "I am able to repro this issue on M63 as well as M62"

Did the search team enable experiments that could have caused this?  If we can repro on 62 but reports only started on 12/15 that's indicative of an external factor IMO.

cmasso@, in the Listnr link Robert sent, I think there's a version filter applied for M63; if I remove it I see other reports...

https://listnr.corp.google.com/report/84786796788

That's from M62 with identical circumstances on 13 Dec.

Another M62: https://listnr.corp.google.com/report/84804395467

There are 12 reports since 12/12 in 63.0.3239.84 and 63.0.3239.107 from in-app feedback and play review:
https://listnr.corp.google.com/product/282/issue/a11:69647b14:930853?collapseIssueChart=true&dateRange=30&sources=8590027391,8590013633&versions=63.0.3239.83,63.0.3239.107

Just had a chat with Robert and yes, the reports are from Dec 12th. We need to find an owner to look into this issue.

Not sure if Internals>Network is the right component here but adding Chris to take a look.

I think at this point the owner should be the search by image team given what we're seeing - it may be a Chrome bug, but if it's back to M62 then it's likely we should roll back whatever's causing this to start failing now.

Thoughts on removing RB here and tagging as ExternalDependency?

Unfortunately Chris is OOO

I haven't been able to repro the issue in M61 so far. But can consistently repro it in M62 and M63 on these two devices. I am trying to bisect further.

Also Note that I was not able to repro this issue in M63 on a Pixel 2XL / 8.0.0. So it looks like its not happening on all devices.

Does it reproduce on all OS versions?

So far I have been able to repro on 2 devices out of 3 which I tried.

..pressed send too soon.

I was able to repro on OS versions 8.0 and 5.1.1. But it didn't repro on another device with 8.0. 

We are also seeing this on iOS https://listnr.corp.google.com/product/5031434/issue/a06cc4:69647b14:5808900?collapseIssueChart=true&dateRange=30
and Windows
https://listnr.corp.google.com/report/84806943893
https://listnr.corp.google.com/report/84805881030

The search support team is not aware of this issue. They are escalating to search Eng now I am being told.

My bisect did not provide a code change CL. Its a version change CL. Then may be its a GWS experiment which is enabled Chrome M62 and above.


Good build: 61.0.3163.0
Bad build: 61.0.3164.0
Regression range: https://chromium.googlesource.com/chromium/src/+log/61.0.3163.0..62.0.3164.0?pretty=fuller&n=10000

Good commit: 488564
Bad commit: 488565
Suspect CL: https://chromium.googlesource.com/chromium/src/+/67d808464f515952ee0276976fb73f30ef209ca9

Bad build above should probably say 62.0.3164.0. 

We should check recent Finch changes as well actually... Just to be safe. Unsure if image team experiments track Chrome versions so closely. 

Oops typo. Yes the BAD Build: 62.0.3164.0

I think this has been identified as a bad service worker released on the search side. Details in b/70786900

Thanks to all who gathered data to help track this down!

Thanks!

 Issue 795616  has been merged into this issue.

Many thanks to everyone who helped us debug. The Search UI team has identified the cause of the issue and has released a temporary fix. We will switch back to b/70786900 for further updates.