Explore the integration of web technologies within your app. Discuss building web-based apps, leveraging Safari functionalities, and integrating with web services.

All subtopics
Posts under Safari & Web topic

Post

Replies

Boosts

Views

Activity

Apple Calculator
Hello. I'm using Sololearn and ChatGPT to learn how to code. I've made a calculator before, but I want to make one similar to the one on iPhone. Is ok to have a link to apple.com or do I say I was inspired by Apple Here is the code I currently have: HTML <!DOCTYPE html><html> <head> <title>Page Title</title> <meta name="viewport" content="width=device-width, initial-scale=1"> </head> <body> <div class="calculator"> <input class="display" type="text"> <div class = "scientific"> <button>(</button> <button>)</button> <button>mc</button> <button>m+</button> <button>m-</button> <button>mr</button> </div> <div class ="standard"> <button class="utility" id="backspace">&#9003;</button> <button class="utility" id="clear">AC</button> <button class="utility" id="percent">%</button> <button class="operator">/</button> <button class="number digit">7</button> <button class="number digit">8</button> <button class="number digit">9</button> <button class="operator">*</button> <button class="number digit">4</button> <button class="number digit">5</button> <button class="number digit">6</button> <button class="operator">-</button> <button class="number digit">1</button> <button class="number digit">2</button> <button class="number digit">3</button> <button class="operator">+</button> <button class="number" id="plusmn"><sup>+</sup>&frasl;<sub>-</sub></button> <button class="number digit">0</button> <button class="number" id="decimal">.</button> <button class="utility equals" id="equals">=</button> </div> </div> </body></html> ``` ``` CSSbody{ background-color: black; } html, body { margin: 0; width: 100%; height: 100%; background-color: black; } input { font-size: 48px; box-sizing: border-box; width: 100%;} .utility { background-color: #666; color: white; } .operator { background-color: orange; color: white; } .equals{ background-color: orange; color: white; } .number{ background-color: #333; color: white; } .calculator { display: grid; /*grid-template-columns: repeat(4, 1fr);*/ grid-template-columns: 1fr; gap: 4px; width: 100%; box-sizing: border-box; padding: 12px; position: fixed; bottom: 0; left: 0;} .calculator button { width: 100%; aspect-ratio: 1; border: none; border-radius: 50%; font-size: 32px; } .scientific{ display: grid; grid-template-columns: repeat(6, 1fr); gap: 4px;} .standard{ display: grid; grid-template-columns: repeat(4, 1fr); gap: 4px;} .display { color: white; background-color: black; border: none; height: 100px; font-size: 48px; text-align: right; box-sizing: border-box; width: 100%; } /* .display { grid-column: 1 / -1; color: white; background-color: black; border: none; height: 100px; font-size: 48px; text-align: right; box-sizing: border-box; width: 100%; } */ /* .zero { grid-column: span 2; border-radius: 40px; aspect-ratio: auto;} .calculator button.zero { aspect-ratio: auto; border-radius: 40px;} */ JS const display = document.querySelector(".display"); let fontSize = 48; function adjustFontSize() { fontSize = 48 - display.value.length * .99; if (fontSize < 20) { fontSize = 20; } display.style.fontSize = fontSize + "px"; } const buttonsJS = document.querySelectorAll(".digit"); buttonsJS.forEach(function(buttonJS) { buttonJS.addEventListener("click", function() { display.value += buttonJS.textContent; adjustFontSize(); }); }); const clear = document.querySelector("#clear"); clear.addEventListener("click", function() { display.value = ""; adjustFontSize(); }); const backspace = document.querySelector("#backspace"); backspace.addEventListener("click", function() { display.value = display.value.slice (0, -1); adjustFontSize(); }); const percent = document.querySelector("#percent"); percent.addEventListener("click", function(){ display.value /= 100; adjustFontSize(); }); const plusmn = document.querySelector("#plusmn"); plusmn.addEventListener("click", function(){ display.value /= -1; adjustFontSize(); }); const decimal = document.querySelector("#decimal"); decimal.addEventListener("click", function(){ if (!display.value.includes(".")) { display.value += "."; // Add the decimal point here } adjustFontSize();}); const operators = document.querySelectorAll(".operator"); operators.forEach(function(operator) { operator.addEventListener("click", function() { display.value += operator.textContent; adjustFontSize(); }); }); const equals = document.querySelector("#equals"); equals.addEventListener("click", function() { display.value = eval(display.value); adjustFontSize(); }); /* const display = document.querySelector(".display"); const buttonJS = document.querySelector(".digit"); buttonJS.addEventListener("click", function() { console.log("You clicked the button!"); }); const buttonsJS = document.querySelectorAll(".digit"); buttonsJS.forEach(function(buttonJS) { buttonJS.addEventListener("click", function() { display.value += buttonJS.textContent; }); }); */
1
0
828
1w
Safari shows “Fraudulent Website Warning” for q-saver.com for over 5 months despite repeated Website Review requests
Safari displays a red “Fraudulent Website Warning” for my website q-saver.com. The warning has been present for more than 5 months. I have already submitted two requests through https://websitereview.apple.com/, but neither resulted in the warning being removed or any response. The website is a video downloading service. It does not impersonate Apple or financial services and does not ask for Apple IDs, banking credentials or other sensitive information. The only password it asks for is the optional password of a q-saver.com account; sign-in with Google or Telegram goes through their official OAuth pages, and payments are processed on the payment providers' own pages. The site used to show pop-under ads from third-party ad networks. They have been turned off (the last one on September 26, 2026), and the ad network code has been removed from the pages. On 27 September I submitted a new Website Review request. Google Safe Browsing reports no unsafe content for the site: https://transparencyreport.google.com/safe-browsing/search?url=q-saver.com The website works normally in Chrome, Firefox and Edge. In iOS in-app browsers (for example, Telegram) it does not open at all because of the warning. Is there an official escalation path for Safari's Fraudulent Website Warning classification when Website Review requests remain unresolved for several months? I can provide screenshots and technical information privately if required.
2
0
2.3k
1w
Apple Pay on the Web sheet fails with PKPaymentAuthorizationStateFatalError after successful merchant validation (PROD trust policy)
Environment macOS 26.5.1 (Build 25F80) Safari 26.5 Apple Pay JS API version 8 Using https://applepay.cdn-apple.com/jsapi/v1/apple-pay-sdk.js Reproduces on the staging website (Does not reproduce on the production website with non sandbox account) Signed into a Sandbox Tester Apple ID, with a test credit card registered exactly per Apple Pay Sandbox Testing — this is the only card in Wallet on the laptop Merchant validation is performed by our staging backend against our real (non-sandbox) merchant identity/certificate — i.e. a sandbox tester card being evaluated against a staging merchant session, which per the sandbox testing documentation is the expected/supported setup for testing on a live site without a separate merchant sandbox environment Summary After completeMerchantValidation() succeeds and the merchant session is accepted, the payment sheet still terminates with PKPaymentAuthorizationStateFatalError a few hundred milliseconds later, right after the native side logs a second "Evaluating merchant session using PROD trust policy." for the same session. The user sees "Payment failed" and the sheet closes. This happens on the very first attempt, with no user interaction beyond tapping the Apple Pay button — no shipping address is even selected before the failure. Since the sandbox tester card + production merchant session combination is the setup the sandbox testing guide describes, we'd expect the sheet to proceed to onpaymentauthorized (Apple's sandbox docs describe payments as being processed as $0 test transactions in this mode) rather than fail natively before that stage is ever reached. Steps to reproduce Visit an item page with an Apple Pay button. Tap the Apple Pay button to open the payment sheet. The sheet presents normally; no interaction with shipping address or payment method is required for the failure to occur. Within ~1 second, the sheet dismisses and displays a "Payment failed" error state. Minimal reproduction of the JS side const session = new ApplePaySession(8, { countryCode: 'US', currencyCode: 'USD', supportedNetworks: ['visa', 'masterCard', 'amex', 'discover'], merchantCapabilities: ['supports3DS'], total: { label: 'Merchant', amount: '10.00' }, }); session.onvalidatemerchant = async () => { const merchantSession = await validateMerchantOnServer(); // succeeds session.completeMerchantValidation(merchantSession); // accepted — see log below }; session.onpaymentmethodselected = () => { session.completePaymentMethodSelection({ newTotal: { label: 'Merchant', amount: '10.00' }, }); }; session.oncancel = event => console.log('cancelled', event); session.begin(); We reproduced this with both our full checkout implementation and this stripped-down request object (no shipping contact required, no line items) — same failure either way, which rules out anything about our order/line-item data. What we expected The sheet to proceed to the biometric authorization step and dispatch onpaymentauthorized once the user confirms. What actually happens The sheet fails immediately with a PKPaymentAuthorizationStateFatalError transition, even though every JS-side completion call (completeMerchantValidation, the payment-method selection) succeeded and returned PKPaymentAuthorizationStatusSuccess. System log (captured via log stream --info --debug --predicate 'process == "Safari" OR process == "passd" OR process == "com.apple.PassKit.PaymentAuthorizationUIExtension"') 21:50:41.544 PaymentCoordinator::beginPaymentSession() -> 1 21:50:41.570 Received prepareWithPaymentRequest: <private> 21:50:42.297 PaymentCoordinator::validateMerchant() 21:50:42.563 PaymentCoordinator::completeMerchantValidation() 21:50:42.564 Received merchant session update with status:PKPaymentAuthorizationStatusSuccess session:<private> 21:50:42.564 Evaluating merchant session using PROD trust policy. <- 1st occurrence, passes 21:50:42.572 PaymentCoordinator::didSelectPaymentMethod() 21:50:42.572 PaymentCoordinator::completePaymentMethodSelection() 21:50:42.653 Evaluating merchant session using PROD trust policy. <- 2nd occurrence 21:50:42.656 State machine change state from ClientCallback to PrepareTransactionDetails with param: <private> 21:50:43.391 Task Completed: <private> 21:50:43.393 State machine change state from PrepareTransactionDetails to PKPaymentAuthorizationStateFatalError with param: <private> 21:50:43.393 Error Payment failed with fatal error <private> 21:50:45.130 PaymentCoordinator::didCancelPaymentSession() The first "Evaluating merchant session using PROD trust policy." line passes (the flow continues to didSelectPaymentMethod). The second occurrence is immediately followed by Task Completed and then the FatalError transition, which suggests PassKit re-validates the merchant session's trust a second time right before PrepareTransactionDetails, and that second check is what's rejecting the session — even though the identical session object was accepted moments earlier at completeMerchantValidation(). What we've tried / ruled out Confirmed every JS completion method (completeMerchantValidation, completePaymentMethodSelection) is called and returns success — no 30-second timeout, no missing completion call, no thrown exception on our side. Reproduced with a minimal, hardcoded ApplePayPaymentRequest (fixed $10.00 total, no shipping fields) — rules out anything about our real order/line-item/sales-tax data. Reproduced on the main branch and independently on our staging deployment running unmodified code — rules out anything specific to our recent frontend changes. The <private> redaction in the system log prevents us from seeing what specifically fails during the second trust evaluation. Confirmed the sandbox tester card and its registration follow the sandbox testing guide exactly — it's the only card on the device, and no other Wallet cards are involved. Question What does PassKit's second "Evaluating merchant session using PROD trust policy" check (immediately before PrepareTransactionDetails) actually validate, beyond what's already checked at completeMerchantValidation() time? Is a sandbox tester card being evaluated against a production merchant session expected to pass this second check, or does sandbox testing per the linked guide require something additional on the merchant/session side (e.g. a specific field on the merchant session, or a specific environment value) that our backend isn't setting? Is there a way to get an unredacted reason for the rejection — e.g. via a private-data-enabled log profile or another diagnostic — since the redacted system log alone doesn't surface one?
3
0
3.2k
1w
White flash when opening a new tab overridden by a Safari Web Extension on iOS
White flash when opening a new tab overridden by a Safari Web Extension on iOS Safari intermittently displays a white flash when opening a new tab overridden by a web extension. I reproduced this on an iPhone 13 mini running iOS 26.5 using a minimal test extension. Minimal reproduction The extension replaces the new tab page through chrome_url_overrides.newtab. The page has a static magenta background, set directly on the root element and through inline CSS. The test page contains no JavaScript, images, fonts, external stylesheets or network requests. Steps to reproduce Install and enable a Safari Web Extension that overrides the new tab page with a static magenta HTML page. Select the extension for new tabs in Safari settings. Open Safari in normal browsing mode. Open a new tab and wait for the magenta page to appear. Open another new tab. Repeat several times. Expected: The page area remains magenta throughout the transition. Actual: The page area intermittently transitions from magenta → white → magenta. The issue reproduces without JavaScript or external resources, so the flash does not require delayed script execution or image loading. Is this a known issue with Safari’s handling of new tab overrides? Is there a supported way for an extension to control the background displayed during this transition?
2
0
715
1w
Safari and Safari Technology Preview intermittently ignore clicks near bottom of webpage on macOS 27 Beta
Environment: MacBook Air M4 macOS 27 Beta Safari Safari Technology Preview Issue: I am experiencing an issue where mouse/trackpad clicks are intermittently ignored near the bottom portion of a webpage. The trackpad hardware appears to be functioning normally, as physical clicks are registered and the issue does not occur consistently across all browsers. Steps to Reproduce: Open Safari or Safari Technology Preview. Navigate to a webpage with interactive elements near the bottom of the visible page. Attempt to click links, buttons, or text fields located in approximately the bottom quarter of the browser window. Observe that clicks are sometimes not registered. Resize the Safari window so that the affected area is no longer located in the bottom portion of the screen. Attempt the same clicks again. Expected Result: Clicks should be consistently registered regardless of their position within the webpage. Actual Result: Clicks in the lower portion of the webpage are sometimes ignored. Resizing the window may temporarily resolve the issue. Additional Information: The trackpad itself appears to function normally. Physical clicks are detected. I have observed the issue in both Safari and Safari Technology Preview. I tested the same website in Perplexity Comet, where the issue does not appear to occur. This suggests the issue may be related to Safari’s rendering, hit-testing, event handling, or window management rather than the website itself. Has anyone else been able to reproduce this on macOS 27 Beta?
1
1
1.8k
1w
Disabling HTTP/2 in Safari
Hi, I’m testing file uploads to a web app that sits behind an AWS Application Load Balancer, and I need a way to make Safari use HTTP/1.1 instead of HTTP/2 while I test. What I’m seeing: Uploads up to about 4 MB work. Anything bigger slows down more and more and then fails with a network error. A 49 MB file never finishes. The same upload over HTTP/1.1 works every time. I tested this with curl (--http1.1 against --http2), and with Chrome started with --disable-http2. In that Chrome, the 49 MB file uploaded fine. In Safari, which uses HTTP/2 with this server, the same file fails every time. My questions: Is there any way to make Safari use HTTP/1.1 for a site, or turn HTTP/2 off, for testing? For example a hidden setting, a defaults write key, something under Develop → Feature Flags, or a Web Inspector option. I couldn’t find one. If not, is there a recommended way to test how Safari behaves with HTTP/1.1 only? Safari supports HTTP/3. Our load balancer doesn’t offer HTTP/3 at the moment, but if it did, would Safari switch to it automatically for uploads? And are large uploads over HTTP/3 known to behave better than over HTTP/2? I have also asked AWS about the load balancer side. The long-term plan is to switch HTTP/2 off there, but I’d like to be able to confirm the behaviour in Safari directly in the meantime. Thank you
Topic: Safari & Web SubTopic: General
0
0
272
1w
Safari Web Extension Packager Fails for Both Development and App Store Distribution — Logs Artifact Unavailable
Hello, I'm trying to package a Safari Web Extension using Apple's web-based Safari Web Extension Packager in App Store Connect. However, both export processes consistently fail, and I have been unable to determine the root cause. Environment Apple Developer Program membership: Active App Store Connect app configured for both iOS and macOS Development environment: Windows PC and iPad; no access to a Mac Packaging method: Safari Web Extension Packager in App Store Connect Issue Every packaging attempt results in these two errors: Development Distribution: Exporting for Development Distribution failed. Please download the logs artifact for more information. App Store Distribution: Exporting for App Store Distribution failed. Please download the logs artifact for more information. The interface does not appear to provide any button or link to download the referenced logs artifact. As a result, I cannot access the diagnostic information needed to investigate the failure. Troubleshooting performed To determine whether the problem was caused by my extension's code, I created and uploaded a separate, minimal test extension. The same export failures occur with the minimal test extension, not just my original extension. Questions How can I download the logs artifact referenced in the error message? Could this be a server-side packaging, signing, or provisioning issue in App Store Connect? I have already reviewed Apple's documentation, but it does not provide enough information to diagnose these specific failures. Any guidance from someone who has successfully used the current web-based packaging workflow, or from an Apple engineer familiar with this service, would be appreciated. Thank you.
0
0
55
1w
iOS: tapping a PWA's Now Playing card opens another installed PWA
On iPhone 14 Pro running iOS 26.7.1 (23H30), tapping the system Now Playing card for an installed Home Screen web app opens a different installed web app. Steps to reproduce: Have multiple Home Screen web apps installed. Play a video with sound in PWA A. Background PWA A and open the system Now Playing UI. Confirm that the card displays PWA A's video, then tap it. Expected: PWA A opens. Actual: another installed PWA opens. This also reproduces in a minimal PWA using a native HTML <video controls playsinline> element with an H.264/AAC video. The page makes no Media Session API calls and has no player SDK or Service Worker. The card was confirmed to show the test video before tapping it. Reported to Apple as FB25262874, with a portable reproduction. The exact cause within iOS has not been established. Is this a known issue with Home Screen web-app launch routing from Now Playing? Is there a supported workaround?
1
0
1.4k
2w
Web Browser Public Key Credential entitlement "issued" but still Submitted on App ID (macOS browser)
Hi, I make Akari, a Chromium-based browser for macOS (Developer ID, notarized). On 2026-09-23 I requested the Web Browser Public Key Credential entitlement (com.apple.developer.web-browser.public-key-credential) so people can use the passkeys saved in iCloud Keychain. Request ID A9LNZMTCS4. On 2026-10-12, Developer Support (case 102988458082) emailed to say the entitlement had been issued. It still hasn't shown up: Certificates, Identifiers & Profiles > io.0arch.akari > Capability Requests still shows "Web Browser Public Key Credential Requests" as Submitted, with no way to enable it. The App Store Connect API lists only In-App Purchase as a capability for the App ID. Developer ID provisioning profiles generated on 10-12 and 10-15 don't include the entitlement. I replied on the case with screenshots on 10-12 and again on 10-15, and submitted a follow-up on 10-18, but I haven't heard back. Phone support currently says it's unavailable. Two questions: Is there anything else I need to do for an approved entitlement to be applied to the App ID? My membership is an individual account. Is an individual account eligible for this entitlement, or does it need an organization account? Team ID: G9KB4QTS57 Bundle ID: io.0arch.akari Thanks, Joseph
1
0
665
3w
Safari shows "Fraudulent Website Warning" for clean domain — all security databases clear, Chrome works fine
Safari continues to display a "Fraudulent Website Warning" for openvan.camp despite the domain being clean across all major security databases for over a week. Chrome, Firefox, and all other browsers open the site without any warnings. Domain: openvan.camp Warning appeared: March 18, 2026 Warning type: Fraudulent Website Warning (red screen) Current security database status: Google Safe Browsing: ✅ Clean (transparencyreport.google.com) Google Search Console: ✅ No security issues Spamhaus DBL: ✅ Removed from blocklist Fortinet FortiGuard: ✅ Category "Travel" VirusTotal: ✅ 0/65 vendors URLVoid: ✅ 0/35 engines Steps taken: Removed the third-party ad network (Adsterra) that caused the original flag — March 18, 2026 Migrated hosting to Scaleway (AS12876, France), IP: 151.115.84.228 Configured SPF, DKIM, DMARC records Created functional abuse@ and postmaster@ role accounts Submitted review via websitereview.apple.com — no response after 5 days What we believe is happening: Apple's Safe Browsing database appears to have an independent entry for this domain that has not been updated despite all underlying security databases clearing the flag. Safari's warning persists even after deleting ~/Library/Safari/SafeBrowsing/ cache and re-downloading the database — which confirms this is not a local cache issue. Steps to reproduce: Open Safari on macOS or iOS Navigate to https://openvan.camp/ Safari displays "Fraudulent Website Warning" Open the same URL in Chrome — no warning Expected behavior: No warning should be shown. The domain is legitimate, clean, and verified. Has anyone experienced a similar issue? Is there any additional channel to escalate beyond websitereview.apple.com?
3
0
3.0k
3w
Safari flags four company domains across two servers as fraudulent: diagnostic and escalation path?
I develop products for VelikSoft Limited and have an active Apple Developer Program membership. Safari displays Fraudulent Website Warnings for four company-owned domains that we believe are false positives. Domains and IPv4 addresses checked on October 17, 2026: veliksoft.com - 77.110.106.89 tizigo.net - 77.110.106.89 vstranslate.net - 77.110.106.89 translatorphone.com - 94.228.163.126 The first three share a server. The newer translatorphone.com was placed on a different server and IP, but also received the warning shortly after launch. A shared IP alone therefore cannot explain all four warnings. The classification provider and trigger remain unknown. The latest site is an informational translator-device project website, with no EXE downloads. Its homepage serves HTTPS with HTTP 200; www redirects to the same domain. A limited check of homepage references and the primary application script found local assets and interface interactions, without an executable download or automatic redirect to the old server. This is not an exhaustive security audit. It identifies VelikSoft Limited and links to our company site. Chrome opens it normally on this Mac. Earlier checks of the older domains using Search Console and independent security services did not explain the Safari warnings. These historical checks are not current verdicts for the newer domain. We already submitted Website Review requests multiple times and Feedback Assistant report FB24448660. Apple Developer Support case 102967798534 records contact events on September 19, September 30 and October 1, 2026. As of October 17, we have no substantive explanation or resolution. Telephone support is not a usable option for us. Can an Apple engineer or a website owner who resolved a comparable issue advise: How can we identify whether the warning comes from Apple, Google Safe Browsing or another provider? Is there an owner-accessible diagnostic identifying the affected URL and reason? Which escalation path works when Website Review and an existing support case have not produced a substantive response? Can the existing case and FB report be routed for a manual review of all four domains? If you resolved this, what evidence and contact channel actually led to a review? Reproduction: open one of the affected HTTPS domains in Safari with Fraudulent Website Warning enabled; the red warning appears instead of the site. Safari 26 on macOS has been affected. I can provide exact current version details and further evidence through the support case if requested. I am seeking an investigation and correction of any mistaken classification, not instructions to disable protection or bypass warnings.
Topic: Safari & Web SubTopic: General Tags:
0
0
487
3w
SecurityError, show() must be triggered by user activation.
This is a rare occurrence on our site, having only detected 4 instances of it over the past few weeks, where 10s of thousands of transactions have occurred successfully. We only call the following PaymentRequest API onClick from the <apple-pay-button>: async function startApplePay(merchantIdentifier, amount) { ... try { const request = new PaymentRequest([ applePayMethod ], paymentDetails); ... catch (e) { // cancel, just stay here if (e.name === "AbortError") { if (consoleLog) console.log("Payment canceled", e); logServer("INFO", "Payment canceled"); } else { handleError("Error caught: " + e.name + ", " + e.cause + ", " + e.message); } } Where the "handleError" else case is what gets triggered: Error caught: SecurityError, undefined, show() must be triggered by user activation. All 4 instances have been from iPads, but with that small of a sample size, we can't tell whether that's relevant or coincidence. Different iOS versions, but looks like same Safari version. Here are the 4 User Agents we've seen thus far: Mozilla/5.0 (iPad; CPU OS 18_2_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) GSA/352.0.715618234 Mobile/15E148 Safari/604.1 Mozilla/5.0 (iPad; CPU OS 17_6_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) GSA/352.0.715618234 Mobile/15E148 Safari/604.1 Mozilla/5.0 (iPad; CPU OS 18_3_0 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) CriOS/133.0.6943.33 Mobile/15E148 Safari/604.1 Mozilla/5.0 (iPad; CPU OS 18_2_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) CriOS/133.0.6943.33 Mobile/15E148 Safari/604.1
5
0
1.4k
3w
Apple Calculator
Hello. I'm using Sololearn and ChatGPT to learn how to code. I've made a calculator before, but I want to make one similar to the one on iPhone. Is ok to have a link to apple.com or do I say I was inspired by Apple Here is the code I currently have: HTML <!DOCTYPE html><html> <head> <title>Page Title</title> <meta name="viewport" content="width=device-width, initial-scale=1"> </head> <body> <div class="calculator"> <input class="display" type="text"> <div class = "scientific"> <button>(</button> <button>)</button> <button>mc</button> <button>m+</button> <button>m-</button> <button>mr</button> </div> <div class ="standard"> <button class="utility" id="backspace">&#9003;</button> <button class="utility" id="clear">AC</button> <button class="utility" id="percent">%</button> <button class="operator">/</button> <button class="number digit">7</button> <button class="number digit">8</button> <button class="number digit">9</button> <button class="operator">*</button> <button class="number digit">4</button> <button class="number digit">5</button> <button class="number digit">6</button> <button class="operator">-</button> <button class="number digit">1</button> <button class="number digit">2</button> <button class="number digit">3</button> <button class="operator">+</button> <button class="number" id="plusmn"><sup>+</sup>&frasl;<sub>-</sub></button> <button class="number digit">0</button> <button class="number" id="decimal">.</button> <button class="utility equals" id="equals">=</button> </div> </div> </body></html> ``` ``` CSSbody{ background-color: black; } html, body { margin: 0; width: 100%; height: 100%; background-color: black; } input { font-size: 48px; box-sizing: border-box; width: 100%;} .utility { background-color: #666; color: white; } .operator { background-color: orange; color: white; } .equals{ background-color: orange; color: white; } .number{ background-color: #333; color: white; } .calculator { display: grid; /*grid-template-columns: repeat(4, 1fr);*/ grid-template-columns: 1fr; gap: 4px; width: 100%; box-sizing: border-box; padding: 12px; position: fixed; bottom: 0; left: 0;} .calculator button { width: 100%; aspect-ratio: 1; border: none; border-radius: 50%; font-size: 32px; } .scientific{ display: grid; grid-template-columns: repeat(6, 1fr); gap: 4px;} .standard{ display: grid; grid-template-columns: repeat(4, 1fr); gap: 4px;} .display { color: white; background-color: black; border: none; height: 100px; font-size: 48px; text-align: right; box-sizing: border-box; width: 100%; } /* .display { grid-column: 1 / -1; color: white; background-color: black; border: none; height: 100px; font-size: 48px; text-align: right; box-sizing: border-box; width: 100%; } */ /* .zero { grid-column: span 2; border-radius: 40px; aspect-ratio: auto;} .calculator button.zero { aspect-ratio: auto; border-radius: 40px;} */ JS const display = document.querySelector(".display"); let fontSize = 48; function adjustFontSize() { fontSize = 48 - display.value.length * .99; if (fontSize < 20) { fontSize = 20; } display.style.fontSize = fontSize + "px"; } const buttonsJS = document.querySelectorAll(".digit"); buttonsJS.forEach(function(buttonJS) { buttonJS.addEventListener("click", function() { display.value += buttonJS.textContent; adjustFontSize(); }); }); const clear = document.querySelector("#clear"); clear.addEventListener("click", function() { display.value = ""; adjustFontSize(); }); const backspace = document.querySelector("#backspace"); backspace.addEventListener("click", function() { display.value = display.value.slice (0, -1); adjustFontSize(); }); const percent = document.querySelector("#percent"); percent.addEventListener("click", function(){ display.value /= 100; adjustFontSize(); }); const plusmn = document.querySelector("#plusmn"); plusmn.addEventListener("click", function(){ display.value /= -1; adjustFontSize(); }); const decimal = document.querySelector("#decimal"); decimal.addEventListener("click", function(){ if (!display.value.includes(".")) { display.value += "."; // Add the decimal point here } adjustFontSize();}); const operators = document.querySelectorAll(".operator"); operators.forEach(function(operator) { operator.addEventListener("click", function() { display.value += operator.textContent; adjustFontSize(); }); }); const equals = document.querySelector("#equals"); equals.addEventListener("click", function() { display.value = eval(display.value); adjustFontSize(); }); /* const display = document.querySelector(".display"); const buttonJS = document.querySelector(".digit"); buttonJS.addEventListener("click", function() { console.log("You clicked the button!"); }); const buttonsJS = document.querySelectorAll(".digit"); buttonsJS.forEach(function(buttonJS) { buttonJS.addEventListener("click", function() { display.value += buttonJS.textContent; }); }); */
Replies
1
Boosts
0
Views
828
Activity
1w
Safari shows “Fraudulent Website Warning” for q-saver.com for over 5 months despite repeated Website Review requests
Safari displays a red “Fraudulent Website Warning” for my website q-saver.com. The warning has been present for more than 5 months. I have already submitted two requests through https://websitereview.apple.com/, but neither resulted in the warning being removed or any response. The website is a video downloading service. It does not impersonate Apple or financial services and does not ask for Apple IDs, banking credentials or other sensitive information. The only password it asks for is the optional password of a q-saver.com account; sign-in with Google or Telegram goes through their official OAuth pages, and payments are processed on the payment providers' own pages. The site used to show pop-under ads from third-party ad networks. They have been turned off (the last one on September 26, 2026), and the ad network code has been removed from the pages. On 27 September I submitted a new Website Review request. Google Safe Browsing reports no unsafe content for the site: https://transparencyreport.google.com/safe-browsing/search?url=q-saver.com The website works normally in Chrome, Firefox and Edge. In iOS in-app browsers (for example, Telegram) it does not open at all because of the warning. Is there an official escalation path for Safari's Fraudulent Website Warning classification when Website Review requests remain unresolved for several months? I can provide screenshots and technical information privately if required.
Replies
2
Boosts
0
Views
2.3k
Activity
1w
Apple Pay on the Web sheet fails with PKPaymentAuthorizationStateFatalError after successful merchant validation (PROD trust policy)
Environment macOS 26.5.1 (Build 25F80) Safari 26.5 Apple Pay JS API version 8 Using https://applepay.cdn-apple.com/jsapi/v1/apple-pay-sdk.js Reproduces on the staging website (Does not reproduce on the production website with non sandbox account) Signed into a Sandbox Tester Apple ID, with a test credit card registered exactly per Apple Pay Sandbox Testing — this is the only card in Wallet on the laptop Merchant validation is performed by our staging backend against our real (non-sandbox) merchant identity/certificate — i.e. a sandbox tester card being evaluated against a staging merchant session, which per the sandbox testing documentation is the expected/supported setup for testing on a live site without a separate merchant sandbox environment Summary After completeMerchantValidation() succeeds and the merchant session is accepted, the payment sheet still terminates with PKPaymentAuthorizationStateFatalError a few hundred milliseconds later, right after the native side logs a second "Evaluating merchant session using PROD trust policy." for the same session. The user sees "Payment failed" and the sheet closes. This happens on the very first attempt, with no user interaction beyond tapping the Apple Pay button — no shipping address is even selected before the failure. Since the sandbox tester card + production merchant session combination is the setup the sandbox testing guide describes, we'd expect the sheet to proceed to onpaymentauthorized (Apple's sandbox docs describe payments as being processed as $0 test transactions in this mode) rather than fail natively before that stage is ever reached. Steps to reproduce Visit an item page with an Apple Pay button. Tap the Apple Pay button to open the payment sheet. The sheet presents normally; no interaction with shipping address or payment method is required for the failure to occur. Within ~1 second, the sheet dismisses and displays a "Payment failed" error state. Minimal reproduction of the JS side const session = new ApplePaySession(8, { countryCode: 'US', currencyCode: 'USD', supportedNetworks: ['visa', 'masterCard', 'amex', 'discover'], merchantCapabilities: ['supports3DS'], total: { label: 'Merchant', amount: '10.00' }, }); session.onvalidatemerchant = async () => { const merchantSession = await validateMerchantOnServer(); // succeeds session.completeMerchantValidation(merchantSession); // accepted — see log below }; session.onpaymentmethodselected = () => { session.completePaymentMethodSelection({ newTotal: { label: 'Merchant', amount: '10.00' }, }); }; session.oncancel = event => console.log('cancelled', event); session.begin(); We reproduced this with both our full checkout implementation and this stripped-down request object (no shipping contact required, no line items) — same failure either way, which rules out anything about our order/line-item data. What we expected The sheet to proceed to the biometric authorization step and dispatch onpaymentauthorized once the user confirms. What actually happens The sheet fails immediately with a PKPaymentAuthorizationStateFatalError transition, even though every JS-side completion call (completeMerchantValidation, the payment-method selection) succeeded and returned PKPaymentAuthorizationStatusSuccess. System log (captured via log stream --info --debug --predicate 'process == "Safari" OR process == "passd" OR process == "com.apple.PassKit.PaymentAuthorizationUIExtension"') 21:50:41.544 PaymentCoordinator::beginPaymentSession() -> 1 21:50:41.570 Received prepareWithPaymentRequest: <private> 21:50:42.297 PaymentCoordinator::validateMerchant() 21:50:42.563 PaymentCoordinator::completeMerchantValidation() 21:50:42.564 Received merchant session update with status:PKPaymentAuthorizationStatusSuccess session:<private> 21:50:42.564 Evaluating merchant session using PROD trust policy. <- 1st occurrence, passes 21:50:42.572 PaymentCoordinator::didSelectPaymentMethod() 21:50:42.572 PaymentCoordinator::completePaymentMethodSelection() 21:50:42.653 Evaluating merchant session using PROD trust policy. <- 2nd occurrence 21:50:42.656 State machine change state from ClientCallback to PrepareTransactionDetails with param: <private> 21:50:43.391 Task Completed: <private> 21:50:43.393 State machine change state from PrepareTransactionDetails to PKPaymentAuthorizationStateFatalError with param: <private> 21:50:43.393 Error Payment failed with fatal error <private> 21:50:45.130 PaymentCoordinator::didCancelPaymentSession() The first "Evaluating merchant session using PROD trust policy." line passes (the flow continues to didSelectPaymentMethod). The second occurrence is immediately followed by Task Completed and then the FatalError transition, which suggests PassKit re-validates the merchant session's trust a second time right before PrepareTransactionDetails, and that second check is what's rejecting the session — even though the identical session object was accepted moments earlier at completeMerchantValidation(). What we've tried / ruled out Confirmed every JS completion method (completeMerchantValidation, completePaymentMethodSelection) is called and returns success — no 30-second timeout, no missing completion call, no thrown exception on our side. Reproduced with a minimal, hardcoded ApplePayPaymentRequest (fixed $10.00 total, no shipping fields) — rules out anything about our real order/line-item/sales-tax data. Reproduced on the main branch and independently on our staging deployment running unmodified code — rules out anything specific to our recent frontend changes. The <private> redaction in the system log prevents us from seeing what specifically fails during the second trust evaluation. Confirmed the sandbox tester card and its registration follow the sandbox testing guide exactly — it's the only card on the device, and no other Wallet cards are involved. Question What does PassKit's second "Evaluating merchant session using PROD trust policy" check (immediately before PrepareTransactionDetails) actually validate, beyond what's already checked at completeMerchantValidation() time? Is a sandbox tester card being evaluated against a production merchant session expected to pass this second check, or does sandbox testing per the linked guide require something additional on the merchant/session side (e.g. a specific field on the merchant session, or a specific environment value) that our backend isn't setting? Is there a way to get an unredacted reason for the rejection — e.g. via a private-data-enabled log profile or another diagnostic — since the redacted system log alone doesn't surface one?
Replies
3
Boosts
0
Views
3.2k
Activity
1w
White flash when opening a new tab overridden by a Safari Web Extension on iOS
White flash when opening a new tab overridden by a Safari Web Extension on iOS Safari intermittently displays a white flash when opening a new tab overridden by a web extension. I reproduced this on an iPhone 13 mini running iOS 26.5 using a minimal test extension. Minimal reproduction The extension replaces the new tab page through chrome_url_overrides.newtab. The page has a static magenta background, set directly on the root element and through inline CSS. The test page contains no JavaScript, images, fonts, external stylesheets or network requests. Steps to reproduce Install and enable a Safari Web Extension that overrides the new tab page with a static magenta HTML page. Select the extension for new tabs in Safari settings. Open Safari in normal browsing mode. Open a new tab and wait for the magenta page to appear. Open another new tab. Repeat several times. Expected: The page area remains magenta throughout the transition. Actual: The page area intermittently transitions from magenta → white → magenta. The issue reproduces without JavaScript or external resources, so the flash does not require delayed script execution or image loading. Is this a known issue with Safari’s handling of new tab overrides? Is there a supported way for an extension to control the background displayed during this transition?
Replies
2
Boosts
0
Views
715
Activity
1w
Safari and Safari Technology Preview intermittently ignore clicks near bottom of webpage on macOS 27 Beta
Environment: MacBook Air M4 macOS 27 Beta Safari Safari Technology Preview Issue: I am experiencing an issue where mouse/trackpad clicks are intermittently ignored near the bottom portion of a webpage. The trackpad hardware appears to be functioning normally, as physical clicks are registered and the issue does not occur consistently across all browsers. Steps to Reproduce: Open Safari or Safari Technology Preview. Navigate to a webpage with interactive elements near the bottom of the visible page. Attempt to click links, buttons, or text fields located in approximately the bottom quarter of the browser window. Observe that clicks are sometimes not registered. Resize the Safari window so that the affected area is no longer located in the bottom portion of the screen. Attempt the same clicks again. Expected Result: Clicks should be consistently registered regardless of their position within the webpage. Actual Result: Clicks in the lower portion of the webpage are sometimes ignored. Resizing the window may temporarily resolve the issue. Additional Information: The trackpad itself appears to function normally. Physical clicks are detected. I have observed the issue in both Safari and Safari Technology Preview. I tested the same website in Perplexity Comet, where the issue does not appear to occur. This suggests the issue may be related to Safari’s rendering, hit-testing, event handling, or window management rather than the website itself. Has anyone else been able to reproduce this on macOS 27 Beta?
Replies
1
Boosts
1
Views
1.8k
Activity
1w
Disabling HTTP/2 in Safari
Hi, I’m testing file uploads to a web app that sits behind an AWS Application Load Balancer, and I need a way to make Safari use HTTP/1.1 instead of HTTP/2 while I test. What I’m seeing: Uploads up to about 4 MB work. Anything bigger slows down more and more and then fails with a network error. A 49 MB file never finishes. The same upload over HTTP/1.1 works every time. I tested this with curl (--http1.1 against --http2), and with Chrome started with --disable-http2. In that Chrome, the 49 MB file uploaded fine. In Safari, which uses HTTP/2 with this server, the same file fails every time. My questions: Is there any way to make Safari use HTTP/1.1 for a site, or turn HTTP/2 off, for testing? For example a hidden setting, a defaults write key, something under Develop → Feature Flags, or a Web Inspector option. I couldn’t find one. If not, is there a recommended way to test how Safari behaves with HTTP/1.1 only? Safari supports HTTP/3. Our load balancer doesn’t offer HTTP/3 at the moment, but if it did, would Safari switch to it automatically for uploads? And are large uploads over HTTP/3 known to behave better than over HTTP/2? I have also asked AWS about the load balancer side. The long-term plan is to switch HTTP/2 off there, but I’d like to be able to confirm the behaviour in Safari directly in the meantime. Thank you
Topic: Safari & Web SubTopic: General
Replies
0
Boosts
0
Views
272
Activity
1w
Safari Web Extension Packager Fails for Both Development and App Store Distribution — Logs Artifact Unavailable
Hello, I'm trying to package a Safari Web Extension using Apple's web-based Safari Web Extension Packager in App Store Connect. However, both export processes consistently fail, and I have been unable to determine the root cause. Environment Apple Developer Program membership: Active App Store Connect app configured for both iOS and macOS Development environment: Windows PC and iPad; no access to a Mac Packaging method: Safari Web Extension Packager in App Store Connect Issue Every packaging attempt results in these two errors: Development Distribution: Exporting for Development Distribution failed. Please download the logs artifact for more information. App Store Distribution: Exporting for App Store Distribution failed. Please download the logs artifact for more information. The interface does not appear to provide any button or link to download the referenced logs artifact. As a result, I cannot access the diagnostic information needed to investigate the failure. Troubleshooting performed To determine whether the problem was caused by my extension's code, I created and uploaded a separate, minimal test extension. The same export failures occur with the minimal test extension, not just my original extension. Questions How can I download the logs artifact referenced in the error message? Could this be a server-side packaging, signing, or provisioning issue in App Store Connect? I have already reviewed Apple's documentation, but it does not provide enough information to diagnose these specific failures. Any guidance from someone who has successfully used the current web-based packaging workflow, or from an Apple engineer familiar with this service, would be appreciated. Thank you.
Replies
0
Boosts
0
Views
55
Activity
1w
iOS: tapping a PWA's Now Playing card opens another installed PWA
On iPhone 14 Pro running iOS 26.7.1 (23H30), tapping the system Now Playing card for an installed Home Screen web app opens a different installed web app. Steps to reproduce: Have multiple Home Screen web apps installed. Play a video with sound in PWA A. Background PWA A and open the system Now Playing UI. Confirm that the card displays PWA A's video, then tap it. Expected: PWA A opens. Actual: another installed PWA opens. This also reproduces in a minimal PWA using a native HTML <video controls playsinline> element with an H.264/AAC video. The page makes no Media Session API calls and has no player SDK or Service Worker. The card was confirmed to show the test video before tapping it. Reported to Apple as FB25262874, with a portable reproduction. The exact cause within iOS has not been established. Is this a known issue with Home Screen web-app launch routing from Now Playing? Is there a supported workaround?
Replies
1
Boosts
0
Views
1.4k
Activity
2w
Web Browser Public Key Credential entitlement "issued" but still Submitted on App ID (macOS browser)
Hi, I make Akari, a Chromium-based browser for macOS (Developer ID, notarized). On 2026-09-23 I requested the Web Browser Public Key Credential entitlement (com.apple.developer.web-browser.public-key-credential) so people can use the passkeys saved in iCloud Keychain. Request ID A9LNZMTCS4. On 2026-10-12, Developer Support (case 102988458082) emailed to say the entitlement had been issued. It still hasn't shown up: Certificates, Identifiers & Profiles > io.0arch.akari > Capability Requests still shows "Web Browser Public Key Credential Requests" as Submitted, with no way to enable it. The App Store Connect API lists only In-App Purchase as a capability for the App ID. Developer ID provisioning profiles generated on 10-12 and 10-15 don't include the entitlement. I replied on the case with screenshots on 10-12 and again on 10-15, and submitted a follow-up on 10-18, but I haven't heard back. Phone support currently says it's unavailable. Two questions: Is there anything else I need to do for an approved entitlement to be applied to the App ID? My membership is an individual account. Is an individual account eligible for this entitlement, or does it need an organization account? Team ID: G9KB4QTS57 Bundle ID: io.0arch.akari Thanks, Joseph
Replies
1
Boosts
0
Views
665
Activity
3w
Safari shows "Fraudulent Website Warning" for clean domain — all security databases clear, Chrome works fine
Safari continues to display a "Fraudulent Website Warning" for openvan.camp despite the domain being clean across all major security databases for over a week. Chrome, Firefox, and all other browsers open the site without any warnings. Domain: openvan.camp Warning appeared: March 18, 2026 Warning type: Fraudulent Website Warning (red screen) Current security database status: Google Safe Browsing: ✅ Clean (transparencyreport.google.com) Google Search Console: ✅ No security issues Spamhaus DBL: ✅ Removed from blocklist Fortinet FortiGuard: ✅ Category "Travel" VirusTotal: ✅ 0/65 vendors URLVoid: ✅ 0/35 engines Steps taken: Removed the third-party ad network (Adsterra) that caused the original flag — March 18, 2026 Migrated hosting to Scaleway (AS12876, France), IP: 151.115.84.228 Configured SPF, DKIM, DMARC records Created functional abuse@ and postmaster@ role accounts Submitted review via websitereview.apple.com — no response after 5 days What we believe is happening: Apple's Safe Browsing database appears to have an independent entry for this domain that has not been updated despite all underlying security databases clearing the flag. Safari's warning persists even after deleting ~/Library/Safari/SafeBrowsing/ cache and re-downloading the database — which confirms this is not a local cache issue. Steps to reproduce: Open Safari on macOS or iOS Navigate to https://openvan.camp/ Safari displays "Fraudulent Website Warning" Open the same URL in Chrome — no warning Expected behavior: No warning should be shown. The domain is legitimate, clean, and verified. Has anyone experienced a similar issue? Is there any additional channel to escalate beyond websitereview.apple.com?
Replies
3
Boosts
0
Views
3.0k
Activity
3w
Safari flags four company domains across two servers as fraudulent: diagnostic and escalation path?
I develop products for VelikSoft Limited and have an active Apple Developer Program membership. Safari displays Fraudulent Website Warnings for four company-owned domains that we believe are false positives. Domains and IPv4 addresses checked on October 17, 2026: veliksoft.com - 77.110.106.89 tizigo.net - 77.110.106.89 vstranslate.net - 77.110.106.89 translatorphone.com - 94.228.163.126 The first three share a server. The newer translatorphone.com was placed on a different server and IP, but also received the warning shortly after launch. A shared IP alone therefore cannot explain all four warnings. The classification provider and trigger remain unknown. The latest site is an informational translator-device project website, with no EXE downloads. Its homepage serves HTTPS with HTTP 200; www redirects to the same domain. A limited check of homepage references and the primary application script found local assets and interface interactions, without an executable download or automatic redirect to the old server. This is not an exhaustive security audit. It identifies VelikSoft Limited and links to our company site. Chrome opens it normally on this Mac. Earlier checks of the older domains using Search Console and independent security services did not explain the Safari warnings. These historical checks are not current verdicts for the newer domain. We already submitted Website Review requests multiple times and Feedback Assistant report FB24448660. Apple Developer Support case 102967798534 records contact events on September 19, September 30 and October 1, 2026. As of October 17, we have no substantive explanation or resolution. Telephone support is not a usable option for us. Can an Apple engineer or a website owner who resolved a comparable issue advise: How can we identify whether the warning comes from Apple, Google Safe Browsing or another provider? Is there an owner-accessible diagnostic identifying the affected URL and reason? Which escalation path works when Website Review and an existing support case have not produced a substantive response? Can the existing case and FB report be routed for a manual review of all four domains? If you resolved this, what evidence and contact channel actually led to a review? Reproduction: open one of the affected HTTPS domains in Safari with Fraudulent Website Warning enabled; the red warning appears instead of the site. Safari 26 on macOS has been affected. I can provide exact current version details and further evidence through the support case if requested. I am seeking an investigation and correction of any mistaken classification, not instructions to disable protection or bypass warnings.
Topic: Safari & Web SubTopic: General Tags:
Replies
0
Boosts
0
Views
487
Activity
3w
SecurityError, show() must be triggered by user activation.
This is a rare occurrence on our site, having only detected 4 instances of it over the past few weeks, where 10s of thousands of transactions have occurred successfully. We only call the following PaymentRequest API onClick from the <apple-pay-button>: async function startApplePay(merchantIdentifier, amount) { ... try { const request = new PaymentRequest([ applePayMethod ], paymentDetails); ... catch (e) { // cancel, just stay here if (e.name === "AbortError") { if (consoleLog) console.log("Payment canceled", e); logServer("INFO", "Payment canceled"); } else { handleError("Error caught: " + e.name + ", " + e.cause + ", " + e.message); } } Where the "handleError" else case is what gets triggered: Error caught: SecurityError, undefined, show() must be triggered by user activation. All 4 instances have been from iPads, but with that small of a sample size, we can't tell whether that's relevant or coincidence. Different iOS versions, but looks like same Safari version. Here are the 4 User Agents we've seen thus far: Mozilla/5.0 (iPad; CPU OS 18_2_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) GSA/352.0.715618234 Mobile/15E148 Safari/604.1 Mozilla/5.0 (iPad; CPU OS 17_6_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) GSA/352.0.715618234 Mobile/15E148 Safari/604.1 Mozilla/5.0 (iPad; CPU OS 18_3_0 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) CriOS/133.0.6943.33 Mobile/15E148 Safari/604.1 Mozilla/5.0 (iPad; CPU OS 18_2_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) CriOS/133.0.6943.33 Mobile/15E148 Safari/604.1
Replies
5
Boosts
0
Views
1.4k
Activity
3w