<div dir="ltr">We don't currently support e10s on Fennec, so all our code runs in a single process (both the logic in LoginManagerParent.jsm and LoginManagerContent.jsm). However, I recently added a content.js frame script to Fennec for reader mode to make it easier to keep the desktop/mobile code in sync, and we could probably start to use that for password manager work as well. As a start, I filed bug 1129998 to move our dependency on LoginManagerContent from browser.js over to content.js.<br><br>Margaret<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 3, 2015 at 6:36 PM, Christopher Karlof <span dir="ltr"><<a href="mailto:ckarlof@mozilla.com" target="_blank">ckarlof@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">At our passwords work day on 2/2/15, we talked a little bit about the concerns of different parts of the toolkit part. Here are the high level points I got, probably with some inaccuracies others can correct:<div><br></div><div>The concerns are mainly factored into two components: LoginManagerParent (<a href="http://mxr.mozilla.org/mozilla-central/source/toolkit/components/passwordmgr/LoginManagerParent.jsm" target="_blank">http://mxr.mozilla.org/mozilla-central/source/toolkit/components/passwordmgr/LoginManagerParent.jsm</a>) and LoginManagerContent (<a href="http://mxr.mozilla.org/mozilla-central/source/toolkit/components/passwordmgr/LoginManagerContent.jsm" target="_blank">http://mxr.mozilla.org/mozilla-central/source/toolkit/components/passwordmgr/LoginManagerContent.jsm</a>).</div><div><br></div><div>This factoring was mainly done for e10s reasons. The “Content” part is attached to content processes and the “Parent” part is in the main(?) process.</div><div><br></div><div>The Content part is mainly concerned with interacting with password forms on the page, e.g., filling, capturing, inspecting, etc. When it needs passwords to fill, it provides Parent with information about the page, and the Parent provides a list of relevant passwords. It also sets up the necessarily hooks to capture usernames and passwords from the page after the user enters them.</div><div><br></div><div>The Parent stuff is an adapter/bridge to the password storage API. It receive messages from the Content part and makes the appropriate decisions about how to read and write the password store.</div><div><br></div><div>The general rule of thumb we made on Monday was that if you’re making a change to policy around how passwords are retrieved or stored for a particular origin (i.e., page), the changes should probably be made to the Parent. Although the Content part currently explicitly provides the origin of the page in the message, the content process it considered untrusted, and we might in the future have a way for the Parent to determine the origin of a message from content process in a trustworthy manner. </div><div><br></div><div>If you’re making a change to how the password manager interacts with untrusted pages, it should probably go in the Content part.</div><div><br></div><div>Obviously, we’ll need to think about this carefully in the context of each patch, but I wanted to provide this overview for those less familiar with toolkit password manager code (which includes me). </div><div><br></div><div>-chris</div><div><br></div></div>
<br>_______________________________________________<br>
Passwords-dev mailing list<br>
<a href="mailto:Passwords-dev@mozilla.org">Passwords-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/passwords-dev" target="_blank">https://mail.mozilla.org/listinfo/passwords-dev</a><br>
<br></blockquote></div><br></div>