282689 2024-11-06 06:45:56 -0800 [Navigation] Fix remaining problems with traversals 2024-12-20 16:13:04 -0800 1 1 1 Unclassified WebKit Page Loading WebKit Nightly Build Unspecified Unspecified NEW InRadar P2 Normal --- 284865 285045 258384 1 rbuis webkit-unassigned beidson cdumez webkit-bug-importer oldest_to_newest 2073162 0 rbuis 2024-11-06 06:45:56 -0800 Fix remaining problems with traversals. 2073164 1 rbuis 2024-11-06 06:46:57 -0800 Traversal tests timing out: navigation-methods/back-forward-multiple-frames.html traverseTo-detach-between-navigate-and-navigatesucces.html navigation-traverseTo-in-iframe-same-document-preventDefault.html navigation-traverseTo-navigates-top-and-same-doc-child-and-cross-doc-child.html 2073165 2 rbuis 2024-11-06 06:48:34 -0800 This will have to be debugged more closely to see what is the problem. I suspect that for at least for one of them the problem is not correctly cancelling navigation for both top and subframe. 2074792 3 webkit-bug-importer 2024-11-13 06:46:13 -0800 <rdar://problem/139799959> 2080198 4 cdumez 2024-12-09 07:49:41 -0800 I started taking a look at navigation-methods/back-forward-multiple-frames.html. At the following step: // Going back in top should go 3->1 (navigating both windows). This resolves: ``` await navigation.back().commited; ``` but this doesn't: ``` new Promise(resolve => i.contentWindow.onpopstate = resolve) ``` 2080199 5 cdumez 2024-12-09 08:18:21 -0800 navigation-methods/back-forward-multiple-frames.html has a top frame and an iframe. The test does this: 1. Navigate the top frame to "#top" 2. Navigate the iframe to "#iframe" 3. Call `navigation.back()` in the top frame 4. Expects both the top frame and the iframe to get navigated back (so that the fragment is removed from both) and a popstate event to get fired in both frames. This works in Blink but in WebKit, only the top frame gets navigated and gets a popstate event. The iframe is still sitting on "#iframe" after calling `navigation.back()` in the top frame. 2080218 6 cdumez 2024-12-09 09:10:14 -0800 (In reply to Chris Dumez from comment #5) > navigation-methods/back-forward-multiple-frames.html has a top frame and an > iframe. > The test does this: > 1. Navigate the top frame to "#top" > 2. Navigate the iframe to "#iframe" > 3. Call `navigation.back()` in the top frame > 4. Expects both the top frame and the iframe to get navigated back (so that > the fragment is removed from both) and a popstate event to get fired in both > frames. > > This works in Blink but in WebKit, only the top frame gets navigated and > gets a popstate event. The iframe is still sitting on "#iframe" after > calling `navigation.back()` in the top frame. Looking at the `Navigation::back()` implementation, it does look like it doesn't quite match the specification and only navigates a single frame. In the spec, we're supposed to also navigate child frames if the navigation of the parent frame doesn't change document (i.e. just a fragment navigation). 2080220 7 cdumez 2024-12-09 09:19:38 -0800 (In reply to Chris Dumez from comment #6) > (In reply to Chris Dumez from comment #5) > > navigation-methods/back-forward-multiple-frames.html has a top frame and an > > iframe. > > The test does this: > > 1. Navigate the top frame to "#top" > > 2. Navigate the iframe to "#iframe" > > 3. Call `navigation.back()` in the top frame > > 4. Expects both the top frame and the iframe to get navigated back (so that > > the fragment is removed from both) and a popstate event to get fired in both > > frames. > > > > This works in Blink but in WebKit, only the top frame gets navigated and > > gets a popstate event. The iframe is still sitting on "#iframe" after > > calling `navigation.back()` in the top frame. > > Looking at the `Navigation::back()` implementation, it does look like it > doesn't quite match the specification and only navigates a single frame. In > the spec, we're supposed to also navigate child frames if the navigation of > the parent frame doesn't change document (i.e. just a fragment navigation). Relevant spec: https://html.spec.whatwg.org/#getting-all-navigables-that-might-experience-a-cross-document-traversal 2080221 8 cdumez 2024-12-09 09:24:26 -0800 (In reply to Chris Dumez from comment #7) > (In reply to Chris Dumez from comment #6) > > (In reply to Chris Dumez from comment #5) > > > navigation-methods/back-forward-multiple-frames.html has a top frame and an > > > iframe. > > > The test does this: > > > 1. Navigate the top frame to "#top" > > > 2. Navigate the iframe to "#iframe" > > > 3. Call `navigation.back()` in the top frame > > > 4. Expects both the top frame and the iframe to get navigated back (so that > > > the fragment is removed from both) and a popstate event to get fired in both > > > frames. > > > > > > This works in Blink but in WebKit, only the top frame gets navigated and > > > gets a popstate event. The iframe is still sitting on "#iframe" after > > > calling `navigation.back()` in the top frame. > > > > Looking at the `Navigation::back()` implementation, it does look like it > > doesn't quite match the specification and only navigates a single frame. In > > the spec, we're supposed to also navigate child frames if the navigation of > > the parent frame doesn't change document (i.e. just a fragment navigation). > > Relevant spec: > https://html.spec.whatwg.org/#getting-all-navigables-that-might-experience-a- > cross-document-traversal And https://html.spec.whatwg.org/#get-all-navigables-whose-current-session-history-entry-will-change-or-reload 2083146 9 cdumez 2024-12-19 15:58:15 -0800 Still failing: - imported/w3c/web-platform-tests/navigation-api/navigation-methods/traverseTo-detach-between-navigate-and-navigatesuccess.html - imported/w3c/web-platform-tests/navigation-api/navigate-event/navigation-traverseTo-in-iframe-same-document-preventDefault.html Other failures have been addressed in the dependency Bug 284865. 2083409 10 cdumez 2024-12-20 15:13:49 -0800 Bug 285045 should take care of: - imported/w3c/web-platform-tests/navigation-api/navigate-event/navigation-traverseTo-in-iframe-same-document-preventDefault.html 2083423 11 cdumez 2024-12-20 15:51:49 -0800 Did some early investigation for imported/w3c/web-platform-tests/navigation-api/navigation-methods/traverseTo-detach-between-navigate-and-navigatesuccess.html, it seems due to the following code in `FrameLoader::stopLoading()`: ``` if (document->settings().navigationAPIEnabled() && !m_doNotAbortNavigationAPI && unloadEventPolicy != UnloadEventPolicy::UnloadAndPageHide) { RefPtr window = m_frame->document()->domWindow(); window->protectedNavigation()->abortOngoingNavigationIfNeeded(); } ``` If you comment out the `unloadEventPolicy != UnloadEventPolicy::UnloadAndPageHide` check then the test start passing. 2083430 12 cdumez 2024-12-20 16:13:04 -0800 (In reply to Chris Dumez from comment #11) > Did some early investigation for > imported/w3c/web-platform-tests/navigation-api/navigation-methods/traverseTo- > detach-between-navigate-and-navigatesuccess.html, it seems due to the > following code in `FrameLoader::stopLoading()`: > ``` > if (document->settings().navigationAPIEnabled() && > !m_doNotAbortNavigationAPI && unloadEventPolicy != > UnloadEventPolicy::UnloadAndPageHide) { > RefPtr window = m_frame->document()->domWindow(); > window->protectedNavigation()->abortOngoingNavigationIfNeeded(); > } > ``` > > If you comment out the `unloadEventPolicy != > UnloadEventPolicy::UnloadAndPageHide` check then the test start passing. Making this change breaks a few tests though: imported/w3c/web-platform-tests/navigation-api/navigation-methods/navigate-history-push-same-url-cross-document.html [ Failure ] imported/w3c/web-platform-tests/navigation-api/navigation-methods/return-value/traverseTo-detach-same-document-before-navigate-event.html [ Failure ] imported/w3c/web-platform-tests/navigation-api/ordering-and-transition/transition-cross-document.html [ Failure ]