olivierrobin@ could you PTAL.

The canonical URL is https://plus.google.com/discover, so AFAICT, this is WAI.
Adding Android as this is a mobile issue.

Keeping ownership as gchatz@ left
Adding mardini@ for decision
Adding tedchoc@ for Android

Another bug about canonical URL breakage:
https://bugs.chromium.org/p/chromium/issues/detail?id=813813

To give another repro case with more details on exactly what happens:

Chrome Dev 66.0.3352.3

1. Visit https://www.instagram.com/simpsons_meme_factory/

2. Click on any of the fine wares on display.
   *Navigation happens via a pushState() rather than a new page request.*

   The URL in the bar is now something like
   https://www.instagram.com/p/BfdCdnOFVm9/

3. Tap menu > share.

EXPECTED RESULT:
The URL that is shared is:
https://www.instagram.com/p/BfdCdnOFVm9/

ACTUAL RESULT:
The URL that is shared is:
https://www.instagram.com/simpsons_meme_factory/

Wearing my webdev hat:

I see three issues with this:

- Websites that manipulate the URL with pushState/replaceState don't expect to have to (and sometimes can't) update the canonical URL that was first loaded.  (This is what the original reporter noticed about Google+, and what I noticed about Instagram.)  These sites only expect to set the canonical URL on page load, and not update it with internal nav.

- Some websites use the URL to store state that, while it is meaningful and useful to humans, is not useful in the indexing process.  (I have a more detailed explanation below.)

---

To go into more detail:

In the web application I work on, sharing the rel-canonical link isn't something I want to happen in any case.  I work on an application with a map, and we use replaceState to generate URLs that look like:

https://my-app.example.com/map/place-id?type=something&lat=...&lng=...&zoom=...

If a user requests that URL, we show a map centered on the given point at the given zoom level.  However, we also include a Link: ... rel=canonical header with this URL:

https://my-app.example.com/map/place-id?type=something

(i.e., the URL without the lat/lng/zoom)

This is explicitly intended, so that when a user shares their page, the recipient sees the exact view they see.  However, when accessed by a search engine, the search engine is informed that lat/lng/zoom are irrelevant for indexing, and only the place id and type are important.