Calling [aWebView.window makeFirstResponder:aWebView], in some conditions, causes the web view content to scroll up. This seems to happen if you are making first responder a web view that is already first responder or that was first responder in the same window (without being removed from it before). There are various ways to reproduce it in Safari (I'm using WebKit compiled by myself matching the version shipped in 10.11.5 DP 4, that is the one for version 601.6.17, but it happens with any 10.11 version I've tried): 1. Open Safari. 2. Go to gmail.com (without clicking the view) and login. 3. Scroll down (without clicking). 4. Open a new tab with the keyboard. 5. Go to the previous tab with the keyboard. -> The gmail content will have scrolled up. If you click the view and repeat then the bug won't happen any more. The other way is: 1. Open Safari. 2. Go to gmail.com and compose a long email (so there's a scroll bar) and make sure you have scrolled the email to the bottom. 3. Go to the URL bar 4. Move the focus back to the web view -> The email will scroll to the top. In my app using WebKit I could reproduce it also by switching tab after clicking the view, while in Safari this doesn't happen. We discovered that this doesn't happen in Safari because, when you switch to another tab, the web view in the newly hidden tab gets removed from its super view. This is a bug related to 10.11 as I cannot reproduce on 10.10. Moreover, if I run WebKit compiled for 10.10 (setting MAC_OS_X_VERSION_MAJOR=101000) on 10.11, the bug doesn't happen.
Can you attach a test project? It is not obvious if all of these are the same issue. Especially the last one, which doesn't involve changing NSViews at all. > Moreover, if I run WebKit compiled for 10.10 (setting MAC_OS_X_VERSION_MAJOR=101000) on 10.11, the bug doesn't happen. I couldn't quickly find any related link version checks in WebKit code. I could have overlooked it, or the change could actually be in AppKit.