Reproducibility 100% on iOS 15.4 and iOS 16.6 Zero crash on iOS 18.6 Xcode 26.1 Steps to Reproduce Xcode 26.1 → New iOS App Replace ViewController.swift with the 20-line code below Run on real device • iPhone XR iOS 15.4 • iPhone 13 iOS 16.6 Tap the link → breakpoint in decidePolicyFor lldb → po navigationAction.sourceFrame Actual Result (lldb) po navigationAction.sourceFrame nil Swift declaration lies: public var sourceFrame: WKFrameInfo { get } // non-optional → Instant EXC_BREAKPOINT libswiftFoundation.dylib`URLRequest._unconditionallyBridgeFromObjectiveC Objective-C tells the truth: po [(WKNavigationAction *)navigationAction fixedSourceFrame] nil iOS 18.6 → same code prints a valid WKFrameInfo, no crash. Expected sourceFrame must be declared WKFrameInfo? in Swift or at least documented “can be nil on iOS 15–16”. Impact Every WKWebView app that touches sourceFrame on iOS 15.4 & 16.6 ships with a latent crash. Production Workaround @implementation WKNavigationAction (Safe) (WKFrameInfo *)fixedSourceFrame { return self.sourceFrame ? self.sourceFrame : nil; } @end Minimal Test (copy-paste) import UIKit import WebKit class ViewController: UIViewController, WKNavigationDelegate { lazy var web = WKWebView(frame: view.bounds) override func viewDidLoad() { super.viewDidLoad() web.navigationDelegate = self view.addSubview(web) web.load(URLRequest(url: URL(string: "https://www.apple.com")!)) } func webView(_ webView: WKWebView, decidePolicyFor navigationAction: WKNavigationAction, preferences: WKWebpagePreferences, decisionHandler: @escaping (WKNavigationActionPolicy, WKWebpagePreferences)->Void) { print(navigationAction.sourceFrame) // ← crashes on 15.4 & 16.6 decisionHandler(.allow, preferences) } }

Such a simple piece of code: import SwiftUI import WebKit struct ContentView: View { var body: some View { WebView(url: URL(string: "https://www.apple.com")) } } When I run this, the web content shows under the top notch’s safe area, and buttons inside that region aren’t tappable. I tried a bunch of things and the only “fix” that seems to work is .padding(.top, 1), but that leaves a noticeable white strip in non-portrait orientations. What’s the proper way to solve this? Safari handles the safe area correctly and doesn’t render content there.

Hello We've encountered an issue with WKWebView in the latest iOS 26 beta. When loading a PDF URL, the background of the PDF viewer now displays as a dark gray instead of the expected white. Device: iOS 26 Simulator/Device Component: WKWebView Issue: The background color of the loaded PDF is gray. Expected Behavior: The background should be white, as it has been in all previous iOS versions. Link for Testing: https://help.apple.com/pdf/security/en_US/apple-platform-security-guide.pdf We confirmed that the same PDF and code render with a white background on iOS 26 and earlier. Questions: Is this an intentional change in iOS 26's WKWebView? If so, is there a new property or configuration setting available to control the background color of the PDF viewer within WKWebView? We would like to have the ability to set it back to white. Any insights, workarounds, or information on this matter would be greatly appreciated. Thank you.

We have a SAML-based SSO App Extension that uses WKWebView to load the SAML login request. This implementation has been working correctly on iOS versions prior to 26. However, starting with iOS 26, the extension consistently crashes when calling WKWebView.load(_:). The crash occurs inside WebKit, specifically in: /Library/Caches/com.apple.xbs/Sources/WebKit/Source/WebKit/UIProcess/WebsiteData/WebsiteDataStore.cpp at WebKit::WebPageProxy::loadRequest(...) No app-level exception is thrown, and the extension terminates with: Thread 10: EXC_BREAKPOINT (code=1, subcode=0x1a31dbe00) It appears that WKWebView initialization or WebsiteDataStore creation is now restricted in extension contexts on iOS 26, but this change is not documented in the SDK release notes. Could you please confirm if this is an intentional sandbox restriction in iOS 26 or a regression in WebKit? Steps to reproduce: Implement an App Extension using ASAuthorizationProviderExtensionAuthorizationRequest. Create a WKWebView instance in the extension. Attempt to load a SAML login request (POST request with headers). Observe immediate crash on iOS 26 (works fine on earlier versions). Expected behavior: WKWebView should load the request or fail gracefully as in prior releases, without crashing the extension process. Request: Please clarify if WKWebView usage inside extensions is officially unsupported as of iOS 26, and if so, recommend an alternative approach for handling SSO flows.

We use an embedded WKWebView for several screens in our app. Recently, we have been testing keyboard navigation via Full Keyboard Access in our apps. On IOS 18, everything works pretty much as expected. On IOS 26, it does not. On IOS 26, you can "tab" away from the webview and then never tab back to the webview for keyboard navigation. Is this a known issue? Are there workarounds for this issue that anyone is aware of?

As the title suggests, given today’s overpowered device performance, shouldn’t Safari and WKWebView allow repainting during window resizing? Currently, all WKWebView-based apps pause page rendering during resize. When a user double-clicks the drag region, the sequence goes: pause rendering → enlarge or shrink the window → leave a blank area → repaint the page. The whole process feels inelegant—especially on devices that support ProMotion.

YouTube now requires a Referer to be sent to be able to embed Youtube videos, otherwise the videos won't work. But WKWebView doesn't send a Referer when using a custom scheme, so Youtube videos stopped working in that case. This affects Ionic apps, both using Cordova or Capacitor. There's an open issue for Cordova and another one for Capacitor. In these apps, the app is served using a custom scheme like capacitor://localhost or ionic://localhost. I tried modifying the Ionic WebView source code to force adding a referrer to the URL loaded using WKWebView's loadRequest: [request addValue:@"https://my.test.app" forHTTPHeaderField:@"Referer"]; [_engineWebView loadRequest:request] But the Referer is still not sent in the Requests, I guess because the app is using a custom scheme (e.g. capacitor://localhost). However, if I modify this code to force loading an "online URL" (using https) instead of capacitor://localhost, then the my.test.app Referer is sent to the requests. Is there any way to make WKWebView send a Referer when using a custom scheme?

Since Xcode 26 our tests are crashing due to the Main Thread not being able to deallocate WKNavigationResponse. Following an example: import Foundation import WebKit final class WKNavigationResponeMock: WKNavigationResponse { private let urlResponse: URLResponse override var response: URLResponse { urlResponse } init(urlResponse: URLResponse) { self.urlResponse = urlResponse super.init() } convenience init(httpUrlResponse: HTTPURLResponse) { self.init(urlResponse: httpUrlResponse) } convenience init?(url: URL, statusCode: Int) { guard let httpURLResponse = HTTPURLResponse(url: url, statusCode: statusCode, httpVersion: nil, headerFields: nil) else { return nil } self.init(httpUrlResponse: httpURLResponse) } } import WebKit import XCTest final class ExampleTests: XCTestCase { @MainActor func testAllocAndDeallocWKNavigationResponse() { let expectedURL = URL(string: "https://galaxus.ch/")! let expectedStatusCode = 404 let instance = WKNavigationResponeMock() // here it should dealloc/deinit `instance` automatically } Here the call stack: Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 CoreFoundation 0x101f3dd54 CFRetain.cold.1 + 16 1 CoreFoundation 0x101e14860 CFRetain + 104 2 WebKit 0x10864dd24 -[WKNavigationResponse dealloc] + 52

Hello Apple Team, I love the existing keyboard shortcuts such as Control + Function + Left/Right Arrow which allow moving windows to the left or right half of the screen. It significantly improves window management and productivity. I would like to kindly request a similar feature to move windows across multiple monitors using a keyboard shortcut. This would be especially helpful for users with multi-monitor setups who want quick and seamless window transitions between displays without using the mouse. This enhancement could align with Apple's commitment to intuitive and efficient user experience, helping users manage their workspace more effectively. Thank you for considering this feature request!

I have a visionOS app using Apple's WebView and WebPage to display web content. When viewing a live YouTube stream last night, YouTube put up the warning in the area that would have the chat window: Oh no! It looks like you're using an older version of your browser. Please update it to use live chat. Anyone know if YouTube is generating this from the server based on the WebPage's user agent string, from Javascript running in the browser engine, or something else? Anyone know if and how it is possible to resolve this? (See right side of YouTube web page from a screen grab):

I'm hoping that others may be able to assist with my first app submission. **Guideline 2.1 - Performance - App Completeness Issue Description** The app still exhibited one or more bugs that would negatively impact App Store users. Bug description: The app did not load its content. Review device details: Device type: iPad Air (5th generation) OS version: iPadOS 18.3.1 The app pulls in a website embedded to allow them to login to their accounts/place orders. I've tested it on multiple physical devices and using the simulator. It works fine and loads without any issues. The review team would not give me any other information or support to help get this app approved. Any help would be appreciated.

Hi, it seems that with iOS26 the system displays two entries in the screentime report for apps that use a WKWebView: one for the app itself and one for the website that was displayed in the app. We don't see this behaviour in iOS18.7. I'm reseaching how to disable the recording for the webviews in one of our apps (written in Swift with UIKit). The STWebpageController looked promising, especially the field suppressUsageRecording, but the whole class is poorly documented. We initialized it with the bundle identifier of the app and set the url of the wkwebview as the url in STWebpageController. It looks a bit like this: webView = WKWebView(frame: .zero, configuration: config) view.addSubview(webView) //setup STWebpageController webpageController = STWebpageController() do { try webpageController!.setBundleIdentifier(bundleIdentifier) } catch{ } webpageController!.suppressUsageRecording = true addChild(webpageController!) view.addSubview(webpageController!.view) webpageController!.view.frame = view.frame webpageController!.didMove(toParent: self) //load url in webView let request = URLRequest(url: url, cachePolicy: .reloadIgnoringLocalCacheData) webview.load(request) webpageController?.url = request.url This has no effect on the recorded screentime for the webview inside our app - we still see the same time for the container app and the included webview. Any suggestions? Thanks, Heiko

I'm working on a regular website, in which I'm trying to debug using the (MacOS) Safari Development tools. Since updating my Simulator to iOS 16.4, console.log is no longer displayed in the Console. Even when executing it directly in the console (console.log('test');), it's not printed. Now, I've read that this is a feature for debugging in-app browser content (https://webkit.org/blog/13936/enabling-the-inspection-of-web-content-in-apps/) but can't find the regular web workaround here. TL;DR: No longer see console.log in iOS 16.4 Safari when debugging from my Mac. Thanks in advance for your suggestions!

System/device combinations where the issue does not occur: Physical device: iOS 26.0 (23A5318c) + iPhone 16 Pro Max System/device combinations where the issue does occur: System versions: Physical device: iOS 26.0 (23A5330a), iOS 26.0 (23A340) Simulator: iOS 26.0 (23A339) Device models: Physical device: iPhone 12 Reproducible in Safari, WKWebView, and UIWebView: Yes Actual behavior In WebView (and identically in Safari): Before the keyboard is shown, header/footer elements with position: fixed are correctly aligned with the screen viewport. Scrolling up/down works as expected. After the keyboard appears, the visualViewport position changes. Bug: When the keyboard is dismissed, visualViewport.offsetTop does not reset to 0. As a result, fixed header/footer elements remain misaligned: When scrolling down, the position looks correct. When scrolling up, the header/footer are visibly offset. Steps to reproduce Focus an input field → the keyboard appears Dismiss the keyboard Observe that visualViewport.offsetTop remains >0 (does not reset to zero) position: fixed header/footer elements are misplaced relative to the screen Expected behavior After the keyboard is dismissed, visualViewport.height should return to match the layout viewport, and visualViewport.offsetTop should reset to 0. When scrolling upward, fixed elements should remain correctly positioned within the layout viewport. Minimal reproducible demo A simple HTML file containing: A header and footer with position: fixed An input element to trigger the keyboard <!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8" /> <meta name="viewport" content="width=device-width, initial-scale=1.0, viewport-fit=cover" /> <title>H5 吸顶吸底页面 Demo</title> <style> * { margin: 0; padding: 0; box-sizing: border-box; } body { font-family: Arial, sans-serif; height: 2000px; /* 设置内容高度 */ background-color: #f0f8ff; /* body 背景浅蓝色 */ padding-top: 120px; /* 预留 header 高度 */ padding-bottom: 60px; /* 预留 footer 高度 */ overflow-x: hidden; } /* 吸顶 Header */ header { position: fixed; top: 0; left: 0; width: 100%; height: 120px; background-color: #ff6b6b; /* 红色 */ display: flex; align-items: center; justify-content: center; color: white; font-size: 24px; font-weight: bold; z-index: 1000; } /* 吸底 Footer */ footer { position: fixed; bottom: 0; left: 0; width: 100%; height: 60px; background-color: #4ecdc4; /* 青绿色 */ display: flex; align-items: center; justify-content: center; color: white; font-size: 18px; font-weight: bold; z-index: 1000; } /* 输入框样式 */ .input-container { margin: 100px auto; width: 80%; max-width: 600px; text-align: center; } input[type='text'] { padding: 12px; font-size: 16px; border: 2px solid #ddd; border-radius: 8px; width: 100%; box-sizing: border-box; } input[type='text']:focus { outline: none; border-color: #4ecdc4; } </style> </head> <body> <!-- 吸顶 Header --> <header>吸顶 Header (120px)</header> <!-- 主体内容 --> <div class="input-container"> <input type="text" placeholder="请输入内容..." /> </div> <!-- 吸底 Footer --> <footer>吸底 Footer (60px)</footer> </body> </html>

We have an iphone app that has an embedded webview using webkit, and we found the app crashes when we navigate to an specifc internal website. When I opened the ips file I see this stacktrace on the com.apple.main-thread WebCore::JSDOMRect::subspaceForImpl(JSC::VM&) WebCore::JSDOMRect::create(JSC::Structure*, WebCore::JSDOMGlobalObject*, WTF::Ref<WebCore::DOMRect, WTF::RawPtrTraits<WebCore::DOMRect>, WTF::DefaultRefDerefTraits<WebCore::DOMRect>>&&) WebCore::toJSNewlyCreated(JSC::JSGlobalObject*, WebCore::JSDOMGlobalObject*, WTF::Ref<WebCore::DOMRect, WTF::RawPtrTraits<WebCore::DOMRect>, WTF::DefaultRefDerefTraits<WebCore::DOMRect>>&&) JSC::JSValue WebCore::CloneDeserializer::readDOMRect<WebCore::DOMRect>() WebCore::CloneDeserializer::readTerminal() WebCore::CloneDeserializer::deserialize() WebCore::SerializedScriptValue::deserialize(JSC::JSGlobalObject&, JSC::JSGlobalObject*, WTF::Vector<WTF::Ref<WebCore::MessagePort, WTF::RawPtrTraits<WebCore::MessagePort>, WTF::DefaultRefDerefTrait WebCore::SerializedScriptValue::deserialize(JSC::JSGlobalObject&, JSC::JSGlobalObject*, WebCore::SerializationErrorMode, bool*) WebCore::SerializedScriptValue::deserialize(OpaqueJSContext const*, OpaqueJSValue const**) API::SerializedScriptValue::deserialize(WebCore::SerializedScriptValue&) ScriptMessageHandlerDelegate::didPostMessage(WebKit::WebPageProxy&, WebKit::FrameInfoData&&, API::ContentWorld&, WebCore::SerializedScriptValue&) WebKit::WebUserContentControllerProxy::didPostMessage(WTF::ObjectIdentifierGeneric<WebKit::WebPageProxyIdentifierType, WTF::ObjectIdentifierMainThreadAccessTraits<unsigned long long>, unsigned lon WebKit::WebUserContentControllerProxy::didReceiveMessage(IPC::Connection&, IPC::Decoder&) IPC::MessageReceiverMap::dispatchMessage(IPC::Connection&, IPC::Decoder&) WebKit::WebProcessProxy::dispatchMessage(IPC::Connection&, IPC::Decoder&) WebKit::WebProcessProxy::didReceiveMessage(IPC::Connection&, IPC::Decoder&) IPC::Connection::dispatchMessage(WTF::UniqueRef<IPC::Decoder>) IPC::Connection::dispatchIncomingMessages() WTF::RunLoop::performWork() WTF::RunLoop::performWork(void*) __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ __CFRunLoopDoSource0 __CFRunLoopDoSources0 __CFRunLoopRun CFRunLoopRunSpecific GSEventRunModal -[UIApplication _run] UIApplicationMain main start I assume something is crashing after deserializing a JSDomRect. This is crashing on an Iphone 13 with os 18.6.2 but this doesn't crash on iphone 11 os 26.0 I'm executing the app from xcode and I'm not able to see the stacktrace listed before in xcode, to be able to see variables and to understand what is being deserialized. I've also tried using safari mac develop, but safari stops debugging as soon as the app crashes. I've also tried attaching a remote process into the webkit I've downloaded from here https://webkit.org/getting-the-code/ but didn't have luck so far. Do you know how can I debug what's causing the crash?

Subject: iOS 26 WKWebView: Remote Pages Become Unresponsive After Loading Local HTML Files Description We're experiencing a critical issue with WKWebView in a React Native 0.64.3 application where remote web pages become completely unresponsive after loading local HTML files in iOS 26. It works well before iOS26. Environment: React Native 0.64.3 iOS 26.0 Xcode 26.0.1 Using custom WKWebView implementations in Native modules Problem Details App loads local HTML files using loadFileURL:allowingReadAccessToURL: Later, when loading remote pages via loadRequest:, the remote pages load successfully but become unresponsive to user interactions This occurs even when using different WKWebView instances The issue is reproducible 100% of the time once a local file has been loaded Restarting the app and loading remote pages directly works fine Code Example: // Loading local file (works fine) [self.webView loadFileURL:localFileURL allowingReadAccessToURL:accessURL]; // Later, loading remote page (loads but becomes unresponsive) NSURLRequest *request = [NSURLRequest requestWithURL:remoteURL]; [self.webView loadRequest:request]; What We've Tried: Using different WKWebView instances for local vs remote content Comprehensive cleanup in dealloc (removing all user scripts and message handlers) Loading blank HTML before switching to remote content Using shared WKProcessPool (understanding its limitations in iOS 15+) Ensuring proper decisionHandler management in navigation delegates Resetting WKWebView configuration settings Clearing cookies and cache between loads Using loadFileRequest:allowingReadAccessToURL: instead of loadFileURL: Key Observations: The remote page renders correctly and network requests complete No JavaScript errors in console The view hierarchy appears normal in Debug View Hierarchy Touch events seem to be delivered but not processed by the web content Questions: Has Apple introduced new security restrictions in iOS 26 that affect the transition from file:// URLs to http:// URLs? Are there specific WKWebView configuration changes required for React Native applications in iOS 26? Could this be related to the React Native bridge or JavaScript context persistence? Any insights or workarounds would be greatly appreciated, as this is blocking our iOS 26 compatibility.

I’m encountering a consistent crash in WebKit when using WKWebView to play a YouTube playlist in my iOS app. Playback starts successfully, but the web process terminates during the second video in the playlist. This only occurs on physical devices, not in the simulator. Here’s a simplified Swift example of my setup: import SwiftUI import WebKit struct ContentView: View { private let playlistID = "PLig2mjpwQBZnghraUKGhCqc9eAy0UbpDN" var body: some View { YouTubeWebView(playlistID: playlistID) .edgesIgnoringSafeArea(.all) } } struct YouTubeWebView: UIViewRepresentable { let playlistID: String func makeUIView(context: Context) -> WKWebView { let config = WKWebViewConfiguration() config.allowsInlineMediaPlayback = true let webView = WKWebView(frame: .zero, configuration: config) webView.scrollView.isScrollEnabled = true let html = """ <!doctype html> <html> <head> <meta name="viewport" content="initial-scale=1.0, maximum-scale=1.0"> <style>body,html{height:100%;margin:0;background:#000}iframe{width:100%;height:100%;border:0}</style> </head> <body> <iframe src="https://www.youtube-nocookie.com/embed/videoseries?list=\(playlistID)&controls=1&rel=0&playsinline=1&iv_load_policy=3" frameborder="0" allow="encrypted-media; picture-in-picture; fullscreen" webkit-playsinline allowfullscreen ></iframe> </body> </html> """ webView.loadHTMLString(html, baseURL: nil) return webView } func updateUIView(_ uiView: WKWebView, context: Context) {} } #Preview { ContentView() } Observed behavior: First video plays without issue. Web process crashes when the second video in the playlist starts. Console logs show WebProcessProxy::didClose and repeated memory status messages. Using ProcessAssertion or background activity does not prevent the crash. Only occurs on physical devices; simulators do not reproduce the issue. Questions: Is there something I should change or add in my WKWebView setup or HTML/iframe to prevent the crash when playing the second video in a playlist on physical iOS devices? Is there an officially supported way to limit memory or prevent WebKit from terminating the web process during multi-video playback? Are there recommended patterns for playing YouTube playlists in a WKWebView on iOS without risking crashes? Any tips for debugging or configuring WKWebView to make it more stable for continuous playlist playback? Thanks in advance for any guidance!

navigator.permissions.query -&gt; permissionStatus.onchange is Supposed to listen to the event of a change in permissions in the browser settings. This works for all browsers, but in Safari for iOS and MacOS this seems to be broken in the currently recent versions 17.x Example: navigator.permissions.query({ name: 'notifications' }).then((permissionStatus) =&gt; { permissions = permissionStatus.state; // this value gets set correctly permissionStatus.onchange = () =&gt; { // This will not get executed when permissions have been changed // within the safari settings app, or iOS Settings for PWA or Safari }; }); Can someone from Apple's Webkit Team please comment on this? Thank you. T.

When trying to create an anchor with the download attribute it does not work for PDF files, it displays the files inline. Also when the download attribute is set the target attribute is ignored too. The tag: ... The behavior: It displaies the file in line. The correct behavior: The file should be downloaded and not displayed or at least displayed but with the "_blank" target (new tab). This is an issue when working with WebSockets which is closed when the file is opened inline.

1. System/device combinations where the issue does not occur: Physical device: iOS 26.0 (23A5318c) + iPhone 16 Pro Max 2. System/device combinations where the issue does occur: System versions: Physical device: iOS 26.0 (23A5330a), iOS 26.0 (23A340) Simulator: iOS 26.0 (23A339) Device models: Physical device: iPhone 12 Reproducible in Safari, WKWebView, and UIWebView: Yes Actual behavior In WebView (and identically in Safari): Before the keyboard is shown, header/footer elements with position: fixed are correctly aligned with the screen viewport. Scrolling up/down works as expected. After the keyboard appears, the visualViewport position changes. Bug: When the keyboard is dismissed, visualViewport.offsetTop does not reset to 0. As a result, fixed header/footer elements remain misaligned: When scrolling down, the position looks correct. When scrolling up, the header/footer are visibly offset. Steps to reproduce Focus an input field → the keyboard appears Dismiss the keyboard Observe that visualViewport.offsetTop remains >0 (does not reset to zero) position: fixed header/footer elements are misplaced relative to the screen Expected behavior After the keyboard is dismissed, visualViewport.height should return to match the layout viewport, and visualViewport.offsetTop should reset to 0. When scrolling upward, fixed elements should remain correctly positioned within the layout viewport. Minimal reproducible demo A simple HTML file containing: A header and footer with position: fixed An input element to trigger the keyboard <!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8" /> <meta name="viewport" content="width=device-width, initial-scale=1.0, viewport-fit=cover" /> <title>H5 吸顶吸底页面 Demo</title> <style> * { margin: 0; padding: 0; box-sizing: border-box; } body { font-family: Arial, sans-serif; height: 2000px; /* 设置内容高度 */ background-color: #f0f8ff; /* body 背景浅蓝色 */ padding-top: 120px; /* 预留 header 高度 */ padding-bottom: 60px; /* 预留 footer 高度 */ overflow-x: hidden; } /* 吸顶 Header */ header { position: fixed; top: 0; left: 0; width: 100%; height: 120px; background-color: #ff6b6b; /* 红色 */ display: flex; align-items: center; justify-content: center; color: white; font-size: 24px; font-weight: bold; z-index: 1000; } /* 吸底 Footer */ footer { position: fixed; bottom: 0; left: 0; width: 100%; height: 60px; background-color: #4ecdc4; /* 青绿色 */ display: flex; align-items: center; justify-content: center; color: white; font-size: 18px; font-weight: bold; z-index: 1000; } /* 输入框样式 */ .input-container { margin: 100px auto; width: 80%; max-width: 600px; text-align: center; } input[type='text'] { padding: 12px; font-size: 16px; border: 2px solid #ddd; border-radius: 8px; width: 100%; box-sizing: border-box; } input[type='text']:focus { outline: none; border-color: #4ecdc4; } </style> </head> <body> <!-- 吸顶 Header --> <header>吸顶 Header (120px)</header> <!-- 主体内容 --> <div class="input-container"> <input type="text" placeholder="请输入内容..." /> </div> <!-- 吸底 Footer --> <footer>吸底 Footer (60px)</footer> </body> </html>