Enable web views and services in your apps.

All subtopics

Post

Replies

Boosts

Views

Activity

Error accessing webkitSpeechRecognition() in my pwa application
I use the Vue.js 3 language, together with Typescript, I created a pwa application and I want to create a voice button, but when I use this button created in my safari it works, when I add my application to the IOS home screen, it no longer works, I tested it with different versions of Ios. an example of my code: <template> <div class="app-container"> <span @touchstart="startRecording" @touchend="stopRecording" class="no-select microphone-button" > <el-icon :style="{ transform: isActive ? 'scale(2.3)' : 'scale(1.5)' }" id="microphone-button-margin"> <Microphone /> <span v-if="isActive" class="recording-indicator" /> </el-icon> </span> <p>Texto Reconhecido: {{ recognizedText }}</p> </div> </template> <script setup lang="ts"> const recognizedText=ref('') let recognition: any=null const isActive=ref(false) onMounted(() => { recognition = new (window as any).webkitSpeechRecognition() }) const startRecording = () => { isActive.value = true recognition.lang = 'pt-BR' recognition.continuous = false ElMessage.error('Start') recognition.onresult = (event: { results: { transcript: any }[][] }) => { ElMessage.success(event.results[0][0].transcript) const transcript = event.results[0][0].transcript recognizedText.value = transcript } recognition.start() } const stopRecording = () => { isActive.value = false ElMessage.error('Stop') if (recognition) { recognition.stop() } } </script> link code: [https://element-plus.run/#eyJzcmMvQXBwLnZ1ZSI6IjxzY3JpcHQgc2V0dXAgbGFuZz1cInRzXCI+XG5pbXBvcnQgeyByZWYsIHZlcnNpb24gYXMgdnVlVmVyc2lvbiwgb25Nb3VudGVkIH0gZnJvbSAndnVlJ1xuaW1wb3J0IHsgdmVyc2lvbiBhcyBlcFZlcnNpb24sIEVsTWVzc2FnZSB9IGZyb20gJ2VsZW1lbnQtcGx1cydcbmltcG9ydCB7IE1pY3JvcGhvbmUgfSBmcm9tICdAZWxlbWVudC1wbHVzL2ljb25zLXZ1ZSdcblxuY29uc3QgcmVjb2duaXplZFRleHQ9cmVmKCcnKVxubGV0IHJlY29nbml0aW9uOiBhbnk9bnVsbFxuY29uc3QgaXNBY3RpdmU9cmVmKGZhbHNlKVxuXG5vbk1vdW50ZWQoKCkgPT4ge1xuICByZWNvZ25pdGlvbiA9IG5ldyAod2luZG93IGFzIGFueSkud2Via2l0U3BlZWNoUmVjb2duaXRpb24oKVxufSlcblxuY29uc3Qgc3RhcnRSZWNvcmRpbmcgPSAoKSA9PiB7XG4gaXNBY3RpdmUudmFsdWUgPSB0cnVlXG4gIHJlY29nbml0aW9uLmxhbmcgPSAncHQtQlInXG4gIHJlY29nbml0aW9uLmNvbnRpbnVvdXMgPSBmYWxzZVxuICBFbE1lc3NhZ2UuZXJyb3IoJ1N0YXJ0JylcbiAgcmVjb2duaXRpb24ub25yZXN1bHQgPSAoZXZlbnQ6IHsgcmVzdWx0czogeyB0cmFuc2NyaXB0OiBhbnkgfVtdW10gfSkgPT4ge1xuICAgIEVsTWVzc2FnZS5zdWNjZXNzKGV2ZW50LnJlc3VsdHNbMF1***0udHJhbnNjcmlwdClcbiAgICBjb25zdCB0cmFuc2NyaXB0ID0gZXZlbnQucmVzdWx0c1swXVswXS50cmFuc2NyaXB0XG4gICAgcmVjb2duaXplZFRleHQudmFsdWUgPSB0cmFuc2NyaXB0XG4gIH1cbiAgcmVjb2duaXRpb24uc3RhcnQoKVxufVxuY29uc3Qgc3RvcFJlY29yZGluZyA9ICgpID0+IHtcbiAgaXNBY3RpdmUudmFsdWUgPSBmYWxzZVxuICBFbE1lc3NhZ2UuZXJyb3IoJ1N0b3AnKVxuICBpZiAocmVjb2duaXRpb24pIHtcbiAgICByZWNvZ25pdGlvbi5zdG9wKClcbiAgfVxufVxuXG48L3NjcmlwdD5cblxuPHRlbXBsYXRlPlxuICA8ZGl2IGNsYXNzPVwiYXBwLWNvbnRhaW5lclwiPlxuICAgIDxlbC1jYXJkPlxuICAgICAgPGVsLXJvdyA6Z3V0dGVyPVwiNVwiPlxuICAgICAgICA8ZWwtY29sIDp4cz1cIjI0XCIgOnNtPVwiMjRcIiA6bWQ9XCIyNFwiIDpsZz1cIjI0XCIgOnhsPVwiMjRcIiBzdHlsZT1cIm1hcmdpbi10b3A6IDE1cHhcIj5cbiAgICAgICAgICA8c3BhblxuICAgICAgICAgICAgQHRvdWNoc3RhcnQ9XCJzdGFydFJlY29yZGluZ1wiXG4gICAgICAgICAgICBAdG91Y2hlbmQ9XCJzdG9wUmVjb3JkaW5nXCJcbiAgICAgICAgICAgIGNsYXNzPVwibm8tc2VsZWN0IG1pY3JvcGhvbmUtYnV0dG9uXCJcbiAgICAgICAgICA+XG4gICAgICAgICAgICA8ZWwtaWNvbiA6c3R5bGU9XCJ7IHRyYW5zZm9ybTogaXNBY3RpdmUgPyAnc2NhbGUoMi4zKScgOiAnc2NhbGUoMS41KScgfVwiIGlkPVwibWljcm9waG9uZS1idXR0b24tbWFyZ2luXCI+XG4gICAgICAgICAgICAgIDxNaWNyb3Bob25lIC8+XG4gICAgICAgICAgICAgIDxzcGFuIHYtaWY9XCJpc0FjdGl2ZVwiIGNsYXNzPVwicmVjb3JkaW5nLWluZGljYXRvclwiIC8+XG4gICAgICAgICAgICA8L2VsLWljb24+XG4gICAgICAgICAgPC9zcGFuPlxuICAgICAgICAgIDxwPlRleHRvIFJlY29uaGVjaWRvOiB7eyByZWNvZ25pemVkVGV4dCB9fTwvcD5cbiAgICAgICAgPC9lbC1jb2w+XG4gICAgICA8L2VsLXJvdz5cbiAgICA8L2VsLWNhcmQ+XG4gIDwvZGl2PlxuPC90ZW1wbGF0ZT5cblxuPHN0eWxlIHNldHVwPlxuLm5vLXNlbGVjdCB7XG4gIC13ZWJraXQtdXNlci1zZWxlY3Q6IG5vbmU7IC8qIFNhZmFyaSAqL1xuICAtbW96LXVzZXItc2VsZWN0OiBub25lOyAgLyogRmlyZWZveCAqL1xuICAtbXMtdXNlci1zZWxlY3Q6IG5vbmU7ICAvKiBJRSAxMCsgICovXG4gICB1c2VyLXNlbGVjdDogbm9uZTsgICAvKiBTdGFuZGFyZCAqL1xufVxuLm1pY3JvcGhvbmUtYnV0dG9uIHtcbiAgdGV4dC1hbGlnbjogY2VudGVyO1xuICBwb3NpdGlvbjogcmVsYXRpdmU7XG4gIGRpc3BsYXk6IGJsb2NrO1xuICBoZWlnaHQ6IDMwcHg7XG4gIHdpZHRoOiA0MHB4O1xufVxuLnJlY29yZGluZy1pbmRpY2F0b3Ige1xuICBwb3NpdGlvbjogYWJzb2x1dGU7XG4gIHRvcDogLTVweDtcbiAgcmlnaHQ6IDEycHg7XG4gIHdpZHRoOiA3cHg7XG4gIGhlaWdodDogN3B4O1xuICBiYWNrZ3JvdW5kLWNvbG9yOiByZWQ7XG4gIGJvcmRlci1yYWRpdXM6IDUwJVxufVxuPC9zdHlsZT5cbiIsImltcG9ydC1tYXAuanNvbiI6IntcbiAgXCJpbXBvcnRzXCI6IHt9XG59IiwidHNjb25maWcuanNvbiI6IntcbiAgXCJjb21waWxlck9wdGlvbnNcIjoge1xuICAgIFwidGFyZ2V0XCI6IFwiRVNOZXh0XCIsXG4gICAgXCJqc3hcIjogXCJwcmVzZXJ2ZVwiLFxuICAgIFwibW9kdWxlXCI6IFwiRVNOZXh0XCIsXG4gICAgXCJtb2R1bGVSZXNvbHV0aW9uXCI6IFwiQnVuZGxlclwiLFxuICAgIFwidHlwZXNcIjogW1wiZWxlbWVudC1wbHVzL2dsb2JhbC5kLnRzXCJdLFxuICAgIFwiYWxsb3dJbXBvcnRpbmdUc0V4dGVuc2lvbnNcIjogdHJ1ZSxcbiAgICBcImFsbG93SnNcIjogdHJ1ZSxcbiAgICBcImNoZWNrSnNcIjogdHJ1ZVxuICB9LFxuICBcInZ1ZUNvbXBpbGVyT3B0aW9uc1wiOiB7XG4gICAgXCJ0YXJnZXRcIjogMy4zXG4gIH1cbn1cbiIsIl9vIjp7fX0=) Can anyone help me in this case? I don't know what I could be doing wrong and I also did a lot of research and didn't see anything to help me.
0
0
668
Mar ’24
WebGPU for IPAD
It is 2024. WebGPU has been available for Safari on desktops since December of last year, as well as other browsers for quite some time. It's about time it was made available on the IPAD; at the very least as an advanced feature. WebGPU provides many opportunities to create compelling experiences in other browsers on different device, but not in the Safari browser for IPAD users. I bought an IPAD a few years ago, but the lack of ability and sub-par software, is one of the reasons I can't justify buying another, and many students feel this way. I know so many that are still buying android and surface pros because we are being held back from both creating and consuming newly possible web experiences when we use IOS devices. There are quite a few other things we need, such as a proper set of dev tools, even just for the browser, but webGPU is a must in order to stay competitive. Students who bought IPADs for school and for development need to be allowed to keep up with those using other platforms. Machine Learning, Signal processing, image processing, anything could benefit from compute shaders and uniforms... massive number crunching capability is a must going forward in the web, and those with IPADs need to be allowed to take part. More capabilities will equal more sales.
2
0
2.1k
Mar ’24
SFSafariViewController will sometimes ignore redirects to non-https URLs if no user interaction occurs
We have a payment process in an app which involves loading up a Web page to allow a user to enter credit card details, and to complete a transaction. This web page may result in a 3D-Secure step up challenge. For PCI compliance purposes we launch this in a SFSafariViewController. This 3D secure process involves a collection of redirects, with a final one back to us known as the "Merchant Page". In here, we want to do one more redirect, using a custom URL scheme, to allow the app to recognise that the process has completed, and can safely dismiss the SFSafariViewController. In those cases where no "step up 3d challenge" occurs, the process works well, the final redirect occurs, and our app successfully dismisses the SFSafariViewController. However, in a step up challenge, the Merchant Page loads, but any attempt to do the final custom redirect does not execute. I believe this is a feature of Safari - What I think is going on is that enough time has passed since there was user interaction on the page, and the final redirect, which isn't a https or http link (it is a myapp:// link) simply gets ignored. We've tried a lot of things. One thing works: If we provide a button, and when it is tapped, it sets window.location.href = 'myapp://success?', this works. This is a clue to if it is cause by lack of user interaction. We've tried lots of things: Rather than a javascript redirect, we tried server side redirecting; we tried all of the HTTP 300 response codes. They were all ignored We tried the meta refresh (which we know is kinda deprecated). We tried window.location.href = , window.location.assign(), document.location.href, document.location.assig(), etc. We tried issuing an Ajax XMLHttpRequest, but this failed because it isn't https or http We even tried to suggest our non-standard URL was the source of a script, just to trigger it but it didn't work. We've tried calling in during body onload We've tried calling it using a timeout in case timing was relevant. My gut feeling here is this is a feature. I've used Safari Debugging, and it literally steps over the window.location.href assignment, and doesn't produce a warning or an error. We've added try/catch, and no exception was thrown. Again, it leads me to believe this is all by design (perhaps to prevent ad fraud or something?). I was kinda hoping that in the response, we'd be able to specify a CORS header that tells the browser that "it will be ok to use resources from myapp://", but haven't found the right one. We may end up having to simply produce a button with a message "Your transaction has completed, please press here to dismiss", but it is terrible UX that is unnecessary. I've seen a number of posts elsewhere suggesting that redirects without user interaction can be considered suspicious, and I've experience of this same problem on another browser. If anyone has cracked this one, I'd love to know how
1
0
777
Mar ’24
domToImage JS library not working well on iPhone and Mac
I have a problem with the JS library 'dom-to-image', This JavaScript library converts a div to an image, but it's not working well on iPhone and Mac devices. Sometimes it doesn't work at all, and other times I need to download the image multiple times for it to work. I understand that Mac/iPhone devices have different rendering logic, but is there a way to check what the problem is and how to fix it? I tried dom-to-image-more and some delay but still not working. Thank you!
0
0
594
Mar ’24
WKWebView cookies management
Problem statement- WKWebView cookies management. We need to clone the connection used by the WKWebView to the same end point, this connection utilize cookies for routing and missing even one the cookies will end up with a wrong route to be used. It appears that when retrieving the cookies from the WKWebView connection some cookies are missing. From some analysis seems that the missing cookies all have in common a value containing special characters. The question for Apple is if they are going to relax the constraint on cookies value to allow such cookies to be used. Technical Description:- We are using WKWebView. There are some cookies being set during server connection. We are retrieving all cookies using 'getAllCookies' method of WKWebview. Sometime its not giving correct set of cookies in case if there are any special characters in any cookie. For example - Cookie- ss2QKagAdkAV3My1pnKElaFDnQ6lxhgqNbD03IaRbX6WfDz2+P9dT6DdlK8G5WIH3svEATnehZSmWGQ3QFTnew==\n It contains special character "+ = !".
1
0
540
Mar ’24
Failed to load resource: The request timed out after iOS 17.0 update
Subject: Apple Developer Ticket: Issue with Web Page Loading Timeout after iOS 17.0 Update Description: I am writing to report an issue that arose after the recent iOS update to version 17.0. Since the update, users accessing our web page via Chrome and Safari browsers on iOS 17.0 and later are experiencing loading timeouts. Problem Details: Issue: Failed to load resource due to request timeout. Affected Browsers: Chrome and Safari on iOS 17.0 and later. Working Versions: The web page functions correctly on iOS versions 16.1 to 16.4. Web Page Content: The web page includes JavaScript and Ajax calls. Steps to Reproduce: Access the web page using Chrome or Safari browser on iOS 17.0 or later. Observe the loading timeout error. Additional Information: The issue seems to be related to a change in the way iOS 17.0 handles JavaScript and Ajax calls. We have tested the web page on multiple devices running iOS 17.0 and encountered the same problem consistently. No changes were made to the web page's codebase prior to the iOS update. Expected Resolution: We kindly request Apple's assistance in identifying and resolving the root cause of this issue. Our aim is to ensure compatibility with the latest iOS versions and provide a seamless user experience for our customers. Thank you for your prompt attention to this matter. Please let us know if you require any further information or assistance from our end.
0
0
660
Feb ’24
Will Capacitor-Wrapped PWA Custom Apps work offline in IOS 17.4 - and what about maintaining multiple versions?
Scenario: Apple decided to not support PWAs in Europe in IOS 17.4. My company has multiple Angular PWAs, all using IndexedDB and providing full offline-usage as main feature, that apparently won't work anymore. The apps communicate with a server. We maintain two versions of that server, e.g. v1.1 and v1.2 - some customers don't want or can't upgrade to v1.2 just yet. Not all new features of an app will get implemented in v1.1, and eventually we won't push updates for it anymore. At some point, we'll have the same situation with e.g. v1.2 and v1.3. My questions: Do I understand correctly that offline-usage and IndexedDB features won't work anymore? If I wrap the PWAs via Capacitor and upload them as Custom App via App Store Connect, in IOS 17.4... Will the app, including routing, work offline? Will the IndexedDb still be usable as permanent data storage? Can I upload v1.1 and v1.2 as separate apps or will I have to create on app with in-app purchase options? If it's the latter, how do I push updates? Apparently, Apple Review can cause problems with separate apps that have similar functions... Thank you for your time!
0
0
728
Feb ’24
Europa : PWA or A2HS in standalone no longer works
Hello, since the last iOS 17.4 Europe update, and since the implementation of new rules for default browsers, PWAs no longer work. In fact, they are nothing more than shortcuts for internet pages, so this makes the application unusable, which could not necessarily be launched in install mode with notifications. I tried looking for changes but couldn't find them. I think it's linked to the fact that you can install applications from the web from a marketplace. If anyone has a solution or the same problem. Thank you
22
10
7.2k
Jan ’24
Safari(>17) in Private mode strips GET query parameters from window.location
In Safari 17's private mode, an inconsistent behaviour has been observed where GET query parameters are stripped from window.location after following user's click on any link with GET query parameters. The issue is reproducible for any link with GET query parameters. This issue varies; in some cases, the parameters remain visible in the URL, while in others, they are removed. (The window.location is always stripped of the query parameters). This behaviour impacts both iOS and MacOS users, suggesting a broader issue with Safari's treatment of URL parameters in private mode. The issue is not reproducible on both Safari < 17 and Safari 17 in Normal mode. Most probably it is the result of adding Advanced Tracking and Fingerprinting Protection in Safari 17. Can you please clarify logic behind Advanced Tracking and Fingerprinting Protection? Is it an expected behaviour?
1
0
939
Feb ’24