Disable prompts to save logins while on extension pages #74

lmorchard · 2019-02-06T22:10:28Z

Add getLoginSavingEnabled and setLoginSavingEnabled methods to the
Logins experiment API
Disable login saving for extension pages on background startup

Fixes #57

lmorchard · 2019-02-06T22:11:48Z

test/integration/logins-api-test.js

+        await disableRememberSignons();
+      });
+      it("does not enable login saving for origin when given true", async () => {
+        await commonTest(true, false);


Mild corner case here: If the user has turned off saving logins globally in options, getLoginSavingEnabled always returns false no matter what the setting might be.

Good catch! I'm not sure which, if any, parts of the logins API will work if logins are globally disabled. I think this needs investigation; could you file a bug?

From my own experiences, the CRUD portion of the upstream API works just fine regardless of what the global pref and this specific callout are set to.

lmorchard · 2019-02-06T22:13:35Z

src/background/environment.js

+  const origin = browser.extension.getURL("").slice(0, -1);
+  const savingEnabled = await browser.experiments.logins
+    .getLoginSavingEnabled(origin);
+  if (savingEnabled) {


Checking whether saving is enabled to ensure we keep it off. The user could enable login save globally or manually delete the exception from the list in options. Kind of edge casey, but bleh.

It seems unlikely that users are going to mess with this manually. That said, the browser APIs are available from extension pages, so we could just run this check when the management page is loaded (or, to get kind of extreme about the "user messes things up" edge case, we could run this check on page load and whenever the page visibility API's visibilitychange event fires).

lmorchard · 2019-02-06T22:16:27Z

Hmm, so I only ensure saving is off on startup of the addon. The user could later enable saving in options or delete the exception - and then we'd see the login save prompt come up until next add-on startup.

I wonder if I should make a check more often? Like, say, whenever the browser action button is clicked?

meandavejustice

This is working well for me.

Hmm, so I only ensure saving is off on startup of the addon. The user could later enable saving in options or delete the exception - and then we'd see the login save prompt come up until next add-on startup.
I wonder if I should make a check more often? Like, say, whenever the browser action button is clicked?

I think it would be pretty rare for someone to go and manually delete that rule, If they did I think it's fine to respect it until the next addon startup.

linuxwolf · 2019-02-08T16:18:29Z

I wonder if I should make a check more often? Like, say, whenever the browser action button is clicked?

I think we can start with this, and see how it goes. If we do it more frequently, I'd argue for whenever we think the management page is loaded.

linuxwolf

LGTM

jaredhirsch

Great work overall! Technically, I think this can land as-is, but I do have some suggestions to consider.

jaredhirsch · 2019-02-08T18:35:36Z

src/experiments/logins/api.js

@@ -49,6 +49,20 @@ this.logins = class extends ExtensionAPI {
          //   - fooLogin = login as vanilla JS object
          //   - fooLoginInfo = login as nsILoginInfo
          //   - fooBag = (subset of) login fields as nsIPropertyBag
+          getLoginSavingEnabled(aHost) {


I really dislike the aFoo naming convention. How about just calling this origin?

Heh, I used aHost to match the upstream API, but I can change it if necessary

jaredhirsch · 2019-02-08T18:38:29Z

src/experiments/logins/api.js

@@ -49,6 +49,20 @@ this.logins = class extends ExtensionAPI {
          //   - fooLogin = login as vanilla JS object
          //   - fooLoginInfo = login as nsILoginInfo
          //   - fooBag = (subset of) login fields as nsIPropertyBag
+          getLoginSavingEnabled(aHost) {
+            try {
+              return Services.logins.getLoginSavingEnabled(aHost);


The trailing slash thing seems like a super annoying gotcha. I think we should either handle it here (strip it out or throw if it's detected), or document this annoyance in the schema docs.

jaredhirsch · 2019-02-08T18:39:21Z

src/experiments/logins/schema.json

+      {
+        "name": "getLoginSavingEnabled",
+        "type": "function",
+        "description": "For the given origin, gets a boolean flag which determines whether login saving is enabled",


Should also mention that the returned promise is rejected if the URL is malformed.

jaredhirsch · 2019-02-08T18:40:25Z

src/experiments/logins/schema.json

+        "parameters": [{
+          "name": "aHost",
+          "type": "string",
+          "description": "The origin for which to check the status of login saving"


Just use the description from the IDL: The hostname to check. This argument should be in the origin URL format, with no pathname. For example: "https://www.site.com".

Actually, looking at the schema docs, I haven't been super strict about reusing the IDL descriptions. This could be fine as is (but aHost does bug me ;-P).

jaredhirsch · 2019-02-08T18:42:26Z

src/experiments/logins/schema.json

+      {
+        "name": "setLoginSavingEnabled",
+        "type": "function",
+        "description": "For the given origin, uses the given value to set a boolean flag which determines whether login saving is enabled",


The IDL docs may be clearer here. Also, be sure to mention cases in which the returned promise is rejected, which I think is just if the URL is malformed.

jaredhirsch · 2019-02-08T18:43:04Z

src/experiments/logins/api.js

+              throw new ExtensionError(ex);
+            }
+          },
+          setLoginSavingEnabled(aHost, isEnabled) {


How about origin and shouldSaveLogins for the arguments?

Yeah, same as above, I was trying to follow the underlying API rather than invent new names

jaredhirsch · 2019-02-08T18:45:26Z

test/integration/logins-api-test.js

+  const enableRememberSignons = async () => {
+    await webext.inChrome();
+    await driver.executeScript(`
+      Services.prefs.setBoolPref("signon.rememberSignons", true);


It would be good to actually call the Services.logins.get/setLoginSavingEnabled for a specific origin, then test it's correctly returned when you call the API. I wonder what happens if you accidentally leave in a trailing slash, for instance. This could be left for a followup commit.

jaredhirsch · 2019-02-08T18:46:00Z

test/integration/logins-api-test.js

+        await disableRememberSignons();
+      });
+      it("does not enable login saving for origin when given true", async () => {
+        await commonTest(true, false);


Good catch! I'm not sure which, if any, parts of the logins API will work if logins are globally disabled. I think this needs investigation; could you file a bug?

jaredhirsch · 2019-02-08T18:49:28Z

Whoops! Didn't see Matt had already reviewed. Sorry to pile on :-P

lmorchard · 2019-02-08T22:24:29Z

I added a commit that automatically re-adds our entry to the exception list for login saving when it is somehow removed (manually or otherwise). However, this still needs unit / integration tests. However, however, this could use a sanity check as to whether this is what we actually want to do.

~~Also: Adding WIP because I do intend to add unit / integration tests for the additions in the new commit~~

- Add getLoginSavingEnabled and setLoginSavingEnabled methods to the Logins experiment API - Disable login saving for extension pages on background startup Fixes mozilla-lockwise#57

lmorchard · 2019-02-11T15:20:22Z

Actually, you know what: Never mind my last commit. It occurred to me over the weekend that this PR without the event handler to automatically re-enable the exception was already 80% of the solution and pretty much reviewed.

My commit that uses the permission events still needs time to bake, so I'll do it in a follow-up PR. I can probably add some more test cases there, too

punkbusterdani · 2019-04-24T14:28:10Z

I wish to verify the fix of this issue, but I'm lacking some steps here. How am I supposed to reproduce/verify this issue? Thanks.

lmorchard requested a review from a team as a code owner February 6, 2019 22:10

ghost assigned lmorchard Feb 6, 2019

ghost added the in progress label Feb 6, 2019

lmorchard commented Feb 6, 2019

View reviewed changes

meandavejustice approved these changes Feb 6, 2019

View reviewed changes

linuxwolf approved these changes Feb 8, 2019

View reviewed changes

jaredhirsch reviewed Feb 8, 2019

View reviewed changes

lmorchard force-pushed the 57-disable-login-saving branch from d253c8c to 59c1ce4 Compare February 8, 2019 22:29

lmorchard changed the title ~~Disable prompts to save logins while on extension pages~~ WIP: Disable prompts to save logins while on extension pages Feb 8, 2019

Disable prompts to save logins while on extension pages

a6efbfa

- Add getLoginSavingEnabled and setLoginSavingEnabled methods to the Logins experiment API - Disable login saving for extension pages on background startup Fixes mozilla-lockwise#57

lmorchard force-pushed the 57-disable-login-saving branch from 59c1ce4 to a6efbfa Compare February 11, 2019 15:18

lmorchard changed the title ~~WIP: Disable prompts to save logins while on extension pages~~ Disable prompts to save logins while on extension pages Feb 11, 2019

lmorchard merged commit 10feb59 into mozilla-lockwise:master Feb 11, 2019

ghost removed the in progress label Feb 11, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Disable prompts to save logins while on extension pages #74

Disable prompts to save logins while on extension pages #74

lmorchard commented Feb 6, 2019

lmorchard Feb 6, 2019

jaredhirsch Feb 8, 2019

linuxwolf Feb 8, 2019

lmorchard Feb 6, 2019

jaredhirsch Feb 8, 2019

lmorchard commented Feb 6, 2019

meandavejustice left a comment •

edited

linuxwolf commented Feb 8, 2019 •

edited

linuxwolf left a comment

jaredhirsch left a comment

jaredhirsch Feb 8, 2019

lmorchard Feb 8, 2019

jaredhirsch Feb 8, 2019

jaredhirsch Feb 8, 2019

jaredhirsch Feb 8, 2019

jaredhirsch Feb 8, 2019

jaredhirsch Feb 8, 2019

jaredhirsch Feb 8, 2019

lmorchard Feb 8, 2019

jaredhirsch Feb 8, 2019

jaredhirsch Feb 8, 2019

jaredhirsch commented Feb 8, 2019

lmorchard commented Feb 8, 2019 •

edited

lmorchard commented Feb 11, 2019 •

edited

punkbusterdani commented Apr 24, 2019

Navigation Menu

Disable prompts to save logins while on extension pages #74

Disable prompts to save logins while on extension pages #74

Conversation

lmorchard commented Feb 6, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lmorchard commented Feb 6, 2019

meandavejustice left a comment • edited

Choose a reason for hiding this comment

linuxwolf commented Feb 8, 2019 • edited

linuxwolf left a comment

Choose a reason for hiding this comment

jaredhirsch left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jaredhirsch commented Feb 8, 2019

lmorchard commented Feb 8, 2019 • edited

lmorchard commented Feb 11, 2019 • edited

punkbusterdani commented Apr 24, 2019

meandavejustice left a comment •

edited

linuxwolf commented Feb 8, 2019 •

edited

lmorchard commented Feb 8, 2019 •

edited

lmorchard commented Feb 11, 2019 •

edited