Bugzilla

(In reply to Bodea Daniel [:danibodea] from comment #7)
> 1. So far, I understand that the steps to reproduce would start with generating a password (Password Manager drop-down and context menu methods), then modify the generated password (erase a part of it or add to it or change it in any way) and then, the LoginManagerParent should somehow be notified. 

That is correct.

> How should this be verified?

I think it will be easiest to verify bug 1548861 and bug 1548880 which depend on this one.

> Also, how do I differentiate an "isTrusted:true" event from one that is false? What do I need to take into consideration when testing?

`isTrusted` is true when the event is dispatched by the browser instead of by a website. You can dispatch an untrusted event on any `<input>` by first selecting it in the Inspector of web developer tools and the running the following in the console:
```js
$0.dispatchEvent(new Event("change"));
```
and ensuring that it doesn't trigger an edit doorhanger.

(In reply to Bodea Daniel [:danibodea] from comment #7)
> 1. So far, I understand that the steps to reproduce would start with generating a password (Password Manager drop-down and context menu methods), then modify the generated password (erase a part of it or add to it or change it in any way) and then, the LoginManagerParent should somehow be notified. 

That is correct.

> How should this be verified?

I think it will be easiest to verify bug 1548861 and bug 1548880 which depend on this one.

> Also, how do I differentiate an "isTrusted:true" event from one that is false? What do I need to take into consideration when testing?

`isTrusted` is true when the event is dispatched by the browser instead of by a website. You can dispatch an untrusted event on any `<input>` by first selecting it in the Inspector of web developer tools and the running the following in the console:
```js
$0.dispatchEvent(new Event("change"));
```
and ensuring that it doesn't trigger a new doorhanger or a change to the content of an existing one.