Created attachment 497673 [details] Silverlight Controls Demo - Open attached ControlsDemo TestPage.html#TextBox - Type a char into the "TextInput" textbox - Press Win+z twice Expected: Undo char typing, then no-op Result: Undo char typing, then types "z"
Note: This bug refers to a pre-release version of Silverlight that is not public. I can't reproduce this bug, undo works as expected for me except that it always beeps even if an undo action was successful. "Press Win+z twice" makes me think the reporter is on Windows or maybe this is a problem with using a Windows keyboard on a Mac?
This bug report assumes a Windows keyboard attached to a Mac OS X machine.
I was the one who opened the original bug. I use Win+Z because I have a Windows keyboard attached to Mac, but it does not make any difference. You can consider me writing Command+Z instead. This bug does not repro with the same version unreleased of Silverlight on current released version of Firefox 3.6.10.
In comment #2 I said this referred to a pre-release version of Silverlight. That is no longer the case, it's now the current version of Silverlight. Also, this bug is against Firefox 4 only, as far as I know. I think there is some possibility that this was fixed on trunk by bug 628585 (that patch has also landed on the 2.0 branch now). Depends on how Silverlight is handling key events. Steven - I don't have a Windows keyboard, iirc you do. Can you look into this?
Not that it matters much but I referenced the wrong comment above. Comment #1 is the one about pre-release Silverlight...
> Steven - I don't have a Windows keyboard, iirc you do. Can you look > into this? I do have a Windows keyboard. The left and right "Windows keys" on it normally get translated to left and right "Command". I'll try to reproduce this on Monday (with various versions of Silverlight, on various versions of OS X).
This bug is specific to Firefox 4+ and the latest Silverlight, to limit your testing.
Testing with Silverlight 4.0.60129.0 (the current version) and Firefox 4.0 on OS X 10.5.8 and 10.6.7, I can reproduce a bug that closely resembles the one reported in comment #0. But it's not exactly the same. I don't know whether this is because the original report was inaccurate, or because circumstances have changed. What now happens is very strange -- the bug only happens in 32-bit mode, whether or not the Silverlight plugin is running out-of-process! It doesn't matter what kind of keyboard you're using -- the bug happens with either a Windows keyboard or an Apple one. In comment #0's STR, "Press Win+z twice" should be translated "Press Command+z twice". On OS X 10.5.8, Firefox 4.0 always runs in 32-bit mode, and always runs plugins in process. So this bug always happens on OS X 10.5.8. On OS X 10.6.7, Firefox 4.0 by default runs in 64-bit mode, and runs the Silverlight plugin out-of-process in 32-bit mode. In this case the bug doesn't happen. To make Firefox 4.0 run in 32-bit mode on OS X 10.6.7, right-click on the distro, choose "Get Info", and then choose "Open in 32-bit mode". When you run FF 4.0 in 32-bit mode on OS X 10.6.X, by default it runs the Silverlight plugin in process (and of course also in 32-bit mode). In this case the bug happens. Enter about:config and change "dom.plugins.ipc.enabled.i386" from its default setting of "false" to "true" (and restart FF 4.0). This makes the Silverlight plugin run out-of-process even in 32-bit mode. The bug still happens. This bug is so strange that I suspect it's at least partially Silverlight's fault. What's different about the latest version of Silverlight on OS X? (By the way, I tested with Silverlight 4.0.50917.0 and didn't see the bug. But I think there was also a Silverlight 4.0.51204.0 which I never downloaded while it was current, and which I therefore haven't tested with. Is there somewhere I can download older versions of the Silverlight plugin?)
> I think there is some possibility that this was fixed on trunk by bug 628585 Nope. The bug still happens on the trunk (with code pulled today).
> Is there somewhere I can download older versions of the Silverlight > plugin? Actually, this question has already been answered at bug 520312 comment #16. Getting at the information is still a but complicated, though, so I'll give a fuller explanation here. 1) Visit http://www.microsoft.com/silverlight/resources/ and look for "Silverlight Release History" under "Helpful Resources" on the left of the page towards the bottom. 2) Clicking on "Silverlight Release History" currently takes you to the following link: http://www.microsoft.com/downloads/en/details.aspx?familyid=1b7a3205-b5f8-4e20-bf42-792de5923454&displaylang=en 3) Download the file "Microsoft Silverlight Release History.htm" and change its name to "Microsoft Silverlight Release History.html". 4) Double-click on your local copy of "Microsoft Silverlight Release History.html" and follow the appropriate links.
Using the information from comment #10, I was able to download Silverlight 4.0.51204.0 (the next to last version) and test with it. The bug doesn't happen with it.
This is a Silverlight bug. I discovered this using the same method I used to find that bug 520312 is a Silverlight bug -- I (temporarily) set Firefox to use the same user-agent string as Safari uses, then restarted the browser. When you do this, the bug doesn't happen. Here's how to set Firefox to use Safari's user agent string: 1) Enter about:config in the Location bar. If prompted, click on the "I'll be careful, I promise!" button. 2) Right-click somewhere in the settings display (below the Filter box), and choose New : String. 3) Enter general.useragent.override as the preference name. 4) Enter the following (without line breaks) as the string value. If you're testing on OS X 10.6, you might want to use a different value (one obtained in Safari using the browserspy link below). Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_8; en-us) AppleWebKit/533.20.25 (KHTML, like Gecko) Version/5.0.4 Safari/533.20.25 Here's a page that (among other things) displays your browser's current user agent string: http://browserspy.dk/browser.php
Interestingly, the bug also goes away if you make Firefox 4.0 use Firefox 3.6.16's user-agent string.
I think Silverlight negotiates Cocoa NPAPI only for Firefox 4, and possibly only on Mac OS X 10.6.
We tried reproducing the issue with the following trunk http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/firefox-4.2a1pre.en-US.mac.dmg and still see it. It happens only in FF4 running in 32-bit mode. It reproes for the remaining part (pasting “a” for Mac+A, “v” for Mac+V)
This is a Silverlight bug, not a Firefox bug. See comment #12.
> It reproes for the remaining part (pasting “a” for Mac+A, “v” for > Mac+V) I don't know what you're referring to here -- it could be a different bug. But before opening a new bug at https://bugzilla.mozilla.org/, first check if changing the user-agent string (as per comment #12 and comment #13) makes the problem go away. If so, this (new) issue is also a Silverlight bug.
As Josh commented in comment #14, we turned on Cocoa eventing only for Firefox4. Thus if you changed the user agent string to Safari or FF 3.6.16 we would fallback to Carbon eventing that would not reproduce the issue. Mac+A or Command+A should select all and Mac+V or Command+V should paste. In both these cases what we are seeing is character "a" and "v" displayed in the textbox instead of the actual command to select all. Josh had commented in an offline e-mail thread that Mozilla might be swallowing these commands by mistake.
> we turned on Cocoa eventing only for Firefox4. Thus if you changed > the user agent string to Safari or FF 3.6.16 we would fallback to > Carbon eventing that would not reproduce the issue. This doesn't explain why the problem only happens in 32-bit mode. But I suppose it's possible that Firefox 4 is sending different events to the plugin in 32-bit mode and 64-bit mode, when using the Cocoa event model. I'll need to look into this.
> It reproes for the remaining part (pasting “a” for Mac+A, “v” for > Mac+V) I'm also able to reproduce this. And yes, on second thought, it does look related.
I'll also need to check exactly what event models the current Silverlight plugin uses in 32-bit mode on OS X 10.5.8, in 32-bit mode on OS X 10.6.7, and in 64-bit mode on OS X 10.6.7.
Provisionally changing this back to a Core : Plugins bug.
This information might help you a bit more in your investigation. When Firefox4 asks us to enable Cocoa eventing, we do so otherwise we fallback to Carbon eventing. Any other browsers, we don't turn on Cocoa eventing in Silverlight 4 latest version 4.0.60129.
Created attachment 527277 [details] [diff] [review] Fix > I suppose it's possible that Firefox 4 is sending different events > to the plugin in 32-bit mode and 64-bit mode, when using the Cocoa > event model. This is in fact true, and is the cause of this bug. So this is a Firefox bug, not a Silverlight bug. The problem is that, in 32-bit mode (in Cocoa event mode), Firefox sends an NPCocoaEventTextInput event to the plugin for a key-down event that happens when the Command key or Control key is pressed (if we're in the middle of an IME composition, or if the plugin has requested complex text input). This doesn't happen in 64-bit mode. My patch fixes this bug by stopping Firefox from doing this in 32-bit mode (in Cocoa event mode). Here's a tryserver build made with my patch: http://firstname.lastname@example.org/tryserver-macosx64/firefox-6.0a1.en-US.mac.dmg Please test it, and let us know your results. I especially want to hear from the Microsoft people. Because of the way the Silverlight plugin sniffs the user-agent string, you will need to make the test build use Firefox 4's user-agent string to make the Silverlight plugin use Cocoa event mode. (The same is true for recent trunk nightlies.) See comment #12 for how to do this. Here are Firefox 4's user agent strings on OS X 10.5.X and 10.6.X. Whichever one you use, you must copy it without line breaks. Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:2.0) Gecko/20100101 Firefox/4.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0) Gecko/20100101 Firefox/4.0
Michelle, I understand from bug 587667 comment #11 that Adobe has an internal (as yet unreleased) version of the Flash plugin that supports IME input in Cocoa event mode. Please test it with the tryserver build from comment #24 (made with my patch for this bug). I believe that Firefox's current complex-text-input behavior (in 32-bit mode) is incorrect, and that my patch fixes the problem. But it does change the current behavior, and I want to make sure this doesn't cause trouble for IME in Flash. Note that you'll need to test in 32-bit mode (on OS X 10.5.X and 10.6.X) -- my patch doesn't change Firefox's behavior when the browser is running in 64-bit mode.
Comment on attachment 527277 [details] [diff] [review] Fix Landed on trunk: http://hg.mozilla.org/mozilla-central/rev/a2e48e0c44bb
My patch will now appear in mozilla-central nightlies, starting with tomorrow's nightly. This patch should (presumably) also land on the 2.0 branch (from which Firefox 4.0.X releases will come). But I'm going to wait for the test results from the Microsoft and Adobe people before I seek approval. So please do test, as soon as you can!
Steven, we are testing the tryserver build you mentioned in comment #24. I'll update the bug once we're done.
We've verified that the bug has been fixed. We have yet to do a full test run related to IME input and will do that once the changes make it into the Beta branch.
(In reply to comment #29) Thanks for letting us know. Adobe folks, we still need to hear from you.
In Adobe's testing on the Flash Player, we found no side effects. Thanks!
Comment on attachment 527277 [details] [diff] [review] Fix On the strength of comment #29 and comment #31, I'm asking for approval for this patch on the aurora branch (what will become FF 5) and the 2.0 branch (what will become FF 4.0.X). My patch has moderate risk, but fixes a major problem in the Silverlight plugin, and potentially also in other plugins that (like Flash) support the Cocoa event mode.
Comment on attachment 527277 [details] [diff] [review] Fix I don't think we should take this for Firefox 4, at least not for a good while. Lets get this on trunk soon and if all goes well for a week or so we should take it for Firefox 5.
Comment on attachment 527277 [details] [diff] [review] Fix The consensus seems to be this patch should cook on the trunk for a while. Later, if no problems arise, I'll once again seek aurora-branch approval.
We're not going to take this for Firefox 5, so please just wait until the next Aurora merge/Firefox 6.
> We're not going to take this for Firefox 5, so please just wait > until the next Aurora merge/Firefox 6. If this patch implemented a new feature, that would make sense. But it doesn't -- it fixes a bug. And it's very easily backed out (if it were found to cause trouble). I hope treating bug fixes as new features isn't going to become the rule in our new system of faster releases. If it does, it will significantly slow down the rate at which we can fix bugs.
> If it does, it will significantly slow down the rate at which we can > fix bugs. I should rephrase this: If we start treating bug fixes as new features, it will significantly increase the time between when a bug gets fixed and when the fix gets into a Firefox release.