Hi,
I have developed my extension using React and MUI. The extension works with other browsers but it does not work with Safari. Is there any workaround to make it work with Safari or It is not possible to use React build on Safari.
Thank you.
Safari
RSS for tagSafari is the web browser developed by Apple and built into all Apple devices.
Posts under Safari tag
200 Posts
Sort by:
Post
Replies
Boosts
Views
Activity
Hello all, I am have an issue in Safari both for iOS and MacOS where when uploading a file with XMLHttpRequest() progress is not sent in a nice even interval that allows for a smooth upload progress, it is set randomly at large intervals. This means you do not get a smooth nice progress but rather large jumps because the amount of data sent is in large intervals. can see data being constantly sent from the device and at the server level so I know the upload is working.
You can see the problem here: https://imgur.com/a/Qhh3Q8u
I am pretty sure this has to do with the server config and something that is unique to Safari, I am running Nginx 1.27.0 and Php 8.2. This problem does not happen in Chrome or Firefox on my desktop, in those browsers I get a smooth progress and data sent amount. If you have a fast connection you do not notice this problem, slow connections and it's very apparent.
Has anyone figured out what is needed to get this to work properly?
Hi everyone.
I'm reaching out to you to get some help about the issue that I'm facing for last couple of weeks.
The problem is when I have HTML canvas element which is rendering some text which is including some emojis and I'm setting gradient color to that text. I'm expecting that after setting gradient emojis should not change their color, but the reality is that they also become colored. The issue is not reproducible in other major browsers. I'm attaching some screenshots and HTML code for you to have better understanding what I'm trying to achieve.
Thanks in advance.
<html lang="en">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<title>Document</title>
<style></style>
</head>
<body>
<div id="emojis"></div>
<script>
const emojis = [
0x1f600, 0x1f601, 0x1f603, 0x1f603, 0x1f604, 0x1f605, 0x1f606, 0x1f607, 0x1f609, 0x1f60a, 0x1f642,
0x1f643, 0x1f355, 0x1f354,
];
const emoji = [];
const size = 80;
const factor = 2;
const placeholder = document.getElementById("emojis");
for (let i = 0; i < 3; i++) {
emoji.push({
x: size,
y: size,
src: getEmoji(),
});
}
function loadCanvas(id, emo) {
const canvas = document.createElement("canvas");
canvas.id = id;
placeholder.appendChild(canvas);
const ctx = canvas.getContext("2d");
loadEmoji(canvas, ctx, emo);
}
function loadEmoji(canvas, ctx, emo) {
// Use the intrinsic size of image in CSS pixels for the canvas element
canvas.width = w = size * factor;
canvas.height = h = size * factor;
const fontSize = size * (factor - 0.5);
const offset = Math.floor((h - fontSize) / 4);
ctx.font = `${size * (factor - 0.5)}px Arial`;
ctx.textBaseline = "middle";
ctx.textAlign = "center";
emo.x = w / 2;
emo.y = h - size + offset;
const gradient = ctx.createLinearGradient(0, 0, canvas.width, 0);
gradient.addColorStop("0", "magenta");
gradient.addColorStop("0.5", "blue");
gradient.addColorStop("1.0", "red");
ctx.fillStyle = gradient;
ctx.fillText(emo.src, emo.x, emo.y);
}
function getEmoji() {
const len = emojis.length;
const emos = Math.floor(Math.random() * len);
return String.fromCodePoint(emojis[emos]);
}
window.onload = function () {
emoji.forEach((emo, i) => {
const id = `canvas-0${i}`;
loadCanvas(id, emo);
});
};
</script>
</body>
</html>
Hi:
I saw the post WWDC WebKit release notes said Safari will support largeblob extension from version 17. But when I create a credential with largeblob extension, different action takes according what authenticator used.
The credential options is:
"credCreateOptions": {
"rp": {
"name": "WebAuthn demo",
"id": "webauthn.turinggear.com"
},
"user": {
"name": "Jonathon.Runte97@gmail.com",
"displayName": "Jonathon.Runte97@gmail.com",
"id": "bqShD9YGRicjM-1foXiBqrdCzTHTuG1bkmKaxzn7oEM"
},
"challenge": "9BP4y2epk2b3MhRCRRS5tt4bdWYLPJcKBLMMiB_7p7E",
"pubKeyCredParams": [
{
"alg": -7,
"type": "public-key"
},
{
"alg": -257,
"type": "public-key"
}
],
"excludeCredentials": [],
"authenticatorSelection": {
"requireResidentKey": true,
"residentKey": "required",
"userVerification": "discouraged"
},
"attestation": "none",
"extensions": {
"credProps": true,
"largeBlob": {
"support": "preferred"
}
}
}
When i choose use iPhone be my authenticator, it seems that largeblob act as it should be:
"credential" : {
"id": "ZRxBdH4LKE4eiVxbwcA4Kmn9VZk",
"rawId": "ZRxBdH4LKE4eiVxbwcA4Kmn9VZk",
"response": {
"attestationObject": "o2NmbXRkbm9uZWdhdHRTdG10oGhhdXRoRGF0YViYSETDPyxegNfyH_fI_8t9iVRDn34LxYd8YH1k2u4xSk5dAAAAAPv8MAcVTk7MjAtuAgVX170AFGUcQXR-CyhOHolcW8HAOCpp_VWZpQECAyYgASFYICY6gkqg6OG_v1BlGCPj7gSwsu_c0vTmVzmfd7TsqEh5Ilgg_Cn0mAiO8QCx7J1xw809VBq8iI-U5pgY0I947B7XF9g",
"clientDataJSON": "eyJ0eXBlIjoid2ViYXV0aG4uY3JlYXRlIiwiY2hhbGxlbmdlIjoiOVcta3RMbEswemZDSXpFb2hNd3E3OTgxQXJlRzV0aEVBdmRHdXNHcUsxcyIsIm9yaWdpbiI6Imh0dHBzOi8vd2ViYXV0aG4udHVyaW5nZ2Vhci5jb20ifQ",
"transports": [
"internal",
"hybrid"
],
"publicKeyAlgorithm": -7,
"publicKey": "MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEJjqCSqDo4b-_UGUYI-PuBLCy79zS9OZXOZ93tOyoSHn8KfSYCI7xALHsnXHDzT1UGryIj5TmmBjQj3jsHtcX2A",
"authenticatorData": "SETDPyxegNfyH_fI_8t9iVRDn34LxYd8YH1k2u4xSk5dAAAAAPv8MAcVTk7MjAtuAgVX170AFGUcQXR-CyhOHolcW8HAOCpp_VWZpQECAyYgASFYICY6gkqg6OG_v1BlGCPj7gSwsu_c0vTmVzmfd7TsqEh5Ilgg_Cn0mAiO8QCx7J1xw809VBq8iI-U5pgY0I947B7XF9g"
},
"type": "public-key",
"clientExtensionResults": {
"largeBlob": {
"supported": true
}
},
"authenticatorAttachment": "platform"
}
Safari returns clientExtensionResults.largeBlob.supported= ture.
But when I use an NFC authenticator with the same credCreateOptions, safari didnot return clientExtensionResults section. Response as follows(ignore the challenge and others random data):
"credential" : {
"id": "uEVMzgsINXj7bHFD5Z5xbMGJ7k6tnrMQSLjB4yB8_0GxbUPoWYUYX8E3D9XB24Cv-PMh6cRpCFt5klUHqsot2Yc48BVu5TN8sbabTgped2x46ljdsxFzaNCA8D2y9FZK8BHLLZTKHNuzJw4SCYUkzg",
"rawId": "uEVMzgsINXj7bHFD5Z5xbMGJ7k6tnrMQSLjB4yB8_0GxbUPoWYUYX8E3D9XB24Cv-PMh6cRpCFt5klUHqsot2Yc48BVu5TN8sbabTgped2x46ljdsxFzaNCA8D2y9FZK8BHLLZTKHNuzJw4SCYUkzg",
"response": {
"attestationObject": "o2NmbXRkbm9uZWdhdHRTdG10oGhhdXRoRGF0YVj0SETDPyxegNfyH_fI_8t9iVRDn34LxYd8YH1k2u4xSk5FAAABeAAAAAAAAAAAAAAAAAAAAAAAcLhFTM4LCDV4-2xxQ-WecWzBie5OrZ6zEEi4weMgfP9BsW1D6FmFGF_BNw_VwduAr_jzIenEaQhbeZJVB6rKLdmHOPAVbuUzfLG2m04KXndseOpY3bMRc2jQgPA9svRWSvARyy2UyhzbsycOEgmFJM6lAQIDJiABIVggg2LXO5Q2U0ETrSxrLKxCfKKCTCitTCx9bpxD1Gw917ciWCDsxnw4Wd7M_UTiGQJ7swCMXN83nprsT8wkTlftXRizmw",
"clientDataJSON": "eyJ0eXBlIjoid2ViYXV0aG4uY3JlYXRlIiwiY2hhbGxlbmdlIjoiOUJQNHkyZXBrMmIzTWhSQ1JSUzV0dDRiZFdZTFBKY0tCTE1NaUJfN3A3RSIsIm9yaWdpbiI6Imh0dHBzOi8vd2ViYXV0aG4udHVyaW5nZ2Vhci5jb20ifQ",
"transports": [
"nfc"
],
"publicKeyAlgorithm": -7,
"publicKey": "MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEg2LXO5Q2U0ETrSxrLKxCfKKCTCitTCx9bpxD1Gw917fsxnw4Wd7M_UTiGQJ7swCMXN83nprsT8wkTlftXRizmw",
"authenticatorData": "SETDPyxegNfyH_fI_8t9iVRDn34LxYd8YH1k2u4xSk5FAAABeAAAAAAAAAAAAAAAAAAAAAAAcLhFTM4LCDV4-2xxQ-WecWzBie5OrZ6zEEi4weMgfP9BsW1D6FmFGF_BNw_VwduAr_jzIenEaQhbeZJVB6rKLdmHOPAVbuUzfLG2m04KXndseOpY3bMRc2jQgPA9svRWSvARyy2UyhzbsycOEgmFJM6lAQIDJiABIVggg2LXO5Q2U0ETrSxrLKxCfKKCTCitTCx9bpxD1Gw917ciWCDsxnw4Wd7M_UTiGQJ7swCMXN83nprsT8wkTlftXRizmw"
},
"type": "public-key",
"clientExtensionResults": {},
"authenticatorAttachment": "cross-platform"
}
Even without a clientExtensionResults.largeBlob.supported= false.
According to w3c, it should return clientExtensionResults.largeBlob.supported= false ?
The NFC authenticaor do support largeblob extensions and act write with the same credCreateOptions on edge on windows.
Does safari need some extra parameters?
My safari is the newest version of 17.5 (19618.2.12.11.6), mac version is Sonoma 14.5(23F79).
Thank you very much.
Here is my manifest.json:
"permissions": [
"<all_urls>",
"storage",
"unlimitedStorage",
"activeTab"
]
Despite declaring "unlimitedStorage" in permissions, I encounter the following error when trying to save files exceeding approximately 3MB:
Invalid call to browser.storage.local.set(). Exceeded storage quota.
This issue did not occur in iOS 17. Is this behavior intentional or is it a bug? If it is intentional, is there an alternative method to handle large file?
All attempts to script Safari in Xcode using NSAppleScript returns the following message.
error: {
NSAppleScriptErrorAppName = Safari;
NSAppleScriptErrorBriefMessage = "Application isn\U2019t running.";
NSAppleScriptErrorMessage = "Safari got an error: Application isn\U2019t running.";
NSAppleScriptErrorNumber = "-600";
NSAppleScriptErrorRange = "NSRange: {32, 3}";
}
Latest script attempt:
func getHTML() -> String {
let source = """
tell application "Safari"
get URL of tab 1 of window 1
end tell
"""
//print(source)
var a = "hello"
var error: NSDictionary?
if let scriptObject = NSAppleScript(source: source) {
if let scriptResult = scriptObject.executeAndReturnError(&error).stringValue
{
a = scriptResult
print(scriptResult)
} else if (error != nil) {
print("error: ",error!)
}
}
return a
}
In Safari, when there are two password fields side-by-side, they are actually asking for different passwords. However, the browser's autofill might automatically fill the second field with the same password as the first, assuming it's a confirmation.
The process to reproduce:
Create a new extension with Xcode 16 beta.
Run it on the simulator or any iOS device with iOS 18 beta installed.
Open Safari on your Mac, then open Develop -> Device you use.
Unable to access these menus for iOS 18:
1. Extension - Extension Background Content
2. Extension - Extension Pop-up Page - popup.html
However, for iOS 17.4, I can see these options in Develop -> Device iOS(17.4).
I have another extension on the App Store that is not working on the iOS 18 beta, but I am unable to debug it because of this issue.
In iOS 18, internal extension pages cannot navigate to external webpages, either via href links or through JS methods such as window.location.replace. Nothing happens when you try to navigate to an external webpage. Only other internal pages can be navigated to. This wasn't an issue on previous versions of iOS.
It would be appreciated if this can be fixed as soon as possible.
Feedback ID: FB14194963
Can we get the list or count of the URLs blocked using the Safari web extension content blocking on the iOS app?
i can sure the app already hava the camera access, but in the embedded html, i still cannot open the camera. And this HTML page is work at Safari, but cant work on app when the page is embedded in app.
there is the error message:
DOMException: undefine is not an object (evaluating 'navigator.mediaDevices.getUserMedia')
and i also try to use 'navigator.getUserMedia' and 'navigator.mediaDevices.enumerateDevices()', this all dont work.
Hello!
I was wondering if any other developers are experiencing issues with accessing the web extension background script console, sources, etc. on the latest Safari Technology preview or macOS Sequoia betas.
We have an extension which has a persistent background script.
In the latest public release of Safari version 17.5 (19618.2.12.11.6) on macOS Sonoma, everything works as expected. When I enable developer mode in Safari, it shows an additional "Develop" menu and when I select "Web Extension Background Content" in the dropdown, it shows a list of background pages for all installed extensions.
Attaching a screenshot for reference.
However, if I install the latest Safari Technology Preview 197 on macOS Sonoma or just test with the Safari version that comes with MacOS Sequoia beta 1 or beta 2, the "Web Extension Background Content" dropdown menu does not list any background pages.
Attaching a screenshot for reference.
We started discussing the issue with Apple during the latest WWDC.
If anyone at Apple sees this post, I opened FB13834388 to track this issue.
However according to Apple, they cannot reproduce the issue exactly as I see it on all macOS machines around me including clean virtual machines, real hardware (MacBook Pro M1 Max, MacBook Air M2, MacBook Pro Intel based). The "Web Extension Background Content" menu looks as expected on their end which is very confusing to me...
I have a reason to believe that new Safari's developer tools are simply broken in the latest release. I base that statement on the fact that I cannot access it in case of our own Safari extension, Apple's sample "Sea Creator" extension and a few random extensions that I got from the App Store.
I was wondering if anyone else can observe the same behavior or all machines around me are haunted :)
Please share if you have similar issues with Safari Technology Preview 197 or Safari on the latest macOS Sequoia beta.
Any feedback is important to us. If it's a widespread issue, then Apple should prioritize is accordingly. If the issue is somehow specific to our testing, we will fix it on our side. But any test results at this point are bringing more clarity to the situation and are highly appreciated.
As I wanted to transfer my existing tabgoups from my iPhone/Mac to my new iPad (strange that it’s not working on its own) I shared the tabgroup as a message and opened it on my iPad. From that moment on I had shared tabgroups with a blue dot behind the individual tabs in the tabgroups and a menu bar on the top of each tab where I was able to discontinue the sharing. After a short while a noticed all tabs in the tab groups consisting of more than 400 tabs multiplied 5x.
I am using iOS 18 beta on the iPad and iOS 17.6 on my iPhone. My MacBook Pro from 2016 wasn’t used during the sharing process, but after the Desaster started I disabled tab groups on safari settings in hopes of conserving the tab group without the multiplies on my MacBook. On my MacBook i opened safari and clicked on the shared Tabgroups whereat a warning poped up that MacOsx 13 or later is required for using shared tabgroups nonetheless all tabs are multiplied… please help 😀
Since probably the late iOS 17.4.x, 17.5.1 and still now in 17.6 beta our extension has been experiencing issues with the accompanying background script or service worker being permanently killed with no warning after about 30-45 seconds after initial installation (installation, not page load!).
In all other browsers (including Safari on MacOS) unloading the service worker is part of the normal lifecycle to save memory and CPU if it is idle. In our extension the service worker is used only during the first 5-10 seconds of every page visit, so we are used to seeing it unload after that and consider this a good thing. However, normally, the service worker is able to wake back up when needed - which is no longer the case in iOS.
Once dead, nothing a normal user would do can wake the service worker back up:
No events like webNavigation or similar will trigger anymore
Any attempt to call sendMessage to it from a content-script also does not wake up the service worker and instead returns undefined to the content script immediately
Closing and opening Safari does not start it again
The only two things that will give the service worker another 30-40 seconds of life is a reboot of the device or disabling and then re-enabling the extension. During those few second the extension is working perfectly.
There are no errors or indications in the logs of what is going on and the extension works just fine in Chrome, Firefox, Edge as well as Safari on MacOS and Safari in the Mobile simulator. Only actual iOS devices fail.
It seems like a temporary workaround is to change the manifest to not load the service worker as a service worker by changing
"background": {
"service_worker": "service.js"
}
to
"background": {
"scripts": ["service.js"],
"persistent": false
}
With this change (courtesy of https://forums.developer.apple.com/forums/thread/721222) the service worker is still unloaded but correctly starts up again when needed. Having to make this change does not seem to be consistent with manifest v3 specs though (see this part in Chrome’s migration guide as an example: https://developer.chrome.com/docs/extensions/develop/migrate/to-service-workers#update-bg-field).
According to the release notes of 17.6 beta this bug was supposedly fixed:
“Fixed an issue where Safari Web Extension background pages would stop responding after about 30 seconds. (127681420)”
However, this bug is not fixed - or at least not entirely fixed. It seems to work better for super simple tests doing nothing but pinging the service worker from the content script, but for the full blown extension there is no difference at all between 17.5.1 and 17.6.
Has there been a change in policy about service workers and background scripts for Safari in iOS?
Are anyone else seeing this issue?
Also seemingly related:
https://forums.developer.apple.com/forums/thread/756309
https://forums.developer.apple.com/forums/thread/750330
https://developer.apple.com/forums/thread/757926
https://forums.developer.apple.com/forums/thread/735307
Hello,
I've encoutered an issue with Safari App Extensions. My extension prints lots of suspect error logs in the Xcode console and inside Console.app. This happens basically whenever I make any interaction with the App Extension or with Safari. The most common and predictable error log I get is:
No current extension context; trying most recent context
(Subsystem: com.apple.SafariServices)
However, I also sometimes get the following error messages, albeit less frequently, which may be related:
No extension context for best match
No extension context for remote object
Error connecting back to host for remote object: NSCocoaErrorDomain, code: 4099
No known extension contexts for profile 00000000-0000-0000-0000-000000000000
Most recent extension context B7223E12-B563-45E0-97F8-50500BC6B994 does not have connection back to host; trying best match context
I haven't been able to find anything about these error logs in Apple documentation or on the Internet, so I did a bit of empirical investigation.
I reproduced the bug in the following basic scenario: I've created a new Safari App Extension project in Xcode by going to File > New > Project > Safari Extension App. I've selected "Safari App extension" for the type and "Swift" for the language. The project comes by default with a "SafariExtensionHandler.swift" file, which includes the following code:
override func validateToolbarItem(in window: SFSafariWindow, validationHandler: @escaping ((Bool, String) -> Void)) {
validationHandler(true, "")
}
No issues so far.
If I add the following call:
override func validateToolbarItem(in window: SFSafariWindow, validationHandler: @escaping ((Bool, String) -> Void)) {
validationHandler(true, "")
SFSafariApplication.getActiveWindow { window in
// code
}
}
There are still no error messages logged in the Console.
However, if I do this instead:
override func validateToolbarItem(in window: SFSafariWindow, validationHandler: @escaping ((Bool, String) -> Void)) {
validationHandler(true, "")
DispatchQueue.main.async {
SFSafariApplication.getActiveWindow { window in
// code
}
}
}
Then my Xcode console starts being spammed with "No current extension context; trying most recent context" error logs.
With some more testing, it seems that the most common/predictable situation that causes the error log seems to be when calling any Safari API (e.g. SFSafariApplication.getActiveWindow{} or even SFSafariApplication.setToolbarItemsNeedUpdate()) outside of a direct method call provided by the Safari App Extension API. So making API calls directly from inside validateToolbarItem(in:, validationHandler:) or messageReceived(withName:from:userInfo:) calls is fine, but anything else causes "No extension context" logs. The bug even reproduces if you make a Safari API call directly inside of an @IBAction method call caused by a button click inside the Safari popover of the Safari App Extension.
With this being the case, it seems to be impossible to make clean Safari API calls in an asynchronous or proactive way, which is problematic for our app extension use case and which seems to defeat the purpose of some of the API calls like SFSafariApplication.setToolbarItemsNeedUpdate(). Also, this seems to be a new issue.
I've tested these scenarios on various macOS versions that I had on hand (specifically, on macOS 10.15 Catalina, macOS 13 Ventura and macOS 14 Sonoma) and the bug seems to reproduce only on macOS 14 Sonoma. The Safari App Extension behaves as expected on previous macOS versions, with no suspect error logs.
Does anyone know what this issue is about?
Hello there!
At our company we have started to deal with an issue in the latest iOS (17.5) version.
It looks like the background script of the extension becomes unresponsive after a short amount of time (around 30 seconds) after performing more than one request to it within a range of 1 - 4 seconds.
How it can be tested? Pretty simple example:
// content.js
const t = 4000 // Using less than 4000ms makes background script unresponsive
async function requestNext() {
return browser.runtime.sendMessage({ greeting: "getNext" })
}
setInterval(async () => {
const n = await requestNext()
console.log("current is: " + n)
}, 4000)
// background.js
let counter = 0
browser.runtime.onMessage.addListener((request, sender, sendResponse) => {
console.log("Received request: ", request);
if (request.greeting === "getNext") {
counter++
sendResponse(counter);
return true
}
});
Whenever the browser.runtime.sendMessage is executed too fast the background script will stop working.
As far as we have been able to check this only can be reproduced after 17.4.1
I had to close all application vs code xcode simulator and reboot everything and it started working.
Thanks!
I have integrated the Safari Content Blocking extension, and it works perfectly on the first run, effectively blocking content on Safari. However, after re-installing the app, I occasionally encounter the following error, despite the content blocker functioning as expected:
"Failed to reload content blocker Error Domain=SFErrorDomain Code=3 "(null)""
What could be causing this intermittent error?
Hi,
I know it's currently possible to import a virtual debit/credit card from a mobile app into the IOS Wallet using PassKit from the Apple SDK, but I haven't seen any documentation to do it directly from a web app, could you please tell me if it is possible to do it directly from a web app without using a mobile app?
And if so, point me to some documentation?
Thanks in advance
Thank you again for pushing the web forward in VisionOS 2, super exciting!
The latest WWDC24 video touched on VR experiences for VisionOS2.0 using WebXR, however there was no mention of passthrough AR experiences.
Samples such as this one are not supported:
https://immersive-web.github.io/webxr-samples/immersive-ar-session.html
In Settings > Safari, there is a feature flag for the AR WebXR module, but enabling it did not seem to change anything.
Is this the expected behavior at this time? Any developer preview(s) we could try?