[BUG] iOS WKWebView caches old PDF blobs

[ncpunt]

What happened?

If I use the following code to view a dynamically generated PDF on iOS-WKWebView using jsPDF, the same (first) PDF is shown regardless of any changes to later generated PDFs.

let a = document.createElement("a") 
a.download = "report.pdf";
a.href = doc.output('bloburl');
a.click();
document.body.removeChild(a)

The only way to show fresh PDF contents is to randomize the filename.

a.download = crypto.randomUUID();

Does anyone know an alternative method because I am a bit worried the cached files will pile up. I am also reluctant changing the Swift code generated by PWABuilder.

How do we reproduce the behavior?

Use the code in the description.

What do you expect to happen?

Behavior as in all other browsers where this is not required.

What environment were you using?

Physical iPhone 12 device (iOS 18) and a iOS Simulator on an Intel Mac

Additional context

All browsers and all platforms do not have this problem with the exception of iOS WKWebView.

[jgw96]

@maiconcarraro any ideas here? Or maybe @khmyznikov

[maiconcarraro]

@jgw96 I can explore later this week,

@ncpunt can you share a demo github project using this? so I can clone and host it to generate the ios package and debug it. having only the snippet will take a longer time to have everything set up correctly and can lead to side effects.

[ncpunt]

Repo: WKWebViewCache
Link: Host

[ncpunt]

If you run this on Windows in Chrome, you will see that Chrome automatically generates a randome file name.

[maiconcarraro]

@jgw96 @ncpunt I found the root cause, inside of download function it returns the file by suggested name:

so using the same name, will return the existing file, even if you have different blobs:

Optional("blob:https://www.medimatics.nl/f8c71cb4-59dc-4313-9860-a65e66d44f42")
file:///Users/user/Library/Developer/CoreSimulator/Devices/98206E0A-8A95-409E-AC8A-08994C38A89F/data/Containers/Data/Application/DCE0F696-CA1D-43C4-A2BE-BAFC43C5B50F/Documents/mypdf.pdf

Optional("blob:https://www.medimatics.nl/4b91cc45-ae31-4bfd-ad0b-265d669ec748")
file:///Users/user/Library/Developer/CoreSimulator/Devices/98206E0A-8A95-409E-AC8A-08994C38A89F/data/Containers/Data/Application/DCE0F696-CA1D-43C4-A2BE-BAFC43C5B50F/Documents/mypdf.pdf

You can fix this by making sure to remove the previous file:

func download(_ download: WKDownload, decideDestinationUsing response: URLResponse,
                suggestedFilename: String,
                completionHandler: @escaping (URL?) -> Void) {

        let documentsPath = FileManager.default.urls(for: .documentDirectory, in: .userDomainMask)[0]
        let fileURL = documentsPath.appendingPathComponent(suggestedFilename)
        
        // Remove existing file if it exists
        if FileManager.default.fileExists(atPath: fileURL.path) {
            try? FileManager.default.removeItem(at: fileURL)
        }

        self.openFile(url: fileURL)
        completionHandler(fileURL)
    }

see FileManager.default.removeItem above. using this approach solved the situation on my debugging session.

[maiconcarraro]

@ncpunt

If you run this on Windows in Chrome, you will see that Chrome automatically generates a randome file name.

that's not right, you have a different condition for non-ios device, both have a random blob file name, if you simulate an ios userAgent for the chrome and click it will download the file, and if you click again it will show again to download same file... but windows/chrome will make sure to keep both files and renaming the second:

which was the problem for the ios, it wasn't renaming or making sure to delete old file, if you want to always guarantee an unique file, I do recommend to add timestamp to your file name, in case you can't... you can modify your xcode project to include the fix above.

[ncpunt]

I did not realilze that "doc.output('bloburl')" would already generate a random filename.
I am happy with my workaround without touching the Swift code. Will you make changes to the code generated by PWABuilder?

[jgw96]

@ncpunt or @maiconcarraro would one of yall want to make a PR for this change? Our iOS platform is mainly community driven

[maiconcarraro]

@jgw96 I sent on same day: pwa-builder/pwabuilder-ios#69

[microsoft-github-policy-service]

This issue has been marked as "needs attention 👋" since it has not been triaged for 7 days. Please triage the issue .

[microsoft-github-policy-service]

This issue has been marked as "needs attention 👋" since it has not been triaged for 7 days. Please triage the issue .

[microsoft-github-policy-service]

This issue has been marked as "needs attention 👋" since it has not been triaged for 7 days. Please triage the issue .

[microsoft-github-policy-service]

This issue has been marked as "needs attention 👋" since it has not been triaged for 7 days. Please triage the issue .