The "Glyph bbox was incorrect" is a Firefox warning about
incorrect bounding box values in the font. The icon font, including
the incorrect bounding box values is generatedby icomoon.
I ran the TTF file through fontsquirrel and that seems to have
fixed the issue.
More about this warning: https://bugzilla.mozilla.org/show_bug.cgi?id=1847959
When user double-clicks on text, browser selects a single word.
When user triple-clicks, browser selects a line or a paragraph
of text.
We have JS code that enables user to click on ping URL to copy
it to the clipboard. After copying it shows a small non-native
tooltip saying "Copied!" above the ping URL. This was interfering
with triple-click selection, the word "Copied!" would get selected
as well.
The fix is to use document body as the container of the tooltip,
not the ping URL span (which is the default).
Previously, if the user enters a weak password like "qwerty",
the score is 0, the password strength bar is empty (all gray).
It is easy to not notice the password strength bar at all.
Now, the lowest score for a non-empty password is 1, meaning
the user will see one red bar. This will hopefully draw more
attention to the password strength bar.
Users are still allowed to choose weak passwords.
We already have a MS Teams integration but MS Teams is discontinuing
the incoming webhook feature used by this integration:
https://devblogs.microsoft.com/microsoft365dev/retirement-of-office-365-connectors-within-microsoft-teams/
MS Teams now recommends to use Workflows to post messages
via webhook. MS Teams does not provide backwards compatibility or
an upgrade path for existing integrations.
This commit adds a new "msteamsw" integration which uses MS Teams
Workflows to post notifications. It also updates the instructions
and illustrations in the "Add MS Teams Integration" page.
cc: #1024
The live-updating code still needs float timestamps, but
we only need them for the most recent event (so we know
the lower threshold for fetching new events). We now send
the float timestamp separately:
* in the `/log/` view, we put it in HTML content, in a <script> tag
* in the `/log_events/` view we put it in response header
The main benefit of this is smaller response sizes for the
`/log/` and `/log_events/` views.
* look up the favicon DOM element only once
* update the favicon only if title changes, not on every refresh
* details.js: use the base URL when constructing favicon URL
