In 2.42.1, Unity apps are failing to load. A message 'Cannot load blob... due to access control checks' appears in the JS console. Note, this was working as expected in 2.42.0. Here are two examples; all Unity apps fail for me in this way: https://www.wasm.com.cn/demo/Tanks/ [Error] Cannot load blob:https://www.wasm.com.cn/e767d7ad-3d43-4b51-a971-1edcec1c11f0 due to access control checks. decompress (UnityLoader.js:4:8819) (anonymous function) (UnityLoader.js:1:3769) https://www.cs.nccu.edu.tw/~mtchi/course/3d17/final/07/WebGL/index.html [Error] Cannot load blob:https://www.cs.nccu.edu.tw/a5d0a060-e261-47b3-81de-659a7c927393 due to access control checks. decompress (UnityLoader.js:4:9108) (anonymous function) (UnityLoader.js:1:3769)
Bisected this. Only the Safari and GTK/WPE branches are affected because this commit has not landed in main yet. a209cbf453978e3ea809d36f684a36f36ff301c5 is the first bad commit commit a209cbf453978e3ea809d36f684a36f36ff301c5 Author: Chirag M Shah <chirag_m_shah@apple.com> Date: Mon Jul 10 18:24:09 2023 -0700 Cherry-pick 265870.8@safari-7616-branch (551b1fd24102). https://bugs.webkit.org/show_bug.cgi?id=258712 Fix stack-overflow when dealing with blobURL(s) https://bugs.webkit.org/show_bug.cgi?id=258895 rdar://111440239 Reviewed by Chris Dumez. This change fixes the stack overflow when checking for whether a blobURL is secure. * Source/WebCore/fileapi/BlobURL.cpp: (WebCore::BlobURL::isSecureBlobURL): * Tools/TestWebKitAPI/Tests/WebCore/SecurityOrigin.cpp: (TestWebKitAPI::TEST_F): Canonical link: https://commits.webkit.org/265870.8@safari-7616-branch Source/WebCore/fileapi/BlobURL.cpp | 3 ++- Tools/TestWebKitAPI/Tests/WebCore/SecurityOrigin.cpp | 6 ++++++ 2 files changed, 8 insertions(+), 1 deletion(-)
The culprit has shipped in Safari 17, and I cannot reproduce the issue there. So the regression must be Gtk specific?
Strange, but I've seen stranger....
It's more likely to be branch-specific rather than port-specific. Likely we're either (a) missing some other unknown but required change from safari-7616-branch, or (b) more likely the change is incompatible with some other unknown change on main. We'll be able to find out after this change has landed in main.
(In reply to Michael Catanzaro from comment #4) > It's more likely to be branch-specific rather than port-specific. Likely > we're either (a) missing some other unknown but required change from > safari-7616-branch, or (b) more likely the change is incompatible with some > other unknown change on main. > > We'll be able to find out after this change has landed in main. I think it is likely the branch change is incompatible with some changes that were done on trunk. I haven't had time to investigate yet though.
(In reply to Chris Dumez from comment #5) > (In reply to Michael Catanzaro from comment #4) > > It's more likely to be branch-specific rather than port-specific. Likely > > we're either (a) missing some other unknown but required change from > > safari-7616-branch, or (b) more likely the change is incompatible with some > > other unknown change on main. > > > > We'll be able to find out after this change has landed in main. > > I think it is likely the branch change is incompatible with some changes > that were done on trunk. I haven't had time to investigate yet though. See https://github.com/WebKit/WebKit/pull/18859
Reverted this on webkitglib/2.42 branch. Closing. I'm guessing 266247@main was the commit that fixed the stack overflow on main, though I'm not certain.
<rdar://problem/116756393>
*** Bug 264263 has been marked as a duplicate of this bug. ***
*** Bug 264201 has been marked as a duplicate of this bug. ***