ilibras-widget 1.5.0 → 1.5.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +53 -0
- package/dist/ilibras-widget.cjs +98 -94
- package/dist/ilibras-widget.js +98 -94
- package/dist/ilibras-widget.mjs +98 -94
- package/package.json +1 -1
package/CHANGELOG.md
CHANGED
|
@@ -4,6 +4,59 @@ Todas as mudanças notáveis neste projeto serão documentadas neste arquivo.
|
|
|
4
4
|
|
|
5
5
|
---
|
|
6
6
|
|
|
7
|
+
## [1.5.2] - 2026-09-18
|
|
8
|
+
|
|
9
|
+
### 🗂️ Uma aba, não duas
|
|
10
|
+
|
|
11
|
+
Ao criar o atendimento, o widget abria a aba nova **e** trocava a página da aba
|
|
12
|
+
atual. A pessoa terminava com duas.
|
|
13
|
+
|
|
14
|
+
A causa estava no plano B para pop-up bloqueado:
|
|
15
|
+
|
|
16
|
+
```js
|
|
17
|
+
const aba = window.open(destino, '_blank', 'noopener');
|
|
18
|
+
if (!aba) window.location.assign(destino);
|
|
19
|
+
```
|
|
20
|
+
|
|
21
|
+
A especificação manda `window.open` devolver `null` sempre que `noopener` está
|
|
22
|
+
presente — **mesmo quando a aba abre**. O teste lia esse `null` como pop-up
|
|
23
|
+
bloqueado, e a segunda linha disparava sempre.
|
|
24
|
+
|
|
25
|
+
Agora a chamada vai sem a feature e a proteção é feita na mão
|
|
26
|
+
(`aba.opener = null`), o que dá o mesmo isolamento e preserva o retorno — que é
|
|
27
|
+
justamente o que distingue aba aberta de aba barrada. O plano B continua de pé
|
|
28
|
+
para quando o pop-up é realmente bloqueado: melhor trocar de página do que
|
|
29
|
+
sumir com um atendimento já criado.
|
|
30
|
+
|
|
31
|
+
---
|
|
32
|
+
|
|
33
|
+
## [1.5.1] - 2026-09-18
|
|
34
|
+
|
|
35
|
+
### 🎨 O tema do site não pinta mais o widget
|
|
36
|
+
|
|
37
|
+
Todas as regras de estilo passaram a ser escopadas por
|
|
38
|
+
`#ilibras-widget-container`.
|
|
39
|
+
|
|
40
|
+
O widget usava seletores de uma classe só — `.ilibras-widget-submit` tem
|
|
41
|
+
especificidade (0,1,0) e perde para qualquer tema que estilize botões com dois
|
|
42
|
+
níveis. Um `.elementor-kit-275 button` é (0,1,1) e vencia.
|
|
43
|
+
|
|
44
|
+
O estrago aparecia num site real: botões verdes, cantos arredondados em 30px e
|
|
45
|
+
o "X" de fechar virado pílula — dentro de um widget cuja promessa é justamente
|
|
46
|
+
se bastar no site dos outros. O botão principal escapava por acidente, porque o
|
|
47
|
+
gradiente dele pintava por cima da cor do tema; o de agendar, sem gradiente,
|
|
48
|
+
ficava verde.
|
|
49
|
+
|
|
50
|
+
Com o prefixo, as regras vão a (1,1,0): ganham de qualquer seletor de tema
|
|
51
|
+
**sem recorrer a `!important`**, e continuam perdendo para o `!important` que o
|
|
52
|
+
README ensina o cliente a usar quando quer customizar de propósito. Quem
|
|
53
|
+
customiza sem `!important` precisa passar a usá-lo.
|
|
54
|
+
|
|
55
|
+
Problema antigo, anterior à v1.5.0 — só ficou visível quando o segundo botão
|
|
56
|
+
entrou no formulário.
|
|
57
|
+
|
|
58
|
+
---
|
|
59
|
+
|
|
7
60
|
## [1.5.0] - 2026-09-18
|
|
8
61
|
|
|
9
62
|
### 🙋 O formulário pede só o nome
|