security.insecure_password.ui.enabled false, versus Snap HTTP Padlocks on Waterfox

E&OE … I've been through a few drafts of this (!) … there's a simple tl;dr at the foot.

## Steps

1. Waterfox 56.2.0
2. install [Snap HTTP Padlocks](https://addons.mozilla.org/addon/snap-http-padlocks/) (Snapped Padlocks) 1.0.2
3. visit
4. new tab
5. visit
6. click PANEL
7. dismiss (refrain from using) the HTTP login
6. in both tabs, observe the padlocks
7. new tab
8. about:config?filter=security.insecure
9. security.insecure_password.ui.enabled
10. toggle it from `true` (its default) to `false`
11. bring to front the tabs that were used for steps (3) and (5)

## Expected (desired)

- a sign of insecurity

## Actual result

- neither tab bears a sign

## Thoughts

Difficult to express at the moment (sorry) … I imagined that `security.insecure_password.ui.enabled` `false` would be inferior to the broader effect of Snap HTTP Padlocks.

----

To put things another way: I typically choose to not enable the extension, because I learnt long ago to always infer from the **absence of a green padlock** that – **overall** – a _page_ e.g. **and its content** (including, maybe, a form) are insecure.

So (still without enabling the extension) I don't need anything other than the absence of green at e.g. , and so **for consistency** (or should I say, 'no-nanny'?) I naturally lean towards `security.insecure_password.ui.enabled` `false`.

Then when enabling Snap HTTP Padlocks I'm surprised at it having no effect.

I wonder … is my natural leaning, towards not requiring a password-specific nanny (i.e. a learnt understanding of the simple absence of green), treated as not natural by Mozilla? :-)

----

# tl;dr

I'd like Snap HTTP Padlocks (or any comparable extension) to be **not** dumbed-down by e.g. `security.insecure_password.ui.enabled` `false`.

(Phrases such as _no-nanny_ and _dumbed-down_ phrases are not intended to be inflammatory, here. Just frank. Hope that's OK.)