[Webkit-unassigned] [Bug 258196] New: Overview: We noticed an unexpected behaviour of the NavigationPreload implementation that was recently added to Safari. The problem arises in case we do not return the preloaded response for the current navigation but store it for later use. It seems like

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=258196

            Bug ID: 258196
           Summary: Overview: We noticed an unexpected behaviour of the
                    NavigationPreload implementation that was recently
                    added to Safari. The problem arises in case we do not
                    return the preloaded response for the current
                    navigation but store it for later use. It seems like
           Product: WebKit
           Version: Other
          Hardware: All
                OS: macOS 13
            Status: NEW
          Severity: Major
          Priority: P2
         Component: Service Workers
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: youmna.elghandoor at baqend.com

Created attachment 466717

  --> https://bugs.webkit.org/attachment.cgi?id=466717&action=review

This is the code that reproduces the bug

Overview:
We noticed an unexpected behaviour of the NavigationPreload implementation that was recently added to Safari. The problem arises in case we do not return the preloaded response for the current navigation but store it for later use. It seems like the preload response unexpectedly stays indefinitely pending in case it was not already resolved at the time the navigation itself has finished. To illustrate the scenario we built a simple test page on which we provide two different test cases:
The navigation is answered slowly with a generated HTML response. This will ensure the navigation preload request can be resolved before the navigation itself is finished. We save the preload response for later use and try to access it via a fetch message afterwards. After the fetch successfully resolves we change the page's background color to green.
The navigation is answered immediately with a generated HTML response. This will be faster than the navigation preload request can be resolved. We again save the preload response for later use and try to access it via a fetch message afterwards. Since we also passed the preload response promise to event.waitUntil we would have expected this to work and subsequently the background color of the page should also turn green. This does however never happen. In the web inspector we can also see the request stays pending indefinitely.
In both Chrome and Firefox (latest version) we are not encountering this problem. We did see this problem also for Firefox when the NavigationPreloadAPI was first introduced but it seems to be fixed since version 107 in case that helps to narrow down the issue.
Steps to Reproduce:
1. Open https://sw-lifecycle-test.app.baqend.com/navigationPreloadBug/index.html
2. Reload the page to ensure the Service Worker is successfully installed
3. Click on Navigate with Preload already finished
4. Go back to the index.html
5. Click on Navigate with Preload still pending
Actual Results:
After step 3, A slow navigation should be initiated to ensure the Preload Response is resolved before the navigation finishes
A page with the text „Generated navigation” and a green background should be displayed


After step 5, 
The same generated page should be displayed almost instantly but the background never turns green


Expected Results: Both pages’ backgrounds should turn green

Build Date & Hardware: 2023-06-16 on Mac OS 13.3.1

Additional Builds and Platforms: This same problem used to occur on Firefox  in versions prior to version 107

Additional Information: 

I have attached the code used to reproduce the bug.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20230616/29890604/attachment.htm>