Add 'haschrome=1' to avoid unexpected back buttons on the first page.

[fengga]

https://identitydivision.visualstudio.com/Engineering/_workitems/edit/2972166

Fixes #4738

Changes proposed in this request

It's very easy to reproduce (need to add login hint in the test app code first) the back button by:

In MSAL C++, interactively calls always add "haschrome=1" to avoid such kind of unexpected back buttons on the first page, and this way is also recommended by ESTS folks.
https://github.com/AzureAD/microsoft-authentication-library-for-cpp/blob/4fa774db2b38cdce9c9b94e3e686ab53fc24b948/source/xplat/requests/WebRequestManager.cpp#L566

After adding "haschrome=1" the issue can be resolved:

Testing

Performance impact

Documentation

• All relevant documentation is updated.

[bgavrilMS]

Nice fix @fengga . Just see that a few unit tests need to be updated.

[rayluo]

In MSAL C++, interactively calls always add "haschrome=1" to avoid such kind of unexpected back buttons on the first page, and this way is also recommended by ESTS folks.

Intriguing finding. It feels like folklore because even the name of that workaround - "haschrome" - does not make much sense. :-)

On a more serious note, the current feature branch name is "fixEmbeddedbrowser", however, now I realize that the same mysterious Back-button behavior also applies to Firefox as system browser: it shows up by default, and disappears when using haschrome=1. But I am not aware of other complain, presumably because that default Back button is understandably perceived as a Cancel. So, I suppose we do not have to propagate this change to all other MSALs, do we?