263635 2023-10-24 23:50:03 -0700 window.history.replaceState('', '', '') has no effect in Safari on macOS 2024-09-12 10:03:45 -0700 1 1 1 Unclassified WebKit History Safari 16 All All RESOLVED FIXED InRadar P2 Major --- 276375 1 harnoor1994 pgriffis ahmad.saleem792 d harnoor1994 mike pgriffis sun.shin webkit-bug-importer oldest_to_newest 1987322 0 harnoor1994 2023-10-24 23:50:03 -0700 window.history.replaceState('', '', '') behave differently on Safari on MacOS. It is supposed to update the address bar to the default URL (before the hash parameter). But it has no effect on Safari on MacOS. 1987606 1 ahmad.saleem792 2023-10-25 16:13:19 -0700 Can you share test case to reproduce the issue? Plus whether it is reproducible on latest Safari Technology Preview 181? 1989090 2 webkit-bug-importer 2023-10-31 23:50:15 -0700 <rdar://problem/117782346> 1989188 3 harnoor1994 2023-11-01 10:33:37 -0700 Yes it is reproducible on Safari Technology Preview 181. I am working on test cases. Thanks! 1989346 4 mike 2023-11-01 22:12:25 -0700 Ideally what would be the most help is a WPT test that would be runnable under the WPT test harness. You can find the existing such tests at https://github.com/web-platform-tests/wpt/tree/master/html/browsers/history/the-history-interface — for example, https://github.com/web-platform-tests/wpt/blob/master/html/browsers/history/the-history-interface/history_replacestate.html And you can run those tests directly in any browser by going, for example, to http://wpt.live/html/browsers/history/the-history-interface/history_replacestate.html So you might be able to just add a `window.history.replaceState('', '', '')` test (with an assert_equals or some other kind of assert_*) directly to a copy of the existing https://github.com/web-platform-tests/wpt/blob/master/html/browsers/history/the-history-interface/history_replacestate.html source 2057246 5 472419 harnoor1994 2024-09-03 08:07:26 -0700 Created attachment 472419 index.html to illustrate the bug repro I am attaching an index.html to illustrate a behavior related to how Safari on macOS handles URL changes when using the replaceState function. It is no repro on Chrome. Repo Link of same index.html: https://github.com/HarnoorSinghKhurana/safari-test/tree/main Live Test Link : https://exquisite-fudge-6ed920.netlify.app/ Expected Behavior: 1. Clicking "Go to Deep Link" should update the URL with the fragment (#/deeplink?test-id=6f5d61af). 2. Clicking "Back to Default Route" should clear the fragment and restore the URL to its base path. In Safari on macOS, the clearDeepLink function donot clear the fragment from the URL, leaving it unchanged. 2057714 6 sun.shin 2024-09-04 15:15:41 -0700 Add the attached TC on W3C: https://github.com/web-platform-tests/wpt/pull/47973 2057715 7 sun.shin 2024-09-04 15:18:27 -0700 Tested on STP #202, confirmed that it has been fixed. 2057822 8 d 2024-09-04 23:30:09 -0700 This fix appears to contradict the spec, per https://html.spec.whatwg.org/#shared-history-push/replace-state-steps step 6. 2058216 9 sun.shin 2024-09-06 08:51:04 -0700 @Domenic, the changes made on <https://bugs.webkit.org/show_bug.cgi?id=276375> patched by 2058217 10 sun.shin 2024-09-06 08:52:09 -0700 @Domenic, the changes made on <https://bugs.webkit.org/show_bug.cgi?id=276375> patched by Patrick Griffis. I think we have to go back the the patch and see what is the right path for the issue. 2058967 11 pgriffis 2024-09-10 07:28:50 -0700 I can look into this but is there no test case? web-platform-tests/html/browsers/history/the-history-interface/history_replacestate.html PASSes. > Expected Behavior: > 1. Clicking "Go to Deep Link" should update the URL with the fragment (#/deeplink?test-id=6f5d61af). > 2. Clicking "Back to Default Route" should clear the fragment and restore the URL to its base path. This test works in WebKit main and Chrome, but not on Firefox 129. 2058978 12 pgriffis 2024-09-10 08:36:23 -0700 Pull request: https://github.com/WebKit/WebKit/pull/33402 2058979 13 pgriffis 2024-09-10 08:37:53 -0700 If I understand correctly, not updating the URL is correct per the spec. Firefox matched this, Chrome 127.0.6533.99 did not. I've submitted a draft PR above. Does this sound right Domenic? 2058983 14 pgriffis 2024-09-10 08:46:53 -0700 > is there no test case? WebKit didn't have html/browsers/history/the-history-interface/pushstate-replacestate-empty-string/ imported so that makes sense. With my PR all tests pass. 2059707 15 ews-feeder 2024-09-12 10:03:43 -0700 Committed 283565@main (ba51e8eae852): <https://commits.webkit.org/283565@main> Reviewed commits have been landed. Closing PR #33402 and removing active labels. 472419 2024-09-03 08:07:26 -0700 2024-09-03 08:07:26 -0700 index.html to illustrate the bug repro index.html text/html 891 harnoor1994 PCFET0NUWVBFIGh0bWw+DQo8aHRtbCBsYW5nPSJlbiI+DQo8aGVhZD4NCiAgICA8bWV0YSBjaGFy c2V0PSJVVEYtOCI+DQogICAgPGJhc2UgaHJlZj0iIyIgdGFyZ2V0PSJfYmxhbmsiIC8+DQogICAg PHNjcmlwdD4NCiAgICAgICAgLy8gRnVuY3Rpb24gdG8gdXBkYXRlIHRoZSBhZGRyZXNzIGJhciB0 byB0aGUgZGVlcCBsaW5rDQogICAgICAgIGZ1bmN0aW9uIHVwZGF0ZVRvRGVlcExpbmsoKSB7DQog ICAgICAgICAgICBjb25zdCB1cmwgPSB3aW5kb3cubG9jYXRpb24ub3JpZ2luICsgd2luZG93Lmxv Y2F0aW9uLnBhdGhuYW1lICsgIiMvZGVlcGxpbms/dGVzdC1pZD02ZjVkNjFhZiI7DQogICAgICAg ICAgICB3aW5kb3cuaGlzdG9yeS5yZXBsYWNlU3RhdGUoJycsICcnLCB1cmwpOw0KICAgICAgICB9 DQoNCiAgICAgICAgLy8gRnVuY3Rpb24gdG8gY2xlYXIgdGhlIGRlZXAgbGluayBhbmQgbmF2aWdh dGUgYmFjayB0byB0aGUgZGVmYXVsdCByb3V0ZQ0KICAgICAgICBmdW5jdGlvbiBjbGVhckRlZXBM aW5rKCkgew0KICAgICAgICAgICAgd2luZG93Lmhpc3RvcnkucmVwbGFjZVN0YXRlKCcnLCAnJywg JycpOw0KICAgICAgICB9DQogICAgPC9zY3JpcHQ+DQo8L2hlYWQ+DQo8Ym9keT4NCiAgICA8aDE+ UmVkaXJlY3QgRXhhbXBsZTwvaDE+DQogICAgPHA+UmVkaXJlY3RpbmcgdG8gdGhlIGRlZmF1bHQg cm91dGUuLi48L3A+DQoNCiAgICA8IS0tIEJ1dHRvbnMgdG8gY2hhbmdlIFVSTCAtLT4NCiAgICA8 YnV0dG9uIG9uY2xpY2s9InVwZGF0ZVRvRGVlcExpbmsoKSI+R28gdG8gRGVlcCBMaW5rPC9idXR0 b24+DQogICAgPGJ1dHRvbiBvbmNsaWNrPSJjbGVhckRlZXBMaW5rKCkiPkJhY2sgdG8gRGVmYXVs dCBSb3V0ZTwvYnV0dG9uPg0KPC9ib2R5Pg0KPC9odG1sPg0K