epriestley 7a79131bf2 Replace old hard-coded URI-based "changes saved" jank with new overgeneralized cookie-based "changes saved" jank ... Summary: Ref T13515. Settings currently has some highly specialized code for rendering "Changes saved." messages. The "saved" state is communicated across a redirect-after-POST by adding `/saved/` to the end of the URI. This isn't great. It needs a lot of moving pieces, including special accommodations in routing rules. It's user-visible. It has the wrong behavior if you reload the page or navigate directly to the "saved" URI. Try this scheme, which is also pretty sketchy but seems like an upgrade on the balance: - Set a cookie on the redirect which identifies the form we just saved. - On page startup: if this cookie exists, save the value and clear it. - If the current page started with a cookie identifying the form on the page, treat the page as a "saved" page. This supports passing a small amount of state across the redirect-after-POST flow, and when you reload the page it doesn't keep the message around. Applications don't need to coordinate it, either. Seems somewhat cleaner? Test Plan: In Firefox, Safari, and Chrome: saved settings, saw a "Saved changes" banner without any URI junk. Reloaded page, saw banner vanish properly. Maniphest Tasks: T13515 Differential Revision: https://secure.phabricator.com/D21144		2020-04-19 09:04:31 -07:00
..
PhabricatorAuthApplication.php	Replace old hard-coded URI-based "changes saved" jank with new overgeneralized cookie-based "changes saved" jank	2020-04-19 09:04:31 -07:00