1163339 - Crash when pasting from 1Password app

Status: RESOLVED FIXED

(Core :: Widget: Cocoa, defect)

Description

[phinze]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:39.0) Gecko/20100101 Firefox/39.0
Build ID: 20150509004013

Steps to reproduce:

1. Head to a website with a login, say github.com.

2. Press CMD+OPT+\ to open the 1Password Mini menu.

3. Navigate to a password and copy it

4. Focus Firefox and press CMD+V to paste.


Actual results:

Immediate crash with details shown here:

https://crash-stats.mozilla.com/report/index/2937a5b8-d983-4e4d-a9f9-2ff1a2150507

The key message seems to be this:

> Bug 893973: A password editor has focus, but not in secure input mode


Expected results:

Password should have been pasted into the input field.

Comment 1

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

Is happens in stable Firefox?
Try reporting it also to extension developers.

Comment 2

[phinze]

So far I am unable to reproduce on stable Firefox.

I cross-posted this issue on the Agilebits side here:

https://discussions.agilebits.com/discussion/40792/firefox-developer-edition-crashes-when-pasting-from-1password-mini

One of their developers responded with the following:

> Thanks for reporting this! Unfortunately this doesn't appear to be a
> 1Password error you're seeing, but rather a Firefox bug dating back to 2013.

> Additionally, 'secure input' in Firefox isn't something that 1Password
> controls. Rather, this is a type of field (often for a password) that OS X
> supports, which can be used in apps (in this case, Firefox) to prevent
> keylogging. If you're seeing this any time you try to paste, it sounds like
> Firefox may not be releasing these secure input fields correctly. With Secure
> Input enabled, all typing is passed directly to the active application—no
> other applications can observe your typing. Secure Input is generally enabled
> when you type into a password field. Some applications also enable Secure
> Input at other times, which is appropriate as long as they turn Secure Input
> off once it is no longer required.

> We don't officially support prerelease software (OS, browser, or otherwise),
> but we'll definitely keep an eye on this in case it becomes a larger problem
> that Mozilla neglects to fix. But I suspect that they will fix this in short
> order, as it is a known issue and could cause other problems as well. I'm
> also heartened to see that they are aware of the issue and that it does not
> affect the stable channel. Thanks again for bringing it to our attention! :)

Comment 3

[phinze]

Did some digging on Bug 893973 - that does look to my untrained eyes to be the same issue I'm experiencing, but it looks like it's been languishing for awhile.

Happy to close this as a duplicate if that's the proper procedure. Let me know!

Comment 4

[Steven Michaud [:smichaud] (Retired)]

> https://crash-stats.mozilla.com/report/index/2937a5b8-d983-4e4d-a9f9-2ff1a2150507

This is for an old aurora-branch build.  Release builds don't have these crashes.

Comment 5

[Steven Michaud [:smichaud] (Retired)]

Doug, this looks like your bug almost exactly.

No need to dup this anywhere else.  I'll be working on it here.

Comment 6

[Steven Michaud [:smichaud] (Retired)]

I find I don't need to install the 1Password extension to see these crashes.  They happen with the app alone.  Here's the STR I find works best for me:

1) Install 1Password and set it to "Always keep 1Password mini running".
2) Run a FF trunk (aka mozilla-central) or Developer Edition (aka aurora) nightly and visit a page that prompts you to log in -- for example https://github.com/login.
3) Focus the "Password" box by clicking on it.
4) Press cmd-opt-\ to show the 1Password mini popup.
5) Mouse over Password Generator, then choose Copy.
   Firefox should still be the focused app, and the Password box should still have keyboard focus.
6) Press cmd-v (to copy the generated password into the Password box).
   Crash.

This "works" (crashes) with e10s on or off.

Comment 7

[Steven Michaud [:smichaud] (Retired)]

I used the 1Password 5.3.2 free trial in my tests.  This only runs on OS X Yosemite (10.10.X).

Comment 8

[Steven Michaud [:smichaud] (Retired)]

Quoting from bug 1188425 comment #4:

<begin quote>
1Password does create some fake key events (created with KeyboardEvent initKeyEvent with 0 for the keyCode and charCode arguments) to massage websites' Javascript validations and whatnot. For instance, some forms only trigger their validations on key events, not on value change or blur. This is something we've been doing for a long time and it's worked pretty well for us. 

The other thing we use generated key event for is autosubmit. We manually dispatch a key event with the keyCode and charCode set to 13 to the password field in order to submit the form. This works fantastically and is even better than what we're able to do in Chrome and Safari due to this longstanding bug: https://bugs.webkit.org/show_bug.cgi?id=16735
<end quote>

Jamie, I assume you're talking here about the 1Password extension.  But note that this bug happens even without the extension.  Is what you say still relevant?

Comment 9

[Steven Michaud [:smichaud] (Retired)]

Jamie, please also tell us if you have other, additional STR for these crashes with 1Password -- including ones that involve the extension.

Comment 10

[Steven Michaud [:smichaud] (Retired)]

Apparently these crashes can also be reproduced, in very similar fashion (with an app, not an extension), using the ClipMenu clipboard manager.  See bug 893973 comment #95.

Comment 11

[Jamie Phelps]

Steven: I started to cross post my comment here but when I saw that this happened without 1Password as well, I elected not to muddy the waters.

You are correct that I was talking about our Firefox extension and its key events. I'm don't think this is relevant to this bug now.

Comment 12

[Steven Michaud [:smichaud] (Retired)]

This is now fixed by the patch for bug 1148196.