/**
 * multicloud_showpass — estilo do botão "mostrar/ocultar senha".
 *
 * Carregado só na task `login` (ver `multicloud_showpass.php`). Usa os
 * MESMOS tokens `--mc-*` que `skin/multicloud/styles/styles.css` declara em
 * `:root` (eles não são escopados à tela de login, ficam disponíveis em
 * qualquer página que carregue a skin) -- ver a skill de frontend, seção 6:
 * "mexeu na paleta de um, mexe no outro" também vale aqui, embora este
 * arquivo só LEIA os tokens, não os redeclare.
 *
 * O `<button>` real (não âncora) é neutralizado com `all: unset` antes de
 * receber estilo próprio -- é o que evita o carimbo `.btn.btn-secondary`
 * que o `bootstrap_style()` do ui.js aplica a todo <button> da página (ver
 * o comentário de classe do .php para o raciocínio completo).
 *
 * ⚠️ TODAS as declarações de `.mc-showpass-toggle` (inclusive `all: unset`)
 * levam `!important`, e isto foi MEDIDO, não suposto: testado por CDP contra
 * as duas páginas de login REAIS (`webmail.multicloudsolutions.com.br` e
 * `webmail.andersonsiqueira.com`), simulando o carimbo do `bootstrap_style()`
 * (`btn.classList.add('btn','btn-secondary')`) -- no tema CLARO `all: unset`
 * sem `!important` já bastava (nada mudava), mas no tema ESCURO o
 * `background-color` do botão MUDAVA de transparente para
 * `rgb(77, 96, 102)`: a folha da elastic tem uma regra de dark-mode para
 * `.btn-secondary` com especificidade maior que uma classe só
 * (`.mc-showpass-toggle`, 0-1-0) -- provavelmente algo como
 * `html.dark-mode .btn-secondary` (0-2-0) ou mais. `!important` em CADA
 * declaração (não só em `all`) é necessário porque, dentro da MESMA regra,
 * uma declaração posterior sem `!important` NÃO sobrescreve uma anterior
 * `!important` para a mesma propriedade lógica (`all` se expande para todo
 * o resto) -- sem isso, `position`/`display`/cor etc. abaixo ficariam presos
 * no valor `unset`.
 */

/* `.mc-showpass-anchor` é o PRÓPRIO PAI do campo (`input.parentElement`,
   posto pelo JS) -- nunca um `<span>` novo envolvendo o input. Confirmado
   contra o DOM REAL por CDP (`ui.js` da elastic monta
   `<td class="input input-group input-group-lg">` com o ícone e o input
   como filhos DIRETOS de um `display:flex` do Bootstrap): um wrap novo
   tirava o input de ser filho direto do `.input-group` e quebrava o
   `flex: 1 1 auto` que o Bootstrap dá a `.input-group > .form-control`,
   fazendo o campo encolher para o conteúdo. `position: relative` aqui é
   redundante no `.input-group` real (o Bootstrap já declara isso), mas
   necessário no `<td class="input">` simples que a tela de login usa para
   OUTROS campos de senha que não venham dentro de um input-group. */
.mc-showpass-anchor {
    position: relative;
}

/* `.form-control` já é `box-sizing: border-box` (Bootstrap) -- acrescentar
   padding-right não muda a largura do campo, só reduz o espaço de texto.
   Isto é o que garante "sem deslocamento de layout": nenhuma medida do
   próprio campo (altura, largura, margem) muda por causa do botão.
   `box-sizing: border-box` é declarado aqui TAMBÉM, de propósito, e não só
   assumido do Bootstrap: medido no harness (`tests/harness.html`, que não
   carrega `bootstrap.min.css` -- só vem na imagem do Roundcube, fora deste
   repositório) sem esta linha, o `padding-right` sozinho ACRESCENTAVA ~44px
   de largura ao campo (content-box) e criava overflow horizontal que a
   produção não teria. Declarar aqui deixa de depender da ORDEM de carga do
   Bootstrap para este campo especificamente. Seletor por atributo
   (`[data-mc-showpass-wired]`, posto pelo JS no próprio input), não por
   `.mc-showpass-anchor input` puro -- o anchor pode ter mais de um input NÃO
   relacionado (não é o caso hoje, mas o seletor por atributo não depende
   disso continuar assim). */
.mc-showpass-anchor input[data-mc-showpass-wired] {
    box-sizing: border-box !important;
    padding-right: 2.75rem !important;
}

/* `top: 0; bottom: 0` (não `top: 50% + transform`) de propósito: o botão
   ocupa a altura INTEIRA do campo, nunca mais que isso. Medido no harness
   (`tests/harness.html`) com um campo de teste mais baixo que 40px: um
   botão de altura FIXA de 40px, centralizado por transform, invadia a
   LINHA VIZINHA da tabela de login (a `<tr>` de cima) -- o mesmo tipo de
   defeito que a skill de frontend documenta para alvo de toque por
   `::before` invisível (nunca resolver 44px por overlap, sempre por
   layout), só que aqui com o próprio botão real. Esticar do topo à base do
   campo garante altura de toque = altura do campo, sempre, sem invadir a
   linha vizinha nem crescer o `<tr>` -- na tela de login real (com o
   `padding`/`line-height` do Bootstrap que este harness não carrega por
   inteiro) o campo já fica perto de 40px de altura sozinho. */
/* `z-index: 5` -- achado por CDP contra as páginas reais, não suposto: com
   `document.elementFromPoint()` no centro do botão, o alvo voltava o
   `<input>`, não o botão -- o Bootstrap eleva `.input-group .form-control`
   para `z-index: 3` quando o campo tem foco (regra de sempre do
   input-group, para o campo focado desenhar por cima da borda dos
   vizinhos), e o próprio `input.focus()` que este plugin chama no clique
   do botão (para devolver o foco ao campo depois de alternar o tipo)
   deixava o INPUT por cima do BOTÃO na pilha de empilhamento -- o ícone
   ainda podia aparecer visualmente (dependendo do navegador/composição),
   mas um clique ali batia no campo, não no botão. `5` fica acima de
   qualquer z-index de input-group do Bootstrap (que usa no máximo 3). */
.mc-showpass-toggle {
    all: unset !important;
    box-sizing: border-box !important;
    position: absolute !important;
    z-index: 5 !important;
    top: 0 !important;
    bottom: 0 !important;
    right: 0 !important;
    display: flex !important;
    align-items: center !important;
    justify-content: center !important;
    width: 2.5rem !important;
    min-width: 40px !important;
    border-radius: var(--mc-radius-sm, 9px) !important;
    cursor: pointer !important;
    color: rgba(15, 23, 42, .55) !important;
    background-color: transparent !important;
}

.mc-showpass-toggle svg {
    width: 20px !important;
    height: 20px !important;
    pointer-events: none !important;
}

.mc-showpass-toggle:hover {
    color: var(--mc-royal, #2563eb) !important;
    background-color: rgba(37, 99, 235, .08) !important;
}

/* `:focus-visible` (não `:focus` puro) -- este é um BOTÃO, não um campo de
   texto; a skill de frontend (seção 9) documenta a mesma distinção no site:
   botão/link usa `:focus-visible` porque o próprio clique já é feedback, o
   anel serve a quem navega por teclado. */
.mc-showpass-toggle:focus-visible {
    outline: 2px solid var(--mc-royal, #2563eb) !important;
    outline-offset: 1px !important;
}

html.dark-mode .mc-showpass-toggle {
    color: rgba(230, 236, 247, .65) !important;
}

html.dark-mode .mc-showpass-toggle:hover {
    color: var(--mc-sky, #38bdf8) !important;
    background-color: rgba(56, 189, 248, .12) !important;
}

html.dark-mode .mc-showpass-toggle:focus-visible {
    outline-color: var(--mc-sky, #38bdf8) !important;
}

/* Celular: nenhuma regra própria necessária -- o botão é `position:
   absolute` dentro de `.mc-showpass-anchor` (`position: relative`), então
   ele nunca acrescenta largura ao campo nem ao `<td>`/`.input-group` que o
   envolve, em nenhuma largura de tela -- e, por ser `position: absolute`,
   também não entra no cálculo de `flex` do `.input-group` do Bootstrap
   (elemento fora de fluxo não conta como item flex), então o ícone à
   esquerda e o campo mantêm exatamente a largura que já tinham. */