The underlying code should return the actual origin in use.  Are you saying you can reproduce a case where it doesn't in practice?  If so can you reproduce on desktop as well or only Android?

(Also, apparently bug 726721 is so restricted even I can't see it.)

I can repro - on my phone the search engine is listed as google.com, whereas my search engine's origin is currently www.google.com.au. I guess we strip the www. for brevity? The .au is also not shown though.

Can you repro on desktop?  I'm wondering whether this is a bug in the underlying data model or the Android UI.

On desktop I see www.google.com.au with some number of underscores appended (maybe three, so "www.google.com.au___").

BTW I'd guess it is something in the Android UI. I've recently made changes there and could probably fix it if this is simple, but before doing that wanted to check what we want. Would everyone be happy with just putting in the current DSE CCTLD?

Woah, underscores appended?  How new is this profile?  If it's not "very old", that's surprising and alarming from a sync angle.

I think you should be showing the current search engine keyword in the UI, not the CCTLD.  That's what desktop is doing, and we had a long discussion about the distinction between the two back when deciding to support custom search engines more aggressively on Android.

Oh ... lol ... that profile was indeed 'very old'.

I've just tried on a new profile and I see 'google.com', despite my searches going to www.google.com.au. From the UI 'google.com' is the search engine keyword, is that right? What does 'keyword' mean in this context? It looks a lot like an origin.

The keyword should be auto(re)generated based on the host name unless the user manually overrides it.  Thus for non-manually-touched keywords, it should basically be eTLD + 1.  For manually-touched keywords, it will be what the user sets it to be.

For google.com, the underlying hostname varies, and when it changes, that should also cause the keyword to be modified.  Otherwise, typing "google.com.au" in your address bar and hitting tab won't trigger the Google search engine.

That said, if for some reason searchdomaincheck returned google.com, then from Chrome's perspective both the keyword and the underlying request would be google.com, and if the server then redirected you, you'd see searches wind up somewhere else.  You could check that by manually loading https://www.google.com/searchdomaincheck?format=domain&type=chrome and seeing what it says; and by looking at a network trace for an omnibox search and seeing what actually happens under the hood.

OK ... wow, i didn't realise this was so deep.

For my information - the keyword is something that the user can type in the omnibox to force a particular search engine. Is that right?

Turns out the profile I tried in #7 wasn't new enough. I just tried a brand new profile and now I'm seeing google.com.au as the keyword.

I also just wiped my data on Chrome Canary and now it is also saying google.com.au.

This is really surprising though ... I've been wiping my data on Chrome Canary a lot. Did this change very recently?

No, nothing should have been touched here.

A restart or a network change should both trigger a searchdomaincheck recheck, but if you haven't moved the computer from a google.com area to a google.com.au area, there's no reason it should have been on google.com previously.

OK .... strange.

Martin - are you satisfied? Seems like the keyword is whats being shown, not the origin, but it is updated to match the origin. Maybe we can close this as WontFix.

Thanks for the background. However, the following behavior is still reliably reproducible for me:

1. Reinstall Canary on Android.
2. Check search engines - Google is selected, it says "google.de".
3. Change to a different engine.
4. Change back to Google - it immediately turns to "google.com".
5. Try searching something - it loads "google.de".
6. Visit "/searchdomaincheck" - it says "google.de".
7. Click on "Location is allowed" - it shows the content setting for "www.google.de"

So the keyword is definitely incorrect. And with further testing:

8. Searching for "google.com foo" performs a search for "google.com foo" in the DSE
9. Searching for "google.de foo" performs a search for "google.com foo" in the DSE

So I'm not sure what the keywords are even for? I mean, I know how it works on Desktop, but I don't see how to use them (or change them) on Android.

Custom keywords are not yet supported on Android -- that's still to come.  For now, showing the keyword in the UI will basically always be equivalent to the eTLD+1 (modulo bugs), and it will do what we want later when keyword triggering is supported on Android.

Regarding your reproducible behavior, that certainly sounds buggy to me.  Can you reproduce something similar on desktop?

Yes, just reproduced it on Mac (on a new Canary profile).

Resummarizing to try and capture the current bug report.

I would expect desktop's behavior to fix itself on a restart.  (But then maybe a switch-away, switch-back resets it again?)

This seems P3 to me but maybe it affects more cases than just switch-away, switch-back.

I would like to increase the priority back. The reason I asked benwells@ to look into this was that the menu item

Google
google.com
Location is allowed

might make it seem like location would perhaps not be allowed when I visit google.de (which is my primary TLD). Of course,

Google
google.de
Location is allowed

is still not precise, because, vice versa, location would be allowed on google.com if I visited it directly. But it's a lower chance, because that's not where I'm going directly from Omnibox.

And while I do understand that we're talking about keywords, not origins here, I want to minimize confusion in the default, majority case.