(Split from <http://webkit.org/b/61272> because Safari needs a different solution from Chrome.) What steps will reproduce the problem? 1. Open the attached IME_TextField_Mix3.html. 2. Click the text area under Opaque Flash Stade. 3. Enable an IME. (This issue happens on any IMEs.) 4. Type text. What is the expected result? We can see IME text in the textarea. What happens instead? We cannot see any text. Please provide any additional information below. Attach a screenshot if possible. Since Safari currently runs a plug-in on a UI process, its solution is not so complicated as the one for Chrome. To investigate this Safari problem, Flash just cannot get IME context because it does not have valid window handles. So, in brief, we can solve this problem just creating a dummy window and provide it to Flash so it can get IME context from the window. Regards, Hironori Bono
Created attachment 100445 [details] Patch v0 (not ready for reviews) Greetings, After investigating Safari, I noticed we did not need so complicated solution for Safari as the one for Chromium. So, I would like to upload a simplified change for Safari to start a discussion. Unfortunately, this change still needs to send platform-specific CompositionEvents to the PluginView class so it can send WM_IME_* messages to Flash. It may be a good idea to add a method that sends such CompositionEvents to EventHandler (denoted as EventHandler::compositionEvent) to share this event-sending code? (Once the EventHandler class has this method, we can send CompositionEvents as easy as we send KeyboardEvents.) Regards, Hironori Bono
Created attachment 100947 [details] Patch v1 (added a layout test) Greetings, I have added a layout test that verifies WM_IME_* messages to a plug-in. (This test is the same one as the one used in <http://webkit.org/b/61272>.) Unfortunately, this change becomes much bigger than the previous one because I needed to implement TextInputController for the test. Also, this change copied event-sending code from Editor::setComposition() and Editor::confirmComposition. (I think it is a good idea to merge them as written in my previous comment.) I would like to set r? so I can try building this change on EWS bots. Regards, Hironori Bono
Created attachment 101261 [details] Patch v3 (fixed a build break) Greetings, 3>..\plugins\win\PluginViewWin.cpp(61) : fatal error C1083: Cannot open include file: 'PluginIMEWin.h': No such file or directory Oops, I forgot removing an #include line used for debugging this change. I would like to try building the updated one on EWS bots. Regards, Hironori Bono
Comment on attachment 101261 [details] Patch v3 (fixed a build break) This change seems reasonable to me. I am anything-but a Windows plugin expert at this point. BUt I'm willing to r+ this 4-month-old patch if there are no objections? Bono-san, please give other reviewers at least 24-hours to comment before landing.
Comment on attachment 101261 [details] Patch v3 (fixed a build break) Rejecting attachment 101261 [details] from commit-queue. Failed to run "['/mnt/git/webkit-commit-queue/Tools/Scripts/webkit-patch', '--status-host=queues.webkit.org', '-..." exit_code: 2 Last 500 characters of output: ing file Tools/DumpRenderTree/win/TextInputController.cpp patching file Tools/DumpRenderTree/win/TextInputController.h patching file LayoutTests/ChangeLog Hunk #1 succeeded at 1 with fuzz 3. patching file LayoutTests/platform/win/plugins/windowless-plugin-ime-event-test-expected.txt patching file LayoutTests/platform/win/plugins/windowless-plugin-ime-event-test.html Failed to run "[u'/mnt/git/webkit-commit-queue/Tools/Scripts/svn-apply', u'--reviewer', u'Eric Seidel', u'--force']" exit_code: 1 Full output: http://queues.webkit.org/results/10996144
Greetings, Apologies for the lack of my response. This change works only when we use WebKit (not WebKit2), i.e. this change does not fix this issue if Safari (win) uses WebKit2. (I notice WebKit2 needs more hack to support IMEs for windowless plug-ins.) Does Safari (win) still use WebKit? Regards, Hironori Bono (In reply to comment #4) > (From update of attachment 101261 [details]) > This change seems reasonable to me. I am anything-but a Windows plugin expert at this point. BUt I'm willing to r+ this 4-month-old patch if there are no objections? Bono-san, please give other reviewers at least 24-hours to comment before landing.
Attachment 101261 [details] was posted by a committer and has review+, assigning to Hironori Bono for commit.
Mass closing plug-in bugs, as plug-in support has been removed from WebKit. Please comment and/or reopen if this still affects WebKit in some way.