Tested this issue on on Linux Ubuntu-14.04 using chrome stable #60.0.3112.90 & canary #62.0.3184.0 and and unable to reproduce the issue.
Followed below Steps: 

1)Changed google-chrome as the default browser using the button at the bottom of chrome's Settings page -> Exit 
2.Now in a terminal typed "xdg-open http://www.example.com" -> Observed tab containing www.example.com

jim.avera@ Could you please find the attachment and confirm if anything is missed in triaging the issue.Please recheck this issue by creating a new profile under chrome://settings with no apps or extensions in your browser.
Please update the thread if issue still persists

Thanks..!!

Deleted: 754790.ogv 1.2 MB

	754790.ogv 1.2 MB View Download

My mistake - the bad $HOME/.local/share/applications/google-chrome.desktop file
is not created when google-chrome is made the default browser, but when the chrome icon in the Ubuntu Launcher is locked with rightclick->Lock to Launcher.

Furthermore, this now only seems to happen when running with --user-data-dir=/somewhere/nonstandard, but I don't think that was always the case.  Other users have had this problem, see https://askubuntu.com/questions/499200/xdg-open-opens-chrome-but-does-not-load-the-url

In my case, I just just noticed that the modtime of the bad .desktop file is many months old, created with earlier versions of google-chrome and Ubuntu.
Most likely there was a bug somewhere which has since been fixed.

I apologize for the incorrect bug report!

If anyone is interested, here is how to reproduce the problem today (with google-chrome 60.0.3112.90 and Ubuntu 17.04):

1. Ensure that chrome is not running.
   Remove any chrome icons from the Ubuntu launcher (rightclick->Unlock)

2. rm -rf /tmp/testud; mkdir /tmp/testud
   google-chrome --user-data-dir=/tmp/testud
   > Click OK to the initial pop-up

3. Right-click the chrome icon in the launcher->Lock to Launcher

4. Exit chrome

5. xdg-open http://www.example.com  # does not work

Note: The created $HOME/.local/share/applications/google-chrome.desktop
file contains 
   Exec=/opt/google/chrome/chrome --user-data-dir=/tmp/testud
so somehow the --user-data-dir arg is getting passed to the code which creates the file.

I used loggedfs to determine that the .desktop file is created by Ubuntu's
bamfdaemon, which tries to match windows and processes and intuit how to create
.desktop files which can restart the processes.   I looked briefly at the bamf code but could not figure out where the Exec string comes from.

Thank you for providing more feedback. Adding requester "mmanchala@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

... the problem no longer happens with new users, but that's not because a valid .desktop file is now being created; rather it is because bamfdaemon doesn't create $HOME/.local/share/applications/google-chrome.desktop at all any more when google-chrome isn't started with non-standard options.

Speculation: /usr/share/applications/google-chrome.desktop did not used to exist in earlier releases of the Ubuntu chromium package, which might have made bamfdaemon create a .local file (incorrectly).

 Issue 708411  has been merged into this issue.

Unable to reproduce the issue on reported version 60.0.3112.90 and latest stable 62.0.3202.62 and latest Canary 64.0.3255.3 using ubuntu 14.04 with the steps mentioned in C#2

Ubuntu is ditching Unity (in favor of Gnome) starting with Ubuntu 18.04. The whole bamfdaemon thing might change.  And it seems like Chrome can't work around the problem anyway.

So I suggest closing this as "WontFix".  Possibly re-open next year if someone reports the problem still occurs using the Gnome desktop, not Unity (i.e. on Ubuntu 18.04+ or 17.10 with the optional Gnome login).

AS per the comment #7 marking this issue as 'WontFix'.