248303 2022-11-24 03:11:37 -0800 REGRESSION (iOS 16): popstate events are not fired for swipe-back gesture 2024-11-03 01:44:15 -0800 1 1 1 Unclassified WebKit DOM Safari 16 iPhone / iPad iOS 16 NEW InRadar P2 Major --- 1 r.kato webkit-unassigned achristensen beidson cdumez madsams024 mhjacobson mike pp.mizdra simon.fraser thorton webkit-bug-importer oldest_to_newest 1914452 0 r.kato 2022-11-24 03:11:37 -0800 My device: - iOS: 16.1.1 - User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 16_1_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.1 Mobile/15E148 Safari/604.1 Steps to reproduce: - Open test1.html in iOS 16.1.1 Safari - Tap "Link" to be navigated to test2.html - Do swipe-back gesture in test2.html Actual result: - alert(1) is not shown Expected result: - alert(1) should be shown Notes: - This issue is not occurred in iOS 15 (and earlier, maybe) - popstate events are fired when `history.back()` (you can confirm this by a button in test2.html) 1914453 1 463703 r.kato 2022-11-24 03:12:19 -0800 Created attachment 463703 test1.html (test case) 1914454 2 463704 r.kato 2022-11-24 03:12:59 -0800 Created attachment 463704 test2.html (test case) 1914793 3 webkit-bug-importer 2022-11-26 14:47:31 -0800 <rdar://problem/102683851> 1921981 4 mike 2022-12-26 23:19:29 -0800 Also been noticed in questions at Stack Overflow https://stackoverflow.com/questions/74233075/popstate-does-not-work-since-safari-16-it-was-working-until-safari-15 1922633 5 cdumez 2023-01-03 09:33:11 -0800 I just tried and can reproduce on macOS too. I see the alert when clicking the `history.back()` button but not when clicking the back button (or swiping back). I don't have an explanation yet for the different in behavior between history.back() and navigating back via the browser UI (though I suspect this is related to some of the back/forward list hijacking prevention work we did). What I noticed also is that our behavior seems consistent with Chrome. Therefore, if there is a bug, it is not WebKit-specific. Firefox seems to show the alert consistently, as is expected by the Web developer. 1922635 6 cdumez 2023-01-03 09:38:21 -0800 Oh, I just looked at the test case more closely and I understand what is happening now. Similarly to Chrome, WebKit recently did some security hardening to prevent bad JavaScript from hijacking the back/forward list. This means that history entries added by JS (e.g. via history.pushState()) get skipped on user navigation unless they were added with a user interaction. In your test case, test2.html calls history.pushState() without a user interaction. As a result, the created history item gets marked with a special flag. If the user swipes back or presses the back button, we will skip this "dummy" history item, and thus not fire a popstate event. This is new intentional behavior, which should be consistent with Blink. If you do not want your history item to get skipped, then you need a user gesture / activation when calling history.pushState() (e.g. calling history.pushState() as a result of a button getting clicked by the user). 1939681 7 mhjacobson 2023-03-08 00:06:53 -0800 Hey Chris and WebKit team, Thanks for the explanation. For reference, I believe that the change Chris is describing is <https://bugs.webkit.org/show_bug.cgi?id=241885> (<https://commits.webkit.org/251783@main>), plus follow-up fix in <https://bugs.webkit.org/show_bug.cgi?id=242947> (<https://commits.webkit.org/252649@main>). Now: in my experimentation on an iPhone SE (2nd edition) running iOS 16.3.1 (20D67), the "is history item added by user interaction" detection is rather unpredictable when using the "touchend" event. Sometimes, a history item added in a "touchend" listener is considered to be "added by user interaction", and sometimes it isn't, with little apparent pattern. However, looking at the WebKit source changes in the commits above, I have a hypothesis. The core of the "added by user interaction?" logic is (from Document.cpp): ``` bool Document::hasRecentUserInteractionForNavigationFromJS() const { if (UserGestureIndicator::processingUserGesture(this)) return true; static constexpr Seconds maximumItervalForUserGestureForwarding { 10_s }; return (MonotonicTime::now() - lastHandledUserGestureTimestamp()) <= maximumItervalForUserGestureForwarding; } ``` That is, we return true if either `processingUserGesture()` returns true or if the time returned by `lastHandledUserGestureTimestamp()` is no more than a second ago. The return value of `lastHandledUserGestureTimestamp()` is a member updated by calls to `updateLastHandledUserGestureTimestamp()`. Among other places, the latter is called when a `UserGestureIndicator` object is constructed and creates a new `UserGestureToken`. Based on context clues, I suspect that `UserGestureToken` is an object that tracks the entire *lifetime* of a touch, not a single touch event. (Here are the clues: `UserGestureToken` has `startTime` member; "gesture" is the term used in AppKit and UIKit to mean an entire touch-event sequence.) This might mean that what `hasRecentUserInteractionForNavigationFromJS()` is *really* testing is whether the *beginning* of the last gesture was more than a second ago. If that's true, then one downstream effect might be the following: attempting to add a history item in a "touchend" listener might succeed or not based on the duration of the entire gesture. And in fact, that seems to be sort of what I'm seeing! I'm not able to measure an exact one-second threshold (from the measurements I'm able to do in JavaScript), but I definitely see that *short* gestures tend to succeed (i.e., add the history item in a way that the back button respects), and *long* gestures tend not to. (Maybe iOS changes that one-second value to something else? Maybe there is a race? I'm not breaking out a disassembler tonight, sorry! But I'm interested to know what's going on there.) I'll attach a test case that I'm using to demonstrate the above. Hope this is enough to help you track down the bug. 1939682 8 465356 mhjacobson 2023-03-08 00:08:42 -0800 Created attachment 465356 test of the duration-sensitive touchend behavior I described in my comment 463703 2022-11-24 03:12:19 -0800 2022-11-24 03:12:19 -0800 test1.html (test case) test1.html text/html 242 r.kato PCFET0NUWVBFIGh0bWw+CjxodG1sIGxhbmc9ImVuIj4KICA8aGVhZD4KICAgIDxtZXRhIGNoYXJz ZXQ9IlVURi04IiAvPgogICAgPG1ldGEgbmFtZT0idmlld3BvcnQiIGNvbnRlbnQ9IndpZHRoPWRl dmljZS13aWR0aCwgaW5pdGlhbC1zY2FsZT0xLjAiPgogICAgPHRpdGxlPlRlc3QxPC90aXRsZT4K ICA8L2hlYWQ+CiAgPGJvZHk+CiAgICA8YSBocmVmPSJ0ZXN0Mi5odG1sIj5MaW5rPC9hPgogIDwv Ym9keT4KPC9odG1sPgo= 463704 2022-11-24 03:12:59 -0800 2022-11-24 03:12:59 -0800 test2.html (test case) test2.html text/html 490 r.kato PCFET0NUWVBFIGh0bWw+CjxodG1sIGxhbmc9ImVuIj4KICA8aGVhZD4KICAgIDxtZXRhIGNoYXJz ZXQ9IlVURi04IiAvPgogICAgPG1ldGEgbmFtZT0idmlld3BvcnQiIGNvbnRlbnQ9IndpZHRoPWRl dmljZS13aWR0aCwgaW5pdGlhbC1zY2FsZT0xLjAiPgogICAgPHRpdGxlPlRlc3QyPC90aXRsZT4K ICA8L2hlYWQ+CiAgPGJvZHk+CiAgICA8YnV0dG9uIGlkPSJidG4iPmhpc3RvcnkuYmFjaygpPC9i dXR0b24+CiAgICA8c2NyaXB0PgogICAgICBoaXN0b3J5LnB1c2hTdGF0ZShudWxsLCBudWxsLCBu dWxsKQoKICAgICAgd2luZG93LmFkZEV2ZW50TGlzdGVuZXIoInBvcHN0YXRlIiwgXyA9PiBhbGVy dCgxKSkKCiAgICAgIGRvY3VtZW50LmdldEVsZW1lbnRCeUlkKCJidG4iKS5hZGRFdmVudExpc3Rl bmVyKCJjbGljayIsIF8gPT4gewogICAgICAgIGhpc3RvcnkuYmFjaygpCiAgICAgIH0sIGZhbHNl KQogICAgPC9zY3JpcHQ+CiAgPC9ib2R5Pgo8L2h0bWw+Cg== 465356 2023-03-08 00:08:42 -0800 2023-03-08 00:08:42 -0800 test of the duration-sensitive touchend behavior I described in my comment matt-test.html text/html 1479 mhjacobson PCFET0NUWVBFIGh0bWw+CjxodG1sIGxhbmc9ImVuIj4KICA8aGVhZD4KICAgIDxtZXRhIGNoYXJz ZXQ9IlVURi04IiAvPgogICAgPG1ldGEgbmFtZT0idmlld3BvcnQiIGNvbnRlbnQ9IndpZHRoPWRl dmljZS13aWR0aCwgaW5pdGlhbC1zY2FsZT0xLjAiIC8+CiAgICA8dGl0bGU+dGVzdCBmb3Igd2Vi a2l0IGJ1ZyAjMjQ4MzAzPC90aXRsZT4KICAgIDxzdHlsZT4KICAgICAgI2JveCB7CiAgICAgICAg dHJhbnNpdGlvbi1wcm9wZXJ0eTogbGVmdDsKICAgICAgICB0cmFuc2l0aW9uLWR1cmF0aW9uOiAy NTBtczsKICAgICAgICB0cmFuc2l0aW9uLXRpbWluZy1mdW5jdGlvbjogZWFzZS1pbi1vdXQ7CiAg ICAgICAgbGVmdDogMHB4OwogICAgICAgIHBvc2l0aW9uOiByZWxhdGl2ZTsKICAgICAgfQogICAg PC9zdHlsZT4KICA8L2hlYWQ+CiAgPGJvZHk+CiAgICA8ZGl2IGlkPSJib3giIHN0eWxlPSJ3aWR0 aDogMTAwcHg7IGhlaWdodDogMTAwcHg7IGJhY2tncm91bmQ6IGdyZWVuOyI+PC9kaXY+CiAgICA8 c2NyaXB0PgogICAgICBsZXQgc3RhcnRUaW1lID0gbnVsbCwgbGFzdFRpbWUgPSBudWxsOwogICAg ICBsZXQgY291bnRlciA9IDA7CiAgICAgIGNvbnN0IGJveCA9IGRvY3VtZW50LmdldEVsZW1lbnRC eUlkKCJib3giKTsKCiAgICAgIHdpbmRvdy5vbnBvcHN0YXRlID0gZnVuY3Rpb24oZSkgewogICAg ICAgIGNvbnNvbGUubG9nKGUuc3RhdGUpOwogICAgICAgIGNvdW50ZXIgPSBlLnN0YXRlID8gZS5z dGF0ZS5jb3VudGVyIDogMDsKICAgICAgICBib3guc3R5bGUubGVmdCA9IGAke2NvdW50ZXIgKiAx MH1weGA7CiAgICAgIH07CgogICAgICBkb2N1bWVudC5hZGRFdmVudExpc3RlbmVyKCJ0b3VjaHN0 YXJ0IiwgZSA9PiB7CiAgICAgICAgbGFzdFRpbWUgPSBzdGFydFRpbWUgPSBEYXRlLm5vdygpOwog ICAgICB9LCB7IHBhc3NpdmU6IGZhbHNlIH0pOwoKICAgICAgZG9jdW1lbnQuYWRkRXZlbnRMaXN0 ZW5lcigidG91Y2htb3ZlIiwgZSA9PiB7CiAgICAgICAgbGFzdFRpbWUgPSBEYXRlLm5vdygpOwog ICAgICB9LCB7IHBhc3NpdmU6IGZhbHNlIH0pOwoKICAgICAgZG9jdW1lbnQuYWRkRXZlbnRMaXN0 ZW5lcigidG91Y2hlbmQiLCBlID0+IHsKICAgICAgICBjb25zdCBlbmRUaW1lID0gRGF0ZS5ub3co KTsKICAgICAgICBjb3VudGVyKys7CiAgICAgICAgaGlzdG9yeS5wdXNoU3RhdGUoe2NvdW50ZXI6 IGNvdW50ZXJ9LCAiIiwgYC90ZXN0Lmh0bWwvJHtjb3VudGVyfWApOyAgICAgCiAgICAgICAgYm94 LnN0eWxlLmxlZnQgPSBgJHtjb3VudGVyICogMTB9cHhgOwoKICAgICAgICBjb25zb2xlLmxvZyhl bmRUaW1lIC0gc3RhcnRUaW1lKTsKICAgICAgICBjb25zb2xlLmxvZyhlbmRUaW1lIC0gbGFzdFRp bWUpOwogICAgICAgIHN0YXJ0VGltZSA9IG51bGw7CglsYXN0VGltZSA9IG51bGw7CiAgICAgIH0s IHsgcGFzc2l2ZTogZmFsc2UgfSk7CiAgICA8L3NjcmlwdD4KICA8L2JvZHk+CjwvaHRtbD4K