Hey,
very strange problem I have on iOS when shared web as an app (pwa) to home screen.
Whenever I use it via safari browser on iPhone, it works 100% fine every time. However, when I put it as an app on home screen, first time I open it it works fine, when i close it and reopen again, it just doesnt start recording. I have to restart my phone for it to work. So it works one time, I guess somehow it doesnt end stream or something, but in code I've tried all the possible ways to close and clean the track. tried GPT, Claude, Gemini solutions. nothing worked, it just works 1 time as PWA. my last hope is someone else encountered this issue and may try to help me ?
https://pastebin.com/85i2L2vH
Explore the integration of web technologies within your app. Discuss building web-based apps, leveraging Safari functionalities, and integrating with web services.
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
I'm creating an iPad app using Xcode 26 Beta 6. I have the following simple code and web page, but when I tap the file selection button, nothing appears. Do I need to add any additional code?
code
struct SwiftUIWebView: View {
@State private var webPage = WebPage()
private let url = URL(string: "https://www.xxxx.com/")!
var body: some View {
WebView(webPage)
.onAppear {
webPage.load(URLRequest(url: url))
}
}
}
web page
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>Test</title>
</style>
</head>
<body>
<div id="container">
<input type="file" />
</div>
</body>
</html>
If we use webView.loadFileURL(indexURL, allowingReadAccessTo: readAccessURL) on an iPad it loads the data and navigation works.
But if we place two hands on top of the screen and move a bit, all click events are not working anymore.
It works again if we call loadFileURL again.
We filled a bug report:
FB19812304
Hi everyone,
We’ve recently run into an issue with Apple Pay on the web and would appreciate some clarification.
Background:
Previously, we integrated Apple Pay without using the Apple Pay JS SDK.
We relied on ApplePaySession.canMakePayments() to check availability, and it worked fine.
After Apple announced support for browsers beyond Safari, we switched to the Apple Pay JS SDK.
According to Apple’s documentation, we should now use applePayCapabilities() for capability checks in third-party browsers.
Our current behavior:
We implemented applePayCapabilities().
Initially, it was returning either paymentCredentialStatusUnknown or paymentCredentialsUnavailable.
Based on those values, we displayed the Apple Pay button.
The problem:
About a week ago, on the same device/browser, applePayCapabilities() started returning applePayUnsupported.
Setup: MacBook Pro 13-inch (M1, 2020), Google Chrome Version 136.0.7103.93.
The Apple documentation says: “Don’t show an Apple Pay button or offer Apple Pay” when the result is applePayUnsupported.
However, at the same time, canMakePayments() is returning true.
This creates a direct conflict between the two recommendations:
canMakePayments() → true ⇒ show the button.
applePayCapabilities() → applePayUnsupported ⇒ don’t show the button.
Question:
What’s the correct approach here?
Should we prioritize applePayCapabilities() and hide the button, or is it acceptable to continue relying only on canMakePayments() as the source of truth for showing Apple Pay?
Any insights from others who’ve run into this contradiction would be very helpful.
Thanks in advance!
Can anyone of Apple give a status update whats planed with CC module scripts?
Issue: https://bugs.webkit.org/show_bug.cgi?id=227967
Topic:
Safari & Web
SubTopic:
General
Our UI-less share extension (com.apple.services) appears in Safari and Chrome. We raise a popup "Open in (app)..." via the Action.js script document.location.href = urlScheme://... in Safari.
However, in Chrome, while our extension executes, parses the URL item attachment from Chrome, it never triggers that popup or opens our app.
How can a UI-less share extension open our app from Chrome?
Is the accepted practice, despite guidelines, turning the com.apple.ui-services view controller invisible and auto-openURLing? Several apps on the store appear to do this, immediately popping their app without any confirmation dialog or UI in both Safari and Chrome. https://stackoverflow.com/a/79369242
On iOS 26 Beta, WKWebView consistently crashes when interacting with pages that use -webkit-user-select: none.
This issue does not reproduce in Safari, but only when the same content is loaded inside a WKWebView.
Steps to Reproduce:
Install iOS 26 Beta.
Open a WKWebView that loads a webpage with the following style applied globally:
-webkit-user-select: none;
Perform the following gesture sequence inside the WKWebView:
Double tap anywhere in the web content.
On the second tap, keep your finger pressed (do not lift).
While still holding the second tap, drag your finger across the screen (pan).
This sequence reliably produces the crash.
Expected Result:
No crash. The gesture should either be ignored or handled gracefully.
Actual Result:
The app crashes 100% of the time with the following exception:
#0 0x000000013f1a0874 in __pthread_kill ()
#1 0x00000001357522ec in pthread_kill ()
#2 0x00000001801ad950 in abort ()
#3 0x00000001802fa26c in __abort_message ()
#4 0x00000001802ea1a4 in demangling_terminate_handler ()
#5 0x0000000180077218 in _objc_terminate ()
#6 0x00000001802f9758 in std::__terminate ()
#7 0x00000001802fc7c0 in __cxxabiv1::failed_throw ()
#8 0x00000001802fc7a0 in __cxa_throw ()
#9 0x000000018009c1bc in objc_exception_throw ()
#10 0x00000001804f38f8 in +[NSException raise:format:] ()
#11 0x000000018c5fb570 in -[CALayer setPosition:] ()
#12 0x0000000185d02414 in -[UIView _backing_setPosition:] ()
#13 0x00000001867ec978 in -[UIView setCenter:] ()
#14 0x0000000186666468 in -[_UIEditMenuContentPresentation _displayPreparedMenu:titleView:reason:didDismissMenu:configuration:] ()
#15 0x0000000186666088 in __54-[_UIEditMenuContentPresentation _displayMenu:reason:]_block_invoke ()
#16 0x00000001867b3ed4 in -[UIEditMenuInteraction _editMenuPresentation:preparedMenuForDisplay:completion:] ()
#17 0x0000000186665fb0 in -[_UIEditMenuContentPresentation _displayMenu:reason:] ()
#18 0x0000000186665de4 in -[_UIEditMenuContentPresentation displayMenu:configuration:] ()
#19 0x00000001867b3260 in __58-[UIEditMenuInteraction presentEditMenuWithConfiguration:]_block_invoke ()
#20 0x00000001867b4c98 in __80-[UIEditMenuInteraction _prepareMenuAtLocation:configuration:completionHandler:]_block_invoke ()
#21 0x000000018653ff80 in __109-[UITextContextMenuInteraction _editMenuInteraction:menuForConfiguration:suggestedActions:completionHandler:]_block_invoke ()
#22 0x0000000186540448 in __107-[UITextContextMenuInteraction _querySelectionCommandsForConfiguration:suggestedActions:completionHandler:]_block_invoke ()
#23 0x000000018dba84f8 in WTF::Detail::CallableWrapper<WTF::CompletionHandler<void (IPC::Connection*, IPC::Decoder*)> IPC::Connection::makeAsyncReplyCompletionHandler<Messages::WebPage::RequestDocumentEditingContext, WTF::CompletionHandler<void (WebKit::DocumentEditingContext&&)>>(WTF::CompletionHandler<void (WebKit::DocumentEditingContext&&)>&&, WTF::ThreadLikeAssertion)::'lambda'(IPC::Connection*, IPC::Decoder*), void, IPC::Connection*, IPC::Decoder*>::call ()
#24 0x000000018dca14cc in WTF::Detail::CallableWrapper<WebKit::AuxiliaryProcessProxy::sendMessage(WTF::UniqueRef<IPC::Encoder>&&, WTF::OptionSet<IPC::SendOption>, std::__1::optional<IPC::ConnectionAsyncReplyHandler>, WebKit::AuxiliaryProcessProxy::ShouldStartProcessThrottlerActivity)::$_1, void, IPC::Connection*, IPC::Decoder*>::call ()
#25 0x000000018e2d5c54 in IPC::Connection::dispatchMessage ()
#26 0x000000018e2d6118 in IPC::Connection::dispatchIncomingMessages ()
#27 0x00000001997f9c58 in WTF::RunLoop::performWork ()
#28 0x00000001997fa930 in WTF::RunLoop::performWork ()
#29 0x000000018044d4dc in __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ ()
#30 0x000000018044d424 in __CFRunLoopDoSource0 ()
#31 0x000000018044cc0c in __CFRunLoopDoSources0 ()
#32 0x000000018044bd84 in __CFRunLoopRun ()
#33 0x0000000180446e24 in _CFRunLoopRunSpecificWithOptions ()
#34 0x00000001924c19bc in GSEventRunModal ()
#35 0x00000001862217a8 in -[UIApplication _run] ()
#36 0x00000001862259d0 in UIApplicationMain ()
Same issues below.
https://developer.apple.com/forums/thread/796799
https://developer.apple.com/forums/thread/796501
https://developer.apple.com/forums/thread/796874
https://developer.apple.com/forums/thread/796686
Can someone please tell me which experimental WebKit feature would cause safari to keep timing out on certain sites with a lot of Java script due to heavy cpu drainage. I can provide analytics data if this helps.
Topic:
Safari & Web
SubTopic:
General
現在新しいWebViewを使ってwebページを読み込むiPadプログラムを作成中ですが、読み込んだ後に部分のボタンをタップしても何も起こりません。safariで通常通りページを開いてボタンをタップするときちんと写真ライブラリ・カメラで撮るなどのポップアップが表示されます。下記がコードです。Webページは単純化のためにのみを配置しています。
struct SwiftUIWebView: View {
@State private var webPage = WebPage()
private let url = URL(string: "https://www.****.com/")!
var body: some View {
WebView(webPage)
.onAppear {
// URLを読み込む
webPage.load(URLRequest(url: url))
}
}
}
何か追加のコードが必要なのでしょうか？
When practicing a post request today I forgot to use the setvalue method. Why is this method important and needed for a post request? Don't we just encode the data to JSON and put that as the httpbody and make the request
//Is my post method correct because google and claude are telling me I must use content type for the json and use .setvalue. I thought that my process was correct because I encode the data to turn into json and then make the request
func createTask(_ task: Task) async throws -> Task {
if let url = URL(string: "(baseURL)/todos"){
var request = URLRequest(url: url)
request.httpMethod = "POST"
let encoder = JSONEncoder()
do{
let data = try encoder.encode(task)
request.httpBody = data
let (data, response) = try await URLSession.shared.data(for: request)
return task
//we want to make encoder and then turn the data into json and put it in body
}
catch{
throw JSONErrors.encodingFailed
}
}
else{
throw URLError(.badURL)
}
}
Hello,
I am experiencing an issue when trying to open the browser on my Apple Watch SE 2 running the latest version, watchOS 11.6. When I attempt to visit any website, the browser opens and displays the URL at the top as if it is loading, but the screen remains black and no content is displayed.
The internet connection is available, and all other apps on the watch work normally. This issue occurs only with the browser.
I would appreciate any guidance or solution to resolve this problem.
Thank you for your assistance.
I am a developer from China. We hope to integrate "Sign in with Apple" into our website's web product. Is it possible to use a company-certified Apple developer account within China to create an application and provide login services for global Apple users?
Steps to Reproduce
1. Create a native UIViewController with a WKWebView, loading test-1.html (contains position:fixed header that displays correctly).
2. Push another UIViewController also with a WKWebView, this time loading test-2.html.
3. In test-2.html, tap into the to summon the on-screen keyboard.
4. Without calling blur(), perform an interactive swipe-back gesture to go back to the first view controller.
5. Observe that the fixed header in test-1.html is now offset downward by approximately the height of the keyboard and does not return to its original position.
demo-link : https://bugs.webkit.org/attachment.cgi?id=476324
Currently, im on MacOS Tahoe 26 Public Beta 2, build number 25A5327h. I just recently updated to this, and now, whenever I open some sites like Amazon, or ChatGPT, it freezes my entire browser and I have to force quit it. I tried deleting the SpeakSelection.plist file which everyone swore worked, but not for me. Is this because the new update messed with resource allocation or did my user data corrupt mid-update and i have to transfer all my stuff to a new user?
Topic:
Safari & Web
SubTopic:
General
{
"epochTimestamp": 1755169981033,
"expiresAt": 1755173581033,
"merchantSessionIdentifier": "SSH4ADF1D97A60B47FC8537037BE9892237_FF777A9CB5E9EDAB38A01E4EDF71CB5572F19153853DAC70ADC5AA3E75877CB4",
"nonce": "b6f1e016",
"merchantIdentifier": "7C52E6BFA112124092008236BE1EE49791E4E82E9082AD9AC98D55B03A088120",
"domainName": "1960-ikffk.checkout.trypeppr.com",
"displayName": "peppr",
"signature": "308006092a864886f70d010702a0803080020101310d300b0609608648016503040201308006092a864886f70d0107010000a080308203ee30820394a00302010202080e7210e510586e34300a06082a8648ce3d040302307a312e302c06035504030c254170706c65204170706c69636174696f6e20496e746567726174696f6e204341202d20473331263024060355040b0c1d4170706c652043657274696669636174696f6e20417574686f7269747931133011060355040a0c0a4170706c6520496e632e310b3009060355040613025553301e170d3231303131303032313632395a170d3236303130393032313632395a306b3131302f06035504030c286563632d736d702d62726f6b65722d7369676e5f5543342d50524f445f4b727970746f6e5f45434331143012060355040b0c0b694f532053797374656d7331133011060355040a0c0a4170706c6520496e632e310b30090603550406130255533059301306072a8648ce3d020106082a8648ce3d0301070342000466e0ea0e787dcb3f66bc533189da2bda08ed9574e421117aa1af2cc310f6a8b19ca3e77ed00fa84e8df2ac8688e529866e76ebad89eda5b7c336e0f0d8a7d05da38202113082020d300c0603551d130101ff04023000301f0603551d2304183016801423f249c44f93e4ef27e6c4f6286c3fa2bbfd2e4b304506082b0601050507010104393037303506082b060105050730018629687474703a2f2f6f6373702e6170706c652e636f6d2f6f63737030342d6170706c65616963613330323082011d0603551d2004820114308201103082010c06092a864886f7636405013081fe3081c306082b060105050702023081b60c81b352656c69616e6365206f6e207468697320636572746966696361746520627920616e7920706172747920617373756d657320616363657074616e6365206f6620746865207468656e206170706c696361626c65207374616e64617264207465726d7320616e6420636f6e646974696f6e73206f66207573652c20636572746966696361746520706f6c69637920616e642063657274696669636174696f6e2070726163746963652073746174656d656e74732e303606082b06010505070201162a687474703a2f2f7777772e6170706c652e636f6d2f6365727469666963617465617574686f726974792f30340603551d1f042d302b3029a027a0258623687474703a2f2f63726c2e6170706c652e636f6d2f6170706c6561696361332e63726c301d0603551d0e0416041457c735942abd9ea2feccd3cbe7ede0a37c8cc5fa300e0603551d0f0101ff040403020780300f06092a864886f76364061d04020500300a06082a8648ce3d0403020348003045022100f2fa622622128cd1e1642084bc4117ccdede7289690e864cfb88abb43e04338e022065f85a90b82711d1fd762e0b59c45496e9e683c265c8279998e37872feae46ec308202ee30820275a0030201020208496d2fbf3a98da97300a06082a8648ce3d0403023067311b301906035504030c124170706c6520526f6f74204341202d20473331263024060355040b0c1d4170706c652043657274696669636174696f6e20417574686f7269747931133011060355040a0c0a4170706c6520496e632e310b3009060355040613025553301e170d3134303530363233343633305a170d3239303530363233343633305a307a312e302c06035504030c254170706c65204170706c69636174696f6e20496e746567726174696f6e204341202d20473331263024060355040b0c1d4170706c652043657274696669636174696f6e20417574686f7269747931133011060355040a0c0a4170706c6520496e632e310b30090603550406130255533059301306072a8648ce3d020106082a8648ce3d03010703420004f017118419d76485d51a5e25810776e880a2efde7bae4de08dfc4b93e13356d5665b35ae22d097760d224e7bba08fd7617ce88cb76bb6670bec8e82984ff5445a381f73081f4304606082b06010505070101043a3038303606082b06010505073001862a687474703a2f2f6f6373702e6170706c652e636f6d2f6f63737030342d6170706c65726f6f7463616733301d0603551d0e0416041423f249c44f93e4ef27e6c4f6286c3fa2bbfd2e4b300f0603551d130101ff040530030101ff301f0603551d23041830168014bbb0dea15833889aa48a99debebdebafdacb24ab30370603551d1f0430302e302ca02aa0288626687474703a2f2f63726c2e6170706c652e636f6d2f6170706c65726f6f74636167332e63726c300e0603551d0f0101ff0404030201063010060a2a864886f7636406020e04020500300a06082a8648ce3d040302036700306402303acf7283511699b186fb35c356ca62bff417edd90f754da28ebef19c815e42b789f898f79b599f98d5410d8f9de9c2fe0230322dd54421b0a305776c5df3383b9067fd177c2c216d964fc6726982126f54f87a7d1b99cb9b0989216106990f09921d00003182018930820185020101308186307a312e302c06035504030c254170706c65204170706c69636174696f6e20496e746567726174696f6e204341202d20473331263024060355040b0c1d4170706c652043657274696669636174696f6e20417574686f7269747931133011060355040a0c0a4170706c6520496e632e310b300906035504061302555302080e7210e510586e34300b0609608648016503040201a08193301806092a864886f70d010903310b06092a864886f70d010701301c06092a864886f70d010905310f170d3235303831343131313330315a302806092a864886f70d010934311b3019300b0609608648016503040201a10a06082a8648ce3d040302302f06092a864886f70d010904312204209378ff57580c3205e9ea38d985a2e9ca2db7f06db29b7560f585561a23894402300a06082a8648ce3d04030204483046022100fad47e840779070d097ef91cd4bfa5381d77426071cb38c1cdc77ff9460ba1470221009215c246893bff0983052caaae610a16117237e73ab36d859008e7b234670eaa000000000000",
"operationalAnalyticsIdentifier": "peppr:7C52E6BFA112124092008236BE1EE49791E4E82E9082AD9AC98D55B03A088120",
"retries": 0,
"pspId": "7C52E6BFA112124092008236BE1EE49791E4E82E9082AD9AC98D55B03A088120"
}
This is generated in the onvalidatemerchant event handler, and passed into session.completeMerchantValidation.
Using a sandbox account with linked cards, the next thing that happens is a "payment not completed" message in the ApplePay popup on the page, and the oncancel event is hit
Inspecting the event, I don't see anything that hints at the issue. There is a sessionError object, but its code is "unknown" and the info object is empty.
Whenever I make a safari view controller on XCode26 Beta 5, there appears to be a blurry white overlay overtop the controller. This worked fine in XCode26 Beta 2, with no code differences.
Anyone have any suggestions?
We are experiencing an issue with Safari in all versions from 18.0 to 18.5 that does not occur in version 17. It affects both iPhones and Macs. And does not happen in Chrome or Windows.
The problem is impacting our customers, and our monitoring tools show a dramatic increase in error volume as more users buy/upgrade to iOS 18.
The issue relates to network connectivity that is lost randomly. I can reliably reproduce the issue online in production, as well as on my local development environment.
For example our website backoffice has a ping, that has a frequency of X seconds, or when user is doing actions like add to a cart increasing the quantity that requires backend validation with some specific frequency the issue is noticable...
To test this I ran a JS code to simulate a ping with a timer that calls a local-dev API (a probe that waits 2s to simulate "work") and delay the next HTTP requests with a dynamic value to simulate network conditions:
Note: To even make the issue more clear, I'm using GET with application/json payload to make the request not simple, and require a Pre-flight request, which doubles the issue.
(async () => {
for (let i = 0; i < 30; i++) {
try {
console.log(`Request start ${i} ${new Date().toLocaleString()}`);
const res = await fetch(`https://api.redated.com:8090/1/*****/probe?`, {
method: 'GET',
mode: "cors",
//headers: {'Content-Type': 'text/plain'},
headers: { 'Content-Type': 'application/json' },
});
console.log(`Request end ${i} ${new Date().toLocaleString()} status:`, res.status);
} catch (err) {
console.error(`Request ${i} ${new Date().toLocaleString()} error:`, err);
}
let delta = Math.floor(Math.random() * 10);
console.log("wait delta",delta);
await new Promise(r => setTimeout(r, 1000 - delta));
}
})();
For simplicity lets see a case where it fails 1 time only out of 10 requests.
(Adjusting the "delta" var on the time interval create more or less errors...)
This are the results:
The network connection was lost error, which is false, since this is on my localhost machine, but this happens many times and is very reproducible in local and production online.
The dev-tools and network tab shows empty for status error, ip, connection_id etc.. its like the request is being terminated very soon.
Later I did a detailed debugging with safari and wireshark to really nail down the network flow of the problem:
I will explain what this means:
Frame 10824 – 18:52:03.939197: new connection initiated (SYN, ACK, ECE).
Frame 10831 – 18:52:04.061531: Client sends payload (preflight request) to the server.
Frame 10959 – 18:52:09.207686: Server responds with data to (preflight response) to the client.
Frame 10960 – 18:52:09.207856: Client acknowledges (ACK) receipt of the preflight response.
Frame 10961 – 18:52:09.212188: Client sends the actual request payload after preflight OK and then server replies with ACK.
Frame 11092 – 18:52:14.332951: Server sends the final payload (main request response) to the client.
Frame 11093 – 18:52:14.333093: captures the client acknowledging the final server response, which marks the successful completion of the main request.
Frame 11146 – 18:52:15.348433: [IMPORTANT] the client attempts to send another new request just one second later, which is extremely close to the keep-alive timeout of 1 second. The last message from the server was at 18:52:14.332951, meaning the connection’s keep-alive timeout is predicted to end around 18:52:15.332951 but it does not. The new request is sent at 18:52:15.348433, just microseconds after the predicted timeout. The request leaves before the client browser knows the connection is closed, but by the time it arrives at the server, the connection is already dead.
Frame 11147 – 18:52:15.356910: Shows the server finally sending the FIN,ACK to indicate the connection is closed. This happens slightly later than the predicted time, at microsecond 356910 compared to the expected 332951. The FIN,ACK corresponds to sequence 1193 from the ACK of the last data packet in frame 11093.
Conclusions:
The root cause is related to network handling issues, when the server runs in a setting of keep-alive behavior and keep-alive timeout (in this case 1s) and network timming issue with Safari reusing a closed connection without retrying. In this situation the browser should retry the request, which is what other browsers do and what Safari did before version 18, since it did not suffer from this issue.
This behaviour must differ from previous Safari versions (however i read all the public change logs and could not related the regression change).
Also is more pronounced with HTTP/1.1 connections due to how the keep-alive is handled.
When the server is configured with a short keep-alive timeout of 1 second, and requests are sent at roughly one-second intervals, such as API pings at fixed intervals or user actions like incrementing a cart quantity that trigger backend calls where the probability of failure is high.
This effect is even more apparent when the request uses a preflight with POST because it doubles the chance, although GET requests are also affected.
This was a just a test case, but in real production our monitoring tools started to detect a big increment with this network error at scale, many requests per day... which is very disrupting, because user actions are randomly being dropped when the user actions and timming happens to be just near a previous connection, where keep alive timeout kicks-in, but because the browser is not yet notified it re-uses the same connection, but by the time it arrived the server is a dead connection. The safari just does nothing about it, does not even retry, be it a pre-flight or not, it just gives this error.
Other browsers don't have this issue.
Thanks!
I have a Net8 Maui WebView app and whenever I use magnifier, it crashes.
The magnifier works on iOS18 and lower but crashes on iOS26+
Exception
**Type:** CALayerInvalidGeometry
**Value:** CALayer position contains NaN: [nan 65]. Layer: <CALayer:0x123e88e40; position = CGPoint (0 0); bounds = CGRect (0 0; 0 48); delegate = <_UIEditMenuListView: 0x116f2f200; frame = (nan 0; 0 48); anchorPoint = (inf, 0); alpha = 0; layer = <CALayer: 0x123e88e40>>; sublayers = (<CALayer: 0x125232df0>, <CALayer: 0x123e88e70>); opaque = YES; allowsGroupOpacity = YES; anchorPoint = CGPoint (inf 0); opacity = 0>
Stacktrace
__exceptionPreprocess in unknown file [Line null, column null] (Not in app)
objc_exception_throw in unknown file [Line null, column null] (Not in app)
+[NSException raise:format:] in unknown file [Line null, column null] (Not in app)
CA::Layer::set_position in unknown file [Line null, column null] (Not in app)
-[CALayer setPosition:] in unknown file [Line null, column null] (Not in app)
-[UIView _backing_setPosition:] in unknown file [Line null, column null] (Not in app)
-[UIView setCenter:] in unknown file [Line null, column null] (Not in app)
-[_UIEditMenuContentPresentation _displayPreparedMenu:titleView:reason:didDismissMenu:configuration:] in unknown file [Line null, column null] (Not in app)
__54-[_UIEditMenuContentPresentation _displayMenu:reason:]_block_invoke in unknown file [Line null, column null] (Not in app)
-[UIEditMenuInteraction _editMenuPresentation:preparedMenuForDisplay:completion:] in unknown file [Line null, column null] (Not in app)
-[_UIEditMenuContentPresentation _displayMenu:reason:] in unknown file [Line null, column null] (Not in app)
-[_UIEditMenuContentPresentation displayMenu:configuration:] in unknown file [Line null, column null] (Not in app)
__58-[UIEditMenuInteraction presentEditMenuWithConfiguration:]_block_invoke in unknown file [Line null, column null] (Not in app)
__80-[UIEditMenuInteraction _prepareMenuAtLocation:configuration:completionHandler:]_block_invoke in unknown file [Line null, column null] (Not in app)
__109-[UITextContextMenuInteraction _editMenuInteraction:menuForConfiguration:suggestedActions:completionHandler:]_block_invoke in unknown file [Line null, column null] (Not in app)
__107-[UITextContextMenuInteraction _querySelectionCommandsForConfiguration:suggestedActions:completionHandler:]_block_invoke in unknown file [Line null, column null] (Not in app)
Topic:
Safari & Web
SubTopic:
General
Steps to Reproduce:
Open the Bing search page in Safari (example URL: https://www.bing.com/search?q=webkit&form=APIPH1&PC=APPL).
Pinch-zoom in or out, then return the page to exactly 100% zoom.
Rotate the device from portrait to landscape orientation.
Observe that the page is incorrectly scaled to a value other than 100%.
Rotate the device back to portrait orientation.
The page remains at the incorrect zoom level.
Expected Result:
After returning the page to 100% zoom, changing orientation should keep the zoom level at exactly 100% in both portrait and landscape modes.
Actual Result:
After returning to 100% zoom, rotating to landscape changes the zoom to a non-100% value, and rotating back to portrait retains the incorrect zoom level.