You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've built an ionic/angular application that includes an ion-icon on an HTML page. I don't think that Angular is significant, that's just what I was working with.
The application is built to be displayed from a file:// URL. The application is built, bundled into an iOS application and then displayed in a WKWebView directly from the file system (no server).
Because of a bad interaction between Safari on the iOS device, and some code in the ionicons source, the icons will no display.
I have reproduced the issue on MacOS using Safari in that environment too.
Expected Behavior
I would expect the icon to display. The content (the svg file) is successfully loaded by the browser, but that success is ot reported to ionicons in the expected way.
I am using a MacBook Pro running MacOS 13.6.1 (Ventura) and Safari Version 17.1 (18616.2.9.11.9, 18616).
For iOS I am using iOS 17 with whatever version of Safari I has. This is probably easier to demonstrate on a laptop as to demonstrate it on iOS you need an application to host the web site.
From the repo above, I build the application with the command yarn run build --configuration development. The result is placed in the www folder. From there open the www/index.html file.
I expect this page to show a very large instance of the "star" ionicon. It does not display.
The fundamental problem is an interaction between the way safari treats a file URL through the browser's fetch(url) call and code in ionicons. When getting to the svg file for the icon, ionicons runs this code:
// we don't already have a request
req = fetch(url).then((rsp) => {
if (rsp.ok) {
return rsp.text().then((svgContent) => {
if (svgContent && sanitize !== false) {
svgContent = validateContent(svgContent);
}
ioniconContent.set(url, svgContent || '');
});
}
ioniconContent.set(url, '');
});
The URL that "fetch" is presented with will be something like: file:///Users/sthompson/Projects/TempPlaygrounds/some_app/www/svg/star.svg
Safari will fetch the file, but it returns a status code of 0 instead of a 200:
The file has been successfully downloaded, but the ionicons code is checking "rsp.ok". The Response's ok property tells you if the status code is in the range 200-299 and Safari's response of 0 is clearly not in that range. So ionicons doesn't even try to get the content back from the request. However, if you go ahead and try to access rsp.text() the data will be there.
The status code of 0 may be a bug in Safari. But it is possible to work around that bug. I got it to work by modifying my local copy to ignore the "rsp.ok" property, check, access the text() for the request, and I added a .catch to handle failure cases. Perhaps doing that only in the case that the resonse status is 0 would be an even narrower fix.
Will work around the issue because the svg files are loaded from the web. However our application is designed to be used in environments where the user may not have access to the internet (say on a ship under-way at sea). So having access to the icon images from the file system is important.
The text was updated successfully, but these errors were encountered:
Current Behavior
I've built an ionic/angular application that includes an ion-icon on an HTML page. I don't think that Angular is significant, that's just what I was working with.
The application is built to be displayed from a file:// URL. The application is built, bundled into an iOS application and then displayed in a WKWebView directly from the file system (no server).
Because of a bad interaction between Safari on the iOS device, and some code in the ionicons source, the icons will no display.
I have reproduced the issue on MacOS using Safari in that environment too.
Expected Behavior
I would expect the icon to display. The content (the svg file) is successfully loaded by the browser, but that success is ot reported to ionicons in the expected way.
Steps to Reproduce
I built an application sample in this repo: https://github.com/sthompson-crestron/ionicon_missing
I am using a MacBook Pro running MacOS 13.6.1 (Ventura) and Safari Version 17.1 (18616.2.9.11.9, 18616).
For iOS I am using iOS 17 with whatever version of Safari I has. This is probably easier to demonstrate on a laptop as to demonstrate it on iOS you need an application to host the web site.
From the repo above, I build the application with the command
yarn run build --configuration development
. The result is placed in thewww
folder. From there open thewww/index.html
file.I expect this page to show a very large instance of the "star" ionicon. It does not display.
Code Reproduction URL
https://github.com/sthompson-crestron/ionicon_missing
Additional Information
The fundamental problem is an interaction between the way safari treats a file URL through the browser's
fetch(url)
call and code in ionicons. When getting to the svg file for the icon, ionicons runs this code:The URL that "fetch" is presented with will be something like:
file:///Users/sthompson/Projects/TempPlaygrounds/some_app/www/svg/star.svg
Safari will fetch the file, but it returns a status code of 0 instead of a 200:
The file has been successfully downloaded, but the ionicons code is checking "rsp.ok". The Response's
ok
property tells you if the status code is in the range 200-299 and Safari's response of0
is clearly not in that range. So ionicons doesn't even try to get the content back from the request. However, if you go ahead and try to accessrsp.text()
the data will be there.The status code of 0 may be a bug in Safari. But it is possible to work around that bug. I got it to work by modifying my local copy to ignore the "rsp.ok" property, check, access the
text()
for the request, and I added a.catch
to handle failure cases. Perhaps doing that only in the case that the resonse status is 0 would be an even narrower fix.Including the script from the usage page:
Will work around the issue because the svg files are loaded from the web. However our application is designed to be used in environments where the user may not have access to the internet (say on a ship under-way at sea). So having access to the icon images from the file system is important.
The text was updated successfully, but these errors were encountered: