Last Comment Bug 619217 - Undo action writes Z character when undo stack is empty on FF4 in Silverlight in 32-bit mode
: Undo action writes Z character when undo stack is empty on FF4 in Silverlight...
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Plug-ins (show other bugs)
: 2.0 Branch
: x86 Mac OS X
: P1 normal (vote)
: ---
Assigned To: Steven Michaud [:smichaud] (Retired)
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-12-14 16:21 PST by Andy Rivas
Modified: 2011-04-27 12:56 PDT (History)
7 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
-


Attachments
Silverlight Controls Demo (1.84 MB, application/x-zip-compressed)
2010-12-14 16:21 PST, Andy Rivas
no flags Details
Fix (1.49 KB, patch)
2011-04-20 08:31 PDT, Steven Michaud [:smichaud] (Retired)
jaas: review+
Details | Diff | Splinter Review

Description Andy Rivas 2010-12-14 16:21:57 PST
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"
Comment 1 Josh Aas 2010-12-14 16:54:58 PST
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?
Comment 2 Josh Aas 2010-12-19 09:39:26 PST
This bug report assumes a Windows keyboard attached to a Mac OS X machine.
Comment 3 Igor Babichev 2011-01-21 05:13:13 PST
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.
Comment 4 Josh Aas 2011-04-01 18:29:17 PDT
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?
Comment 5 Josh Aas 2011-04-01 18:30:19 PDT
Not that it matters much but I referenced the wrong comment above. Comment #1 is the one about pre-release Silverlight...
Comment 6 Steven Michaud [:smichaud] (Retired) 2011-04-01 18:54:41 PDT
> 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).
Comment 7 Josh Aas 2011-04-01 20:18:03 PDT
This bug is specific to Firefox 4+ and the latest Silverlight, to limit your testing.
Comment 8 Steven Michaud [:smichaud] (Retired) 2011-04-04 16:08:37 PDT
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?)
Comment 9 Steven Michaud [:smichaud] (Retired) 2011-04-05 09:25:30 PDT
> 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).
Comment 10 Steven Michaud [:smichaud] (Retired) 2011-04-05 09:39:15 PDT
> 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.
Comment 11 Steven Michaud [:smichaud] (Retired) 2011-04-05 09:41:14 PDT
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.
Comment 12 Steven Michaud [:smichaud] (Retired) 2011-04-05 09:58:35 PDT
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
Comment 13 Steven Michaud [:smichaud] (Retired) 2011-04-05 10:00:26 PDT
Interestingly, the bug also goes away if you make Firefox 4.0 use Firefox 3.6.16's user-agent string.
Comment 14 Josh Aas 2011-04-06 10:23:42 PDT
I think Silverlight negotiates Cocoa NPAPI only for Firefox 4, and possibly only on Mac OS X 10.6.
Comment 15 Sunil 2011-04-11 14:54:41 PDT
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)
Comment 16 Steven Michaud [:smichaud] (Retired) 2011-04-11 15:07:59 PDT
This is a Silverlight bug, not a Firefox bug.

See comment #12.
Comment 17 Steven Michaud [:smichaud] (Retired) 2011-04-11 15:11:51 PDT
> 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.
Comment 18 Sunil 2011-04-11 15:19:16 PDT
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.
Comment 19 Steven Michaud [:smichaud] (Retired) 2011-04-11 15:29:54 PDT
> 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.
Comment 20 Steven Michaud [:smichaud] (Retired) 2011-04-11 15:31:08 PDT
> 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.
Comment 21 Steven Michaud [:smichaud] (Retired) 2011-04-11 15:33:55 PDT
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.
Comment 22 Steven Michaud [:smichaud] (Retired) 2011-04-11 15:41:39 PDT
Provisionally changing this back to a Core : Plugins bug.
Comment 23 Sunil 2011-04-11 15:42:27 PDT
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.
Comment 24 Steven Michaud [:smichaud] (Retired) 2011-04-20 08:31:31 PDT
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://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/smichaud@pobox.com-75ea6317a038/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
Comment 25 Steven Michaud [:smichaud] (Retired) 2011-04-20 08:48:57 PDT
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 26 Steven Michaud [:smichaud] (Retired) 2011-04-20 12:00:54 PDT
Comment on attachment 527277 [details] [diff] [review]
Fix

Landed on trunk:
http://hg.mozilla.org/mozilla-central/rev/a2e48e0c44bb
Comment 27 Steven Michaud [:smichaud] (Retired) 2011-04-20 12:05:57 PDT
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!
Comment 28 Sunil 2011-04-20 12:08:06 PDT
Steven, we are testing the tryserver build you mentioned in comment #24. I'll update the bug once we're done.
Comment 29 Sunil 2011-04-26 10:44:29 PDT
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.
Comment 30 Steven Michaud [:smichaud] (Retired) 2011-04-26 11:25:51 PDT
(In reply to comment #29)

Thanks for letting us know.

Adobe folks, we still need to hear from you.
Comment 31 Michelle Sintov 2011-04-26 11:28:04 PDT
In Adobe's testing on the Flash Player, we found no side effects. Thanks!
Comment 32 Steven Michaud [:smichaud] (Retired) 2011-04-26 12:08:58 PDT
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 33 Benjamin Smedberg AWAY UNTIL 2-AUG-2016 [:bsmedberg] 2011-04-26 12:13:07 PDT
Comment on attachment 527277 [details] [diff] [review]
Fix

I really think this should wait 6 weeks.
Comment 34 Josh Aas 2011-04-26 13:59:32 PDT
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 35 Steven Michaud [:smichaud] (Retired) 2011-04-27 08:49:05 PDT
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.
Comment 36 Benjamin Smedberg AWAY UNTIL 2-AUG-2016 [:bsmedberg] 2011-04-27 11:53:56 PDT
We're not going to take this for Firefox 5, so please just wait until the next Aurora merge/Firefox 6.
Comment 37 Steven Michaud [:smichaud] (Retired) 2011-04-27 12:21:55 PDT
> 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.
Comment 38 Steven Michaud [:smichaud] (Retired) 2011-04-27 12:56:43 PDT
> 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.

Note You need to log in before you can comment on or make changes to this bug.