Hello Apple Developer Community, I'm experiencing an issue with PDF link interaction in WKWebView that appears to be specific to iOS 26. Problem Description: I'm loading a PDF in WKWebView.The links may vary widely and are not necessarily DPF, so I need to load them using WKWebView. On iOS versions prior to 26, links within the PDF are clickable and work correctly. On iOS 26, the same links are not clickable (no response when tapped). Expected Behavior: PDF links should remain clickable and functional across all iOS versions. What I've Tried: Tested opening the PDF directly in Safari on iOS 26 - links still not clickable This suggests the issue might be related to changes in the system's PDF rendering engine Reproduction Steps: Load the PDF URL in WKWebView Navigate to page 12 Attempt to tap the link Environment: Test Devices: iPhone 15(26.0 ) / iPhone 16 Pro Max(18.0.1 ) Xcode: 16.2 Questions: Is this an intentional change in iOS 26's PDF handling or WKWebView? If so, is there a new API or configuration to restore link interactivity? Any guidance or suggestions would be greatly appreciated!

This is my first time to post on this forum. If there are something we didn't notice, please tell me. Thanks. Background We're using canvas to provide a web component to marketing. https://demo.mescius.jp/spreadjs/BenchmarkSample/ Problem Recently we have met an issue from customer. He is using iPad 10th to access the web component but when he tries to scroll it and it's very slow on iPad 10th. His iPad OS version is 17.7 and this issue also can be reproduced on our iPad 10th with iPad OS 18.0.1. But if we use iPad 9th with iPad OS 17.7 and 18.0.1, things are fine and there isn't any performance issue. We developer took some time investigating and found it's because of iPad 10th's safari takes longer time to paint each frame. On iPad 9th, it needs nearly 10ms to paint each frame. But on iPad 10, it needs nearly 70ms to paint each frame. Also we can provide simple code for you to check the different. We tried to simulate the repaint when user is scrolling. You can see on iPad 9th, it will be 2~3ms but on iPad 10th, it will be more than 10ms for each frame. test-ipad10.html It has been happening on iPad 10th only with iPad OS 17.6/17.7/18.0. This will be a big problem for us because it means on the iPad 10th (the latest iPad, non Pro or Air), it can't be used. Question Is there anyone knowing similar issue with this one? And do you know how to solve it on iPad 10?

When CHIPS was introduced in 18.4 it worked well, however on 18.5 it does not appear to work. There do not appear to be release notes about this in 18.5, so can someone provide definitive if this is a defect that will be fixed, or have they already been deprecated?

I’m observing an intermittent issue with a Safari Web Extension on macOS 15.7 (Safari 26.0.1). After installing the Safari extension from the App Store, it appears under Settings → Extensions, but the enable checkbox is often missing. Sometimes, after restarting Safari multiple times, the checkbox becomes visible. However, even when I manage to enable the extension, reopening Safari often hides the checkbox again. However, I don't see this issue in safari 26 with macOS 26 I’d like to know if this behavior is a known issue with Safari 26 or macOS 15.7? Any workaround available?

Hello, I've got Smart App Banner set up on my website. However, I want to be able to measure the traffic coming from this banner to the app store / app (i.e. measure impressions/downloads). Apple documentation (https://developer.apple.com/help/app-store-connect/view-app-analytics/manage-campaigns/) says you can set up a campaign link and use it in the Smart Banner to track those who download / open the app store page using your smart banner (so that we can get attribution). However, there is no documentation at all in terms of how this should be added to the tag when implementing a Smart App Banner. I've tried so many different variations and none have tracked downloads. This includes a structure based on an example taken from WWDC from a few years back which also did not work. I would appreciate any help!

I'm a web developer of WebRTC based web app for video and audio calls. After updating to iOS 26.1 beta I noticed, that my app can't use microphone anymore. When I'm calling to getUserMedia with audio set to true, Safari returns error "No AVAudioSessionCaptureDevice device". Other WebRTC demo apps also can't access microphone on this firmware. And maybe it's connected somehow, but safari can't detect connected AirPods Pro 2 as an input device. So, this bug brakes any WebRTC app, that uses microphones.

The issue of fixed elements with { bottom: 0 } moving up when scrolling still persists. It seems to be a general issue with the IOS 26 release. It affects other browser too. I tested on browsers such as Safari, Chrome, Firefox, Edge and Bravo. With the exception of Edge, all the others display the behavior. Device: iPhone 15 Pro IOS Version: 26.0.1

Observed versions: Reproduced on Tahoe / Safari 26 and iOS 26 Safari. Not reproduced on v18 Safari. Not reproduced in Chrome with the same reduced test setup. We are seeing a Safari-only rendering issue affecting an ad creative inside an iframe on both desktop Safari and iOS Safari. What we observe: The issue is reproducible in Safari on OS X and iOS v26. We do not reproduce it in Chrome with the same test setup. We can reproduce it in a minimal test case, outside our site app code. The issue appears tied to the rendered iframe document/layout, not our outer page layout. The problematic rendered structure inside the iframe looks like this: <div class="GoogleActiveViewElement" style="display:inline"> <ins class="dcmads" style="display:inline-block;width:320px;height:50px"> <script src="https://www.googletagservices.com/dcm/dcmads.js"></script> </ins> </div> Here is a simplified, local-reproducible version for testing: <div class="GoogleActiveViewInnerContainer" style="left:0px; top:0px; width:100%; height:100%; position:fixed; pointer-events:none; z-index:-9999;"></div> <div class="GoogleActiveViewElement" style="display:inline"> <ins class="dcmads" style="display:inline-block;width:320px;height:50px"> <script> document.write( '<a target="_blank" href="#"><img ' + 'src="data:image/svg+xml;utf8,' + encodeURIComponent( '<svg xmlns="http://www.w3.org/2000/svg" width="320" height="50">' + '<rect width="320" height="50" fill="#ffd8d8"/>' + '<text x="160" y="30" text-anchor="middle" font-family="Arial" font-size="14" fill="#222">' + 'img placeholder' + '</text>' + '</svg>' ) + '" ' + ' alt="Advertisement" border="0" width="320" height="50" style="display:block" /></a>' ); </script> </ins> </div> In Safari, this produces extra vertical spacing / cutoff above the ad. In the test code you will only notice an added top spacing, but when rendered in a live ad, the bottom gets cut off. A few details that may help: If we manually change the inner ins.dcmads from display:inline-block to display:inline, or adding overflow:hidden, the spacing issue goes away. If the loader script is moved outside the ins during manual experimentation, the issue also goes away. This makes it look like a Safari layout/rendering issue involving an inline wrapper around an inline-block ad container during script-driven rendering. Questions: Is this a known Safari/WebKit layout issue involving inline + inline-block content in iframe documents? Has there been any recent Safari/WebKit change that could affect this rendering path? Is there a preferred reduced repro format for reporting layout issues like this?

Hello, After upgrading to macOS 26.2, I’ve noticed a significant performance regression when calling evaluateJavaScript in an iOS App running on Mac (WKWebView, Swift project). Observed behavior On macOS 26.2, the callback of evaluateJavaScript takes around 3 seconds to return. This happens not only for: evaluateJavaScript("navigator.userAgent") but also for simple or even empty scripts, for example: evaluateJavaScript("") On previous macOS versions, the same calls typically returned in ~200 ms. Additional testing I created a new, empty Objective-C project with a WKWebView and tested the same evaluateJavaScript calls. In the Objective-C project, the callback still returns in ~200 ms, even on macOS 26.2. Question Is this a known issue or regression related to: iOS Apps on Mac, Swift + WKWebView, or behavioral changes in evaluateJavaScript on macOS 26.2? Any information about known issues, internal changes, or recommended workarounds would be greatly appreciated. Thank you. Test Code Swift class ViewController: UIViewController { private var tmpWebView: WKWebView? override func viewDidLoad() { super.viewDidLoad() // Do any additional setup after loading the view. setupUserAgent() } func setupUserAgent() { let t1 = CACurrentMediaTime() tmpWebView = WKWebView(frame: .zero) tmpWebView?.isInspectable = true tmpWebView?.evaluateJavaScript("navigator.userAgent") { [weak self] result, error in let t2 = CACurrentMediaTime() print("[getUserAgent] \(t2 - t1)s") self?.tmpWebView = nil } } } Test Code Objective-C - (void)scene:(UIScene *)scene willConnectToSession:(UISceneSession *)session options:(UISceneConnectionOptions *)connectionOptions { NSTimeInterval startTime = [[NSDate date] timeIntervalSince1970]; WKWebView *webView = [[WKWebView alloc] init]; dispatch_async(dispatch_get_main_queue(), ^{ [webView evaluateJavaScript:@"navigator.userAgent" completionHandler:^(id result, NSError *error) { NSTimeInterval endTime = [[NSDate date] timeIntervalSince1970]; NSLog(@"[getUserAgent]: %.2f s", (endTime - startTime)); }]; }); }

According to our crash analytics, our application crashes while a context menu is opened on a web view. This crash takes place on iOS 26+ only. The messages states that a web view is no longer inside active window hierarchy, however we doesn't modify web view instance's parent anyhow while the context menu is opened. Can you please help with a fix or at least workaround for this issue? What's your opinion for bug localization (application or framework)? NSInternalInconsistencyException UIPreviewTarget requires that the container view is in a window, but it is not. (container: <WKTargetedPreviewContainer: 0x14b442840; name=Context Menu Hint Preview Container>) userInfo: { NSAssertFile = "UITargetedPreview.m"; NSAssertLine = 64; } Crashed: CrBrowserMain 0 CoreFoundation __exceptionPreprocess + 164 1 libobjc.A.dylib objc_exception_throw + 88 2 Foundation -[NSMutableDictionary(NSMutableDictionary) initWithContentsOfFile:] + 0 3 UIKitCore -[UIPreviewTarget initWithContainer:center:transform:] + 660 4 UIKitCore (Missing) 5 UIKitCore (Missing) 6 UIKitCore (Missing) 7 UIKitCore (Missing) 8 UIKitCore (Missing) 9 UIKitCore -[_UIContextMenuPresentation present] + 56 10 UIKitCore +[UIView(UIViewAnimationWithBlocksPrivate) _modifyAnimationsWithPreferredFrameRateRange:updateReason:animations:] + 168 11 UIKitCore (Missing) 12 UIKitCore (Missing) 13 UIKitCore (Missing) 14 UIKitCore (Missing) 15 UIKitCore +[UIView(UIViewAnimationWithBlocks) _setupAnimationWithDuration:delay:view:options:factory:animations:start:animationStateGenerator:completion:] + 516 16 UIKitCore (Missing) 17 UIKitCore (Missing) 18 UIKitCore +[UIView __animateUsingSpringWithDampingRatio:response:interactive:initialDampingRatio:initialResponse:dampingRatioSmoothing:responseSmoothing:targetSmoothing:projectionDeceleration:retargetImpulse:animations:completion:] + 192 19 UIKitCore -[_UIRapidClickPresentationAssistant _animateUsingFluidSpringWithType:animations:completion:] + 316 20 UIKitCore -[_UIRapidClickPresentationAssistant _performPresentationAnimationsFromViewController:] + 516 21 UIKitCore -[_UIRapidClickPresentationAssistant presentFromSourcePreview:lifecycleCompletion:] + 400 22 UIKitCore __55-[_UIClickPresentationInteraction _performPresentation]_block_invoke_3 + 48 23 UIKitCore +[UIViewController _performWithoutDeferringTransitionsAllowingAnimation:actions:] + 140 24 UIKitCore __55-[_UIClickPresentationInteraction _performPresentation]_block_invoke_2 + 144 25 UIKitCore -[_UIClickPresentationInteraction _performPresentation] + 836 26 UIKitCore postPreviewTransition_block_invoke_2 + 104 27 UIKitCore handleEvent + 256 28 UIKitCore -[_UIClickPresentationInteraction _driverClickedUp] + 48 29 UIKitCore -[_UIClickPresentationInteraction clickDriver:didPerformEvent:] + 400 30 UIKitCore stateMachineSpec_block_invoke_5 + 48 31 UIKitCore handleEvent + 144 32 UIKitCore -[_UILongPressClickInteractionDriver _handleGestureRecognizer:] + 140 33 UIKitCore -[UIGestureRecognizerTarget _sendActionWithGestureRecognizer:] + 128 34 UIKitCore _UIGestureRecognizerSendTargetActions + 268 35 UIKitCore _UIGestureRecognizerSendActions + 268 36 UIKitCore -[UIGestureRecognizer _updateGestureForActiveEvents] + 308 37 UIKitCore -[UIGestureRecognizer gestureNode:didUpdatePhase:] + 300 38 Gestures (Missing) 39 Gestures (Missing) 40 Gestures (Missing) 41 Gestures (Missing) 42 UIKitCore -[UIGestureEnvironment _updateForEvent:window:] + 528 43 UIKitCore -[UIWindow sendEvent:] + 2924 44 UIKitCore -[UIApplication sendEvent:] + 396

Our app, VitalSource Bookshelf, is an EPUB reader that uses a WKWebView to display book content. The EPUB content format is XHTML and uses namespaces (for the epub:type declaration). On beta 4, the webkit process repeatedly crashes when loading our content. The crash appears to be in the XML parser. Here's what's at the top of the stack trace: 0 WebCore 0x19166a878 WebCore::XMLDocumentParser::startElementNs(unsigned char const*, unsigned char const*, unsigned char const*, int, unsigned char const**, int, int, unsigned char const**) + 4968 1 libxml2.2.dylib 0x19c5a2bd0 xmlParseStartTag2 + 3940 2 libxml2.2.dylib 0x19c59e730 xmlParseTryOrFinish + 2984 3 libxml2.2.dylib 0x19c59d8e4 xmlParseChunk + 708 4 WebCore 0x191668ec8 WebCore::XMLDocumentParser::doWrite(WTF::String const&) + 636 5 WebCore 0x191665b78 WebCore::XMLDocumentParser::append(WTF::RefPtr<WTF::StringImpl, WTF::RawPtrTraits<WTF::StringImpl>, WTF::DefaultRefDerefTraits<WTF::StringImpl>>&&) + 304 6 WebCore 0x190105db0 WebCore::DecodedDataDocumentParser::appendBytes(WebCore::DocumentWriter&, std::__1::span<unsigned char const, 18446744073709551615ul>) + 268 7 WebCore 0x190861c3c WebCore::DocumentLoader::commitData(WebCore::SharedBuffer const&) + 1488 8 WebKit 0x18e07ca3c WebKit::WebLocalFrameLoaderClient::committedLoad(WebCore::DocumentLoader*, WebCore::SharedBuffer const&) + 52 9 WebCore 0x190869db4 WebCore::DocumentLoader::commitLoad(WebCore::SharedBuffer const&) + 228 10 WebCore 0x1909521e4 WebCore::CachedRawResource::notifyClientsDataWasReceived(WebCore::SharedBuffer const&) + 268 I was able to reproduce this in Safari on beta 4 just by opening the following trivial xhtml file from the file system - it does the same thing it does in our app, which is reloads and crashes several times, followed by the "A problem repeatedly occurred with..." error message. <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE html> <html xmlns="http://www.w3.org/1999/xhtml" xmlns:epub="http://www.idpf.org/2007/ops" epub:prefix="vst: http://vitalsource.com/"><head></head><body class="dash" epub:type="chapter" data-begin-o="0" data-begin-o2="0" data-begin-o3="0" data-o="0" id="eid1844" data-end-o="14703" data-end-o2="14703" data-end-o3="14703"><h2 class="title" data-o="0" id="eid1845" data-out="33"><span class="label" data-o="0" id="eid1846"><span class="label-inner"><b data-o="0" id="eid1847">CHAPTER X</b> </span></span>THE SUBMARINE COAL-MINES</h2></body></html> I've also filed a feedback. But posting here just to raise the visibility - this is critical for us. I think it was introduced in beta 4; that's at least when we first noticed it. It was working in the earlier betas, I just don't remember if I tried beta 3 or not. It happens on iOS, macOS, and iPadOS. This has never been a problem in any earlier release of macOS / iOS.

Hi, I am developing an OpenType font with the following cursive feature. feature curs { lookup cursivejoinrtl; # RIGHT_TO_LEFT flag set between Hah, Meem, Yeh and final Meem lookup rehwawcursive; # RIGHT_TO_LEFT flag clear between Waw and Hah } curs; Here is the rendering of the word وحميم in TextEdit. Using HarfBuzz I got the following result. The same rendering problem occurs when using Safari. It seems that is related to Core Text. I reported the issue to Feedback Assistant over a year ago but haven't had a response yet. So I'm posting the problem on this forum. Any support on this matter would be greatly appreciated.

Dear Apple Product Team, I would like to propose a usability enhancement for Safari on iOS that, in my opinion, would significantly improve the user experience. Current Situation: Currently, to change the default search engine in Safari, users must navigate to Settings → Safari → Search Engine, select their preferred option, and return to browsing. This workflow requires multiple taps and interrupts the user's flow. Proposed Solution: Add a quick search engine selector to the bottom toolbar in Safari (adjacent to the Smart Search field). Tapping this control would display a compact menu allowing users to instantly switch between available search engines (Google, DuckDuckGo, Bing, Yahoo, Ecosia, etc.) without leaving the browser. Key Benefits: ⚡️ Time-saving: Instant switching without navigating through Settings 🎯 Flexibility: Use different search engines for different query types (e.g., DuckDuckGo for privacy, Google for local results) 📱 Intuitive UX: Consistent with iOS design patterns and gesture-based navigation 🔧 Enhanced productivity: Streamlines research workflows for power users Implementation Suggestion: Long-press or tap-and-hold on the search field could trigger the selector Alternatively, a small chevron/icon next to the search field could open the menu Selected engine could persist per-tab or session-based, based on user preference I believe this feature aligns with Apple's commitment to privacy, efficiency, and user-centric design. Thank you for considering this suggestion for future iOS releases.

Hello. I am using Cordova Webview to select a photo from the album, save it locally, and then pass the saved path to the web for display. It displayed correctly up to OS 26.3.x, but starting from OS 26.4.x, I am unable to retrieve images from local paths. Part displayed in Cordova Webview I have also confirmed the existence of the corresponding file in the src path. Are there any known bugs or solutions? Thank you.

Summary When an app is associated with a domain via applinks in the Apple App Site Association (AASA) file, the app's icon is displayed next to passkey entries in the iOS passkey selection UI (e.g., in Safari's sign-in dialog). This occurs even when: The AASA file does not contain a webcredentials section The passkey's relying party ID (rp.id) matches the domain, but the app has no webcredentials association The URL path of the passkey login page does not match any paths specified in the applinks configuration Environment iOS 18.6.2 iPhone 16 Pro Safari / Passkey UI via WebAuthn Steps to Reproduce Create an iOS app and register it in App Store Connect (or distribute via TestFlight) Configure the AASA file on the domain with only applinks — no webcredentials section: json{ "applinks": { "apps": [], "details": [ { "appIDs": ["TEAMID.com.example.myapp"], "components": [ { "/": "/specific-path/*" } ] } ] } } Implement WebAuthn/passkey registration on the same domain with the domain as rp.id Install the app on the device (via TestFlight or App Store) Register a passkey on the website via Safari Navigate to the login page and trigger the passkey selection UI Expected Behavior Since webcredentials is not configured in the AASA file, the passkey selection UI should NOT display the app icon next to the passkey entry. The passkey icon should be the default website favicon or a generic icon. Actual Behavior The app icon (from App Store Connect / TestFlight) is displayed next to the passkey entry in the selection UI, even though: Only applinks is configured (no webcredentials) The current page URL does not match any paths in the applinks configuration Impact In our production environment, we have a single domain serving multiple partner bank apps. The AASA file contains applinks entries for many different apps (20+ partner apps). When a user accesses the passkey login page, the passkey UI may display an app icon from one of these partner apps, which can be confusing for users — especially if the displayed icon belongs to a different partner's app than the one the user intends to use. Questions Is this the intended behavior — that applinks associations influence the passkey UI icon display? Is there a way to prevent applinks associations from affecting the passkey selection UI without removing the applinks entries? Would adding a proper webcredentials section with the correct app ID override the icon source from applinks to webcredentials? Is there a recommended approach for domains that serve multiple apps via applinks but want to control which icon appears in the passkey UI?

I'm not loving the huge Favorites icons in Safari on MacOS 26, is there a way to reduce the size of them so that we can see more favorites on the list without scrolling down?

I have an app which has at least two extensions: A Content Blocker extension with a request handler that returns an appropriate NSExtensionItem as part of beginRequest. A different file URL is returned depending upon if the content blocking is on or off by a user setting A Safari Web Extension that includes a toolbar button and popover that enables users to enable or disable the ad blocking of the content blocker extension All three targets (App, Content Blocker appex and Web Extension appex) use an App Group default to read and set the on or off status of the content blocking. When the user changes the content blocking status, the app group default is updated and SFContentBlockerManager.reloadContentBlocker(...) is called. The Content Blocker extension reads the default and then returns the appropriate file URL. The issue is, I have noticed that whenever SFContentBlockerManager.reloadContentBlocker(...) is called from the app, Safari always applies the correct rules from the returned file URL. However sometimes when SFContentBlockerManager.reloadContentBlocker(...) is called from the Safari Web Extension using native messaging, Safari does NOT apply the correct rules from the returned file URL. Using logging I have confirmed that the Content Blocker extension always returns the appropriate file URL irrespective if called as a result of the app or the web extension. Despite this, Safari does not seem to always apply the returned file URL rules when it is called from the Safari Web Extension appex. In these cases, quitting Safari and relaunching it seems to make it apply the rules correctly (obviously this is applying it due to its launch state, not due to the Web extension appex asking it to do so at that point). All targets have access to the App Group location where the active content blocking file URL belongs and the inactive content blocking file URL is within the Safari content blocker target as a resource. I don't think this is a memory status issue as I cannot see the Content Blocker extension being killed when it returns complex rules --- the fact it always works when called via the app also seems to rule this possibility out. This brings up a number of questions: Is calling SFContentBlockerManager.reloadContentBlocker(...) from a different appex, of the same app target and app group supported? (it seems to work sometimes and did work in previous versions of the app). Is there an issue that the Content Blocker extension sometimes returns a file URL that perhaps the calling Web Extension appex may not have access to (even though Safari should via the Content Blocker extension)? Any other ideas of why this may not be working correctly? Has anyone else experienced this? It seems to happen on both iOS and macOS Safari using the same codebase.

Hello - we have a Mac application that uses a browser extension and the web extension JS APIs to communicate with Safari. During user testing we found that the tab title and tab URL properties are empty when obtaining the set of open windows via windows.get() after a Safari restart. We are testing with Safari 18.4 (20621.1.15.11.10). We have made a TestFlight version of our app and extension available to help with testing: https://testflight.apple.com/join/Va8Zdv9d. Screenshot and screen recording are attached to the Feedback ID supplied below. STEPS TO REPRODUCE Install Tabby via the TestFlight link Enable the Tabby for Safari extension in the Safari extensions dialog Grant permissions for Tabby for Safari to all windows all the time Within Safari, open two windows each with at least two tabs Within the Tabby app, ensure you see the windows and tabs listed correctly (tab title displayed for each) Quit and restart Safari Expected behavior Safari re-opens existing windows and Tabby displays title for each tab Observed Safari re-opens existing windows but within Tabby all tabs except the current tab are displayed with a title of “Start Page”. Under the hood the tab title and tab URL properties are empty when returned via a windows.get() call after Safari restarts. NAME AND APPLE ID OF APP Tabby - Browser Tab Manager 1586203406 FEEDBACK ASSISTANT ID FB16389506

Safari on iOS 17, when entering characters into text input box after deleting characters, the layout is off. Here's the HTML: <body> <div id="J001" style="display: inline-block;"> <div id="J001__0" style="display: inline-block;"> <input id="J001__0__input" style="display: inline-block; height: 28px; padding:2px; border:1px solid gray;"></div> <div id="J003__0" style="display: inline-block;"> <button id="J003__0__btn" style="display: inline-block; height:34px;">a</button> </div> </div> </body> Enter "A" into text input box. Delete "A" with the backspace(x). Enter "A" into text input box, the button position will be shifted down. iOS 17 の Safari にて、テキスト入力ボックスで文字を削除した後、文字を入力するとレイアウトが崩れます。 テキスト入力ボックスに「A」と入力します。 バックスペース(x)で「A」を削除します。 テキスト入力ボックスに「A」と入力すると、ボタンの位置が下にずれます。

I'm encountering an issue with front camera video recordings via browser (Safari/Chrome) on devices running iOS/iPadOS 18 and above: On iPad, the recorded video appears upside down. On iPhone, the recorded video is rotated 90 degrees. The rear camera functions correctly without orientation issues. This problem seems specific to browser-based recordings, as the native Camera app records videos with the correct orientation. Has anyone else experienced this behavior? Is there a known workaround or fix? The preview while recording is fine, the recorded video is oriented incorrectly.