Multiple keys are not as easily discoverable as they should be.

[johnhawkinson]

Somewhat similar to #5, when I added a second key to the TOTP extension, it seemed to me that it was broken.

Previously, I had always clicked on the toolbar icon, and it showed me the complete list of keys (of which there was one!) along with the TOTP code. I expected that what was a list of 1 would become a list of 2.

I went so far as to search existing Issues and found #5 and watched the video and said, "doh!"

The current implementation requires a click in the blank search box in order to display the list of keys, which is not what I expected! Where we had a list of keys before, having no list and being forced to waste an extra click (now it is 3 clicks where it used to be 2) feels like a step backward. Instead it shows "XXXXXX" which makes me think, "corrupt key list," not…well, I'm not sure what the XXXXXX is supposed to indicate.

Can the UI be altered so that a second click (one for the icon, one for the searchbox) is not required to display the list of keys?
I understand that maybe calculating all keys in the list might be prohibitively expensive (not for the 2 keys I have, but for some alternative situations), but at least enumeraing them would be helpful. Or at least some way to make the UI more discoverable.

In addition to discoverability, I value speed and economy of motion. I would prefer not to have three mouse clicks where two would do.

Thanks! Let me know if you need screenshots.

[turistu]

The current implementation requires a click in the blank search box in order to display the list of keys, which is not what I expected! Where we had a list of keys before, having no list and being forced to waste an extra click (now it is 3 clicks where it used to be 2) feels like a step backward. Instead it shows "XXXXXX" which makes me think, "corrupt key list," not…well, I'm not sure what the XXXXXX is supposed to indicate.

I agree with you that that's annoying, but that's down to how user/password forms work in the browser -- and the code from the popup window is just a simple user/password form, only with its "password" field hidden via css (in fact, it's the very same form from the "save key" page; what looks like a "search box" is actually just the "user" field).

The way user/pass forms work in all browsers (and which is admittedly quite confusing, though in 30 years most people got used to it ;-)) is like this: if there is a single user/password saved, the browser will complete it right away upon loading the the page; if there are multiple user/passwords saved, the inputs will stay blank (just as if no passwords were saved!) and you'll have to click inside the user field in order to get a drop-down list from where to select a user.

Can the UI be altered so that a second click (one for the icon, one for the searchbox) is not required to display the list of keys?

It probably can, with some tricks. I will try to put something together, though I don't think I will make it the default

[johnhawkinson]

Thanks for the speedy response.

I agree with you that that's annoying, but that's down to how user/password forms work in the browser -- and the code from the popup window is just a simple user/password form, only with its "password" field hidden via css (in fact, it's the very same form from the "save key" page; what looks like a "search box" is actually just the "user" field).

I'd push back a little bit on this — it doesn't look like a username field to a user, in part because it lacks the usual UI affordances for such things. Username fields are accompanied by some labels and context, both of which are missing here. Indeed, it almost doesn't look like field at all, it looks like a small wide white rectangle with a narrow border.

Indeed, if the current structure stays, one solution would be to add a label for the field (whether to its left, or perhaps as greyed out placeholder text within the field) that gives some indication that typing in it — and therefore clicking — is necessary to see the enumeration of TOTP sites/keys.

There's also a funny UX thing going on here, that I don't quite know what to make of, that when I use a new tool for the first time, I'm prepared to feel my way around it and learn its quirks. But when I have been using a tool and have gotten used to it, and suddenly one day it behaves differently, I am less prepared for that. So having learned how the TOTP extension works with a single key, I was not expecting its usage and behavior to change when I added a second key, and was perhaps less prepared to explore the UI (And more preapred to conclude it was a bug!) than I would have been at the outset. I'm not sure this UX psychological analysis of myself is correct.

(It also suggests that ideally, the UI should not be meaningfully different when there is a single key saved versus when there are two. Although maybe it should.)

The way user/pass forms work in all browsers (and which is admittedly quite confusing, though in 30 years most people got used to it ;-))

I don't think we had username/password autocompletion in browsers in 1995 ;) Firefox Lockbox was 2019.
But I take your point. (But again, generally there are more contextual clues.)

Can the UI be altered so that a second click (one for the icon, one for the searchbox) is not required to display the list of keys?

It probably can, with some tricks. I will try to put something together,

Great, thanks.

though I don't think I will make it the default

Hmm. Well, I guess it depends on how successful a UI it is, but if it solves the problems I outlined without creating new ones, surely it's better for everyone? I'll wait to see. But if not, then perhaps something in the labeling space discussed above might be appropriate for the default case.

[johnhawkinson]

Happy holidays, @turistu. Did you get a chance to look into this, or maybe to explain your thinking on the UX issues?
(I was reminded of this today using this tool again, so thanks for it!)

[turistu]

I had looked into that immediately afterwards, but the solutions that I had found weren't great: they involved either

• use of the local storage to store the list of saved labels (excluded by design), or
• saving the list of labels as an extra "password" -- which means that the user would have to click two save buttons (one for the key, and one to add the label to the "quick access list"): quite unwieldly and obtuse, especially when removing a key -- the use would have to manually edit the list in the password manager.

That UX issue would be better solved in the browser itself -- for instance, they could display a "click for a list" placeholder on any input element when there are saved values that could be autocompleted. Such a thing could've been done with old-style bootstrapped or xul extensions, but doesn't look possible within the limits of the webextension api.

[turistu]

That UX issue would be better solved in the browser itself -- for instance, they could display a "click for a list" placeholder on any input element when there are saved values that could be autocompleted. Such a thing could've been done with old-style bootstrapped or xul extensions, but doesn't look possible within the limits of the webextension api.

Offtopic, but there are a lot of things that could've been improved that way: for instance

• the browser could've implemented the "show password" toggle itself instead of forcing each website to do it in its own quirky and unsafe way (that's one thing that the Microsoft Edge browser got right!)
• when looking through the autocompletion list, the entire string could've been considered, not just its beginning: for instance, starting to type github in the input would've shown both github / foo@bar and quux@google.com / github in the dropdown list, not just the first.

[johnhawkinson]

This placeholder seems to work for me. It seems inelegant but still an improvement from where we were?:

Obviously the CSS color change is not necessary, although may be helpful.

diff --git a/form.html b/form.html
index 58720f5..9627690 100644
--- a/form.html
+++ b/form.html
@@ -11,6 +11,8 @@
 #CODE[title^="copied!"]::after { color: green }
 
 input, button { font: inherit }
+input::placeholder { /* Standard syntax (Chrome, Firefox, Opera, Safari 10.1+) */
+    color: slateblue; }
 #USER, #KEY { box-sizing: border-box; width: 100%; max-width: 25em }
 button { max-width: max-content }
 #ADD { display: none }
@@ -24,7 +26,7 @@ button { max-width: max-content }
 
 <form id=FORM>
   <label for=USER>User</label><br>
-  <input id=USER size=27 autocomplete=username>
+  <input id=USER size=27 autocomplete=username placeholder="(click for site list)">
   <p>
     <label for=KEY>Shared Key</label>
     <label><input type=checkbox id=SHOW>show</label><br>

[turistu]

This placeholder seems to work for me. It seems inelegant but still an improvement for where we were?:

Of course it works, but would't it also show when there are no inputs saved?

[johnhawkinson]

Going back to my original:

The current implementation requires a click in the blank search box in order to display the list of keys, which is not what I expected! Where we had a list of keys before, having no list and being forced to waste an extra click (now it is 3 clicks where it used to be 2) feels like a step backward. Instead it shows "XXXXXX" which makes me think, "corrupt key list," not…well, I'm not sure what the XXXXXX is supposed to indicate.

What actually is the XXXXXX supposed to be indicating?

[johnhawkinson]

This placeholder seems to work for me. It seems inelegant but still an improvement for where we were?:

Of course it works, but would't it also show when there are no inputs saved?

That seems a little less perfect, but isn't it worth the tradeoff? You click for a list when there is no list and nothing happens, so…okay?

[turistu]

Going back to my original:

The current implementation requires a click in the blank search box in order to display the list of keys, which is not what I expected! Where we had a list of keys before, having no list and being forced to waste an extra click (now it is 3 clicks where it used to be 2) feels like a step backward. Instead it shows "XXXXXX" which makes me think, "corrupt key list," not…well, I'm not sure what the XXXXXX is supposed to indicate.

What actually is the XXXXXX supposed to be indicating?

They're like a ... placeholder ;-)

That could use a css :empty::before combo, so that it could be styled differently (e.g. with the Xs grayed out) and configurable via userContent.css, but that would only add even more css silliness to a thing that is already chock full of it.

--- a/form.html
+++ b/form.html
@@ -9,6 +9,7 @@
 #CODE { font: 250% monospace; letter-spacing: .15em; user-select: all }
 #CODE::after { all: initial; content: ' ' attr(title); color: red; pointer-events: none }
 #CODE[title^="copied!"]::after { color: green }
+#CODE:empty::before { content: '000000'; color: lightgray }

 input, button { font: inherit }
 #USER, #KEY { box-sizing: border-box; width: 100%; max-width: 25em }
@@ -31,7 +32,7 @@ button { max-width: max-content }
     <input id=KEY size=27 autocomplete=current-password type=password pattern="[a-zA-Z2-7\s]+">
     <output for=KEY id=ERROR></output>
   </p>
-  <output for=KEY id=CODE>XXXXXX</output>
+  <output for=KEY id=CODE></output>
   <a id=ADD href target=_blank>add key</a>
   <p><button type=button id=GENERATE>Generate TOTP (and copy it to clipboard)</button>
   <p><button>Save the key (with the browser's password manager)</button>

[johnhawkinson]

I think I am still confused. Why do we need or want the XXXXXX at all? Changing it to 000000 leaves me with the same question? I'm not supposed to click on it, I'm not supposed to copy or edit it, why is it there at all?

I'm sorry, I feel like I'm missing something obvious.

When I compared your ffa008a to my patch, of course you skipped this

+input::placeholder { /* Standard syntax (Chrome, Firefox, Opera, Safari 10.1+) */
+    color: slateblue; }

I'm not entirely sure why I styled it that way, but when I look the rendering of mine (3 comments above) and compare it to yours:

…my initial reaction is that mine has an affordance for clicking and yours doesn't. This suggests that maybe the text should be styled just like a link, i.e. colored blue and underlined, so that users feel like they're supposed to click it. That is:

input::placeholder { /* Standard syntax (Chrome, Firefox, Opera, Safari 10.1+) */
    color: blue; text-decoration: underline }

I don't love this, but it seems like the better of several not-great alternatives.

The default grey placeholder color conveys the affordance of "this is a disabled UI element that you are not supposed to click." At least…I think so? I'm trying to think and reason about it intellectually, it's not like i ran a focus group overnight.

Maybe you disagree for good reason, though! UI stuff is awfully subjective and I don't claim to be "correct" here (as if that were even possible).

[turistu]

I think I am still confused. Why do we need or want the XXXXXX at all? Changing it to 000000 leaves me with the same question? I'm not supposed to click on it, I'm not supposed to copy or edit it, why is it there at all?

To fill up the space, and give a hint that it will be replaced with actual data. Notice that with the new code you could easily configure it via chrome/userContent.css either into an empty space or into nothing at all.

I will revert though the default to XXXXXX (though grayed out), since that's what github and other sites are using for the same thing (and that's where I probably unwittingly copycatted it from).

When I compared your ffa008a to my patch, of course you skipped this

+input::placeholder { /* Standard syntax (Chrome, Firefox, Opera, Safari 10.1+) */

• color: slateblue; }

For the placeholder, it's better to respect the default style and the user's choice from userContent.css without forcing them to bring out the !important hammer.

…my initial reaction is that mine has an affordance for clicking and yours doesn't. This suggests that maybe the text should be styled just like a link, i.e. colored blue and underlined, so that users feel like they're supposed to click it. That is:

But it's not a link! If it were a link, clicking on it from a popup will open a new page. And inside a page ctrl/shift-click to open in a new tab/window would work.

The default grey placeholder color conveys the affordance of "this is a disabled UI element that you are not supposed to click." At least…I think so? I'm trying to think and reason about it intellectually, it's not like i ran a focus group overnight.

Maybe you disagree for good reason, though! UI stuff is awfully subjective and I don't claim to be "correct" here (as if that were even possible).

I don't necessarily disagree. Notice that I'm a long time user of focus-follows-pointer + keyboard controlled pointer and arguing about a the firefox UI (which is deeply hostile to any such use, needing ugly kludges in any non click-to-focus window manager to just function at all) feels to me like arguing with native speakers (from the dominating culture) about the correct use of their mother tongue ;-)

[johnhawkinson]

Happy New Year, and sorry for the delay.
I don't think I did a good job of explaining my concerns, so let me try again.

But first:

For the placeholder, it's better to respect the default style and the user's choice from userContent.css without forcing them to bring out the !important hammer.

I think I disagree.
The fraction of users who know about and will configure userContent.css for this extension has to be super small, feels like less than 0.2% of users, one in a five hundred, if that (AMO says there are 635 users).

If we can improve the style and appearance for new users, and do so in a way that makes the tool easier to use, that is much more valuable than the convenience of non-functional style customizations for the very few power users who wish to do so — and it's not like forcing them to use the ! important flag in custom css is taking their choices away.

Anyhow:

…my initial reaction is that mine has an affordance for clicking and yours doesn't. This suggests that maybe the text should be styled just like a link, i.e. colored blue and underlined, so that users feel like they're supposed to click it. That is:

But it's not a link! If it were a link, clicking on it from a popup will open a new page. And inside a page ctrl/shift-click to open in a new tab/window would work.

So, the overarching problem that most concerns me is that the white box does not give the user any idea that they are supposed to click on it. "It does not have an affordance for clicking."

We're talking about this:

Indeed, this was bad enough that the reason I opened this Issue back on Dec. 3 was I genuinely couldn't figure out how to get access to the keys I had saved and thought that I had lost access through a bug after I had added a second key.

So all the things I have proposed in this issue are ways to address that. Automatically displaying the list without a click, or, if a click is necessary, ways to let the user know that they should be clicking.

I agree adding the placeholder text is better than nothing, but I also don't think it is good enough. When I see this:

…obviously the words say to click, but it still doesn't look like something you're supposed to click. The things that look like they should be clicked on are links and buttons. I'm not sure that we should make it a button, or make it look like a button, but we can definitely make it look like a link. (And making it a link doesn't involve the myriad of design decisions associated with buttons and iconography and such.)

So if I sat and reasoned and thought about it, I would probably figure out that I had to click there (I can read! I hope!), but I don't think it would be as convenient or as natural as if it looked like a link or a button or something else that was clickable.

Indeed, the "add key" looks like a link…it is, I guess you could argue, technically a link, but functionally it is not a link. It doesn't behave like a link does, changing what is displayed on in the active frame/region. It instead opens a new tab (ok, sure, like a target=blank link), but the styling of a user interface should reflect how it behaves, not how it is implemented at an underlying low level that the user doesn't see.

However, after you mentioned the case of no inputs being saved, I happened to go through this. (Because I loaded the extension via about:debugging and somehow extension IDs changed and the keys are still saved in the password store but the extension can't find them? Not sure. Presumably restarting the browser will fix this but I haven't tried it.) And with one key only, it looks like this:

So, first of all, we have an established UI decision for what a direction telling the user to click should look like, and it's color: red. (I guess that's from #CODE::after? Not sure. Doesn't matter.)

I don't like this. It seems to me we are telling a user to click in three different ways. "click for site list," "click to copy," and "add key."
They are different colors and different sizes and with different pseudo-markup (that is parens around "(click for site list").

I also don't think red should be used for an advisory direction. Red means something is wrong, like a broken link or an error. This is not that.

It seems to me they are all basically telling the user the same kind of thing (click here, albeit for different purposes) and should be styled similarly.

Returning to this other topic:

I think I am still confused. Why do we need or want the XXXXXX at all? Changing it to 000000 leaves me with the same question? I'm not supposed to click on it, I'm not supposed to copy or edit it, why is it there at all?

To fill up the space, and give a hint that it will be replaced with actual data. Notice that with the new code you could easily configure it via chrome/userContent.css either into an empty space or into nothing at all.

So, it's certainly not a big deal, but I guess I just don't get it.
I don't see why as a user I need or want the hint that it will be replaced with actual data? Indeed, I think having new data appear in an otherwise blank space is far more eyecatching than having placeholder text turn into valid text.

It seems like nothing at all is a better choice for everybody.

But again, I don't think anyone is getting confused by it, and I do think people are getting confused by the blank box, and even by the greyed out placeholder text (for all two people out there running code from your placeholders branch), so both of those seem more important.

Thanks!

p.s.: I should add, for the one site where I have to use TOTP a lot, I ended up pulling your code into a GreaseMonkey script and having it automatically calculate the TOTP code and punch it into the authentication form and submit the form without user intervention. I am not quite sure if this is useful information/feedback for you to have, but I guess it's worth mentioning.

[turistu]

I think I disagree. The fraction of users who know about and will configure userContent.css for this extension has to be super small, feels like less than 0.2% of users, one in a five hundred, if that (AMO says there are 635 users).

It's probably less than a quarter of a user, since all those 635 users have to be bots: I don't think there's any human who runs Firefox with the telemetry turned on ;-)

However, after you mentioned the case of no inputs being saved, I happened to go through this. (Because I loaded the extension via about:debugging and somehow extension IDs changed and the keys are still saved in the password store but the extension can't find them?

Yes, that's the most serious and irritating limitation of this hack. See #8.

That could only be fixed if you have a domain you trust and control (e.g. http://localhost) serve the page instead of moz-extension://UUID, in which case the entire extension could be reduced to a pop-up opening an external url. In fact, since an extension is able the replace the whole content of a page, the "server" could just be a stupid script answering any http request with 200 OK and have the extension fill up the content for it via the webRequest api.

This how I'm using this on Android, where the password manager doesn't work on moz://... extension pages.

Not sure. Presumably restarting the browser will fix this but I haven't tried it.)

No it won't ;-(. You have to copy the passwords over to the new UUID. See this.

So, first of all, we have an established UI decision for what a direction telling the user to click should look like, and it's color: red. (I guess that's from #CODE::after? Not sure. Doesn't matter.)

I don't like this. It seems to me we are telling a user to click in three different ways. "click for site list," "click to copy," and "add key." They are different colors and different sizes and with different pseudo-markup (that is parens around "(click for site list").

I also don't think red should be used for an advisory direction. Red means something is wrong, like a broken link or an error. This is not that.

But there is an error! If that message appears, something went wrong: the extensions was not able to "copy" [1] the TOTP code to the clipboard as it should (because of stupid bugs and limitations in Firefox) and so it asks the user to try it again.

In order to (partially) fix that, the extension would have to require the clipboardWrite, and by that pretend that it needs to acess the clipboard at any time, even when not interacting with the user -- which is an absolute lie.

[1] scare-quotes because on X11 and wayland it does not copy anything at all anywhere: it just informs the display server that it owns the selection and will send it if asked for it.

p.s.: I should add, for the one site where I have to use TOTP a lot, I ended up pulling your code into a GreaseMonkey script and having it automatically calculate the TOTP code and punch it into the authentication form and submit the form without user intervention. I am not quite sure if this is useful information/feedback for you to have, but I guess it's worth mentioning.

Great, that's how it's supposed to be used, rather then trying to work around the self-imposed limitations of this hack (no local storage, no content scripts, no special permissions, etc)

[2] though I suggest you better use a content script directly instead of GreaseMonkey