Closed Bug 619217 Opened 14 years ago Closed 13 years ago

Undo action writes Z character when undo stack is empty on FF4 in Silverlight in 32-bit mode

Categories

(Core Graveyard :: Plug-ins, defect, P1)

2.0 Branch
x86
macOS
defect

Tracking

(firefox5-)

RESOLVED FIXED
Tracking Status
firefox5 - ---

People

(Reporter: andy.rivas, Assigned: smichaud)

Details

Attachments

(2 files)

- 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?
Assignee: nobody → joshmoz
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?
Assignee: joshmoz → smichaud
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?)
Summary: Undo action writes Z character when undo stack is empty on FF4B8 64bit → Undo action writes Z character when undo stack is empty on FF4 in 32-bit mode
> 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
Assignee: smichaud → english-us
Component: General → English US
Product: Firefox → Tech Evangelism
QA Contact: general → english-us
Target Milestone: Firefox 4.0 → ---
Version: Trunk → unspecified
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.
Assignee: english-us → nobody
Component: English US → Plug-ins
Product: Tech Evangelism → Core
QA Contact: english-us → plugins
Version: unspecified → 2.0 Branch
Assignee: nobody → smichaud
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.
Summary: Undo action writes Z character when undo stack is empty on FF4 in 32-bit mode → Undo action writes Z character when undo stack is empty on FF4 in Silverlight in 32-bit mode
Attached patch FixSplinter Review
> 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
Attachment #527277 - Flags: review?(joshmoz)
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.
Attachment #527277 - Flags: review?(joshmoz) → review+
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!
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
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.
Attachment #527277 - Flags: approval2.0?
Attachment #527277 - Flags: approval-mozilla-aurora?
Comment on attachment 527277 [details] [diff] [review]
Fix

I really think this should wait 6 weeks.
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.
Attachment #527277 - Flags: approval2.0?
Attachment #527277 - Flags: approval-mozilla-aurora?
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.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: