Hello,
The iPadOS application I'm working on has a WKWebView which should provide an Angular app. That does still work but the routing in the javascript based application isn't anymore.
The error I can inspect begins with following snippet:
.
ERROR Error: Uncaught (in promise): SecurityError: Blocked attempt to use history.pushState() to change session history URL from file:///Users/rindlisbacher/Library/Developer/CoreSimulator/Devices/436628E4-8D12-43E4-AE7B-8FFADA02E510/data/Containers/Bundle/Application/A17AC11F-2251-4414-A5F4-C4BC7876A0B6/APPNAME.app/index.html/ to file:///Users/rindlisbacher/Library/Developer/CoreSimulator/Devices/436628E4-8D12-43E4-AE7B-8FFADA02E510/data/Containers/Bundle/Application/A17AC11F-2251-4414-A5F4-C4BC7876A0B6/APPNAME.app/index.html/dashboard. Only differences in query and fragment are allowed for file: URLs.
Since the the path must match in the URLs I have a problem.
What I have found so far:
It seems that the WebKit browser engine has a behaviour that isn't disabled anymore, if I interpret the source file (RuntimeApplicationsChecksCocoa.cpp) correctly:
if (linkedBefore(dyld_spring_2023_os_versions, DYLD_IOS_VERSION_16_4, DYLD_MACOSX_VERSION_13_3)) {
...
disableBehavior(SDKAlignedBehavior::PushStateFilePathRestriction);
...
}
So the check is executed and my routing fails.
Check on local files:
if (fullURL.isLocalFile()
#if PLATFORM(COCOA)
&& linkedOnOrAfterSDKWithBehavior(SDKAlignedBehavior::PushStateFilePathRestriction)
#endif
&& fullURL.fileSystemPath() != documentURL.fileSystemPath()) {
return createBlockedURLSecurityErrorWithMessageSuffix("Only differences in query and fragment are allowed for file: URLs.");
}
Does someone know something about that and is there a workaround or something? Maybe a configuration issue..? I couldn't find anything
macOS: 13.3.1 (22E261)
Xcode: 14.3 (14E222b)
Simulation: iPadPro (11-inch) 4th generation - iOS 16.4
Thanks in advance
José
I failed so far to return after I found a solution to our problem. Just in case anyone is still interested in a possible solution, I'll share my findings.
There is an Angular interface called NavigationBehaviourOptions that has a property called skipLocationChange. If set to true, the navigation will not push the state to history, so there is no specification violation anymore.
Documentation:
https://angulardoc.com.br/api/router/NavigationBehaviorOptions
So basically, we added this property as attribute in all the routerLink anchor elements.
To tackle the routers initial navigation there is an ExtraOption to disable that:
https://angular.io/api/router/InitialNavigation