I think I finally found the problem. The application's window is borderless, so when it is not full screen, it cannot become key. I didn't think to mention this in my description of the problem because I didn't know it mattered. However, by creating a subclass of NSWindow and overriding canBecomeKeyWindow, the application is accepting keystrokes when it is in the small window state.
Rob ________________________________ From: Robert Walsh <rwa...@envisionware.com> Sent: Thursday, April 15, 2021 12:21 PM To: Alex Zavatone <z...@mac.com> Cc: cocoa-dev@lists.apple.com <cocoa-dev@lists.apple.com> Subject: Re: WKWebView rejecting keyboard input Thanks Alex, Markus. Markus, yes, it appears the WKWebView subclass is becoming first responder. I added a log statement that is being hit when the window is shown. Alex, yes, I am trying to isolate as much as possible, but this is a client application that cannot run outside its server environment, the HTML is delivered from the server, and the HTML page that works is shown when the application is in a different state than the one that does not work. Both pages contain a simple form, but in one state the browser is full screen, and in the other it is in a relatively small window and not full screen. I can't easily switch the pages, but I have tried other pages that are displayed while in the small window state. None will accept user input. Also, I've compared the HTML code in one form to the code in the other, and they are close enough to assume the form and the input are not the problem; the form portion of the code is very plain HTML with few styles that mostly set size and position. So, since the window is becoming first responder and since the HTML buttons on the page can be pressed in the small window state, I don't think there is a focus issue or a problem with another view occluding the web view. It seems to me to be more likely that the problem is inside the web view itself and the way it is handling the HTML and stylesheet for these small window pages. That's probably not a Cocoa issue. Thanks very much for the input. Rob ________________________________ From: Alex Zavatone <z...@mac.com> Sent: Thursday, April 15, 2021 11:26 AM To: Robert Walsh <rwa...@envisionware.com> Cc: cocoa-dev@lists.apple.com <cocoa-dev@lists.apple.com> Subject: Re: WKWebView rejecting keyboard input Hi Rob. One thing that I learned back in QA is that when we have a working sample and one non-working one, duplicate both, point your app to use them, & start removing items from the one that doesn’t work until you get back down to either it working or end up with identical items in the working sample and it still doesn’t work. Have you tried that yet? Let us know. Alex Zavatone > On Apr 15, 2021, at 9:42 AM, Robert Walsh via Cocoa-dev > <cocoa-dev@lists.apple.com> wrote: > > I have an Objective-C application that creates a WKWebView to collect form > input. The form has a label, an input (password) field, and two buttons. > When the form is shown inside the web view by the application, the user can > click the buttons but cannot enter text into the input field. The system > plays a sound to indicate that the key was rejected. I've tried adding a > text area element to the form just to see if the problem is with the input > field itself, but the user cannot type in the text area either. If I take > the same HTML/stylesheet content and open it in Safari, the input field > accepts keyboard input. > > There is another area of the application that shows a different web page in > the same WKWebView component. That page, too, contains a form with an input > field, and the user can type into that one. > > I am using a WKWebView subclass so that I can trap mouse down events, but I > do not have any overloads for keyboard event handlers. > > I'm having trouble determining where (e.g., by what component) the keys are > being blocked and why they are allowed on one page but not another. > > Thanks! > Rob Walsh > > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com > > This email sent to z...@mac.com _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
