Dziwne bugi w UI w Coyote

1

screenshot-20220222214732.png

Po odświeżeniu strony jest git.

Niepoprawnie załadowany FontAwesome?

1

Czegoś takiego jeszcze nie widziałem, ale wszystko by wskazywało właśnie na font-awesome.

0

Nie czytałem, być może powiązane -> https://github.com/FortAwesome/Font-Awesome/issues/17644

1
Adam Boduch napisał(a):

Czegoś takiego jeszcze nie widziałem, ale wszystko by wskazywało właśnie na font-awesome.

Czasem się zdarza, że znaki strzałeczek w okruszkach oraz kropki przed komentarzami są renderowane jako krzaki. Powód najpewniej jest ten sam i też odświeżenie strony rozwiązuje problem.

0

Jest to podwójnie dziwna sprawa; bo mam wrażenie że widziałem to już kilka razy na 4programmers.net; ale nie pamiętam żebym kiedykolwiek widział coś podobnego w innych serwisach.

0

Nikt nie wie czym to jest spowodowane :D

2

Znowu.

Czy samo gadanie o tym bugu wywołuje buga? :D

screenshot-20220225095050.png

0

Czy ktoś patrzył do konsoli przed odświeżeniem strony?

1

pytanie bardziej czy komuś innemu się to przydarzyło
jaka przeglądarka?

0

I jeszcze: czy ktoś patrzył w źródło strony przed odświeżeniem strony?

3

Również doświadczyłem tego problemu na mobilnym chrome. ![Screenshot_20210908-072246686[1].jpg]Screenshot_20220225-161711181[1].jpg

Problem pojawił się przy próbie debugowania innego, ale niestety konsola czysta, wyłączony cache, brak jakichś 404 czy coś.

2
jurek1980 napisał(a):

Problem pojawił się przy próbie debugowania innego, ale niestety konsola czysta, wyłączony cache, brak jakichś 404 czy coś.

Następnym razem sprawdź, proszę, jeszcze, jaki kod HTML jest w miejscu tych dziwnych znaków w źródle strony. :)


UPDATE Może pomocne okaże się też sprawdzenie, jakiego kodowania używa przeglądarka, wyświetlając te dziwne znaki.


UPDATE2 Znalazłem taki komunikat na stronie projektu:

Heads up! We changed the unicode values of some of the icons!

In version 5.12.0 we began to use unicode codepoints that fell outside of the defined Private Use Area (PUA). We've corrected this in Version 5.14.0. If you are using icons that were released in 5.12 or 5.13, you'll want to update your unicode values.

~ https://fontawesome.com/v5/docs/web/advanced/css-pseudo-elements

To może być powiązane. @Adam Boduch, jakiej wersji Font Awesome używamy?

1
Silv napisał(a):

jakiej wersji Font Awesome używamy?

Aktualnie 5.15.4.

0

Właśnie mi się to stało znowu. W Network nic podejrzanego, w konsoli żadnych błędów.

0

Mi też się pare razy przytrafiło. Nie mam pojęcia czym to jest spowodowane.

1
666 napisał(a):

https://github.com/FortAwesome/Font-Awesome/issues/17644

Autor font-awesome i sass-loader od webpacka twierdza, że to bug; autor sass/dart-sass twierdzi że to jest by design.

Odkopałem issue, zobaczymy co opiszą.

1

Już kiedyś tutaj na forum dyskutowaliśmy, że odpowiedzialny za tego typu błędy, może być brak nagłówka @charset w CSS. Co ciekawe znajduje się on w plikach SCSS, ale jest wycinany w procesie minifikacji pliku :/

0
Adam Boduch napisał(a):

Już kiedyś tutaj na forum dyskutowaliśmy, że odpowiedzialny za tego typu błędy, może być brak nagłówka @charset w CSS. Co ciekawe znajduje się on w plikach SCSS, ale jest wycinany w procesie minifikacji pliku :/

Autor sass twierdzi że kodowanie można przekazać przez BOM z UTF-8, i na tej podstawie ustalić który kod jest który. A żęby dodać stringa "@charset " to to jest kilka dodatkowych bajtów, jak rozumiem: https://github.com/sass/dart-sass/issues/1387

Dali też workaround:
@charset jest usuwany tylko jeśli się ustawi output: "compressed" tak jak jest w coyote. Gdyby ustawić output: "expanded", to usuwania by nie było, ale wtedy stracilibyśmy kompresje. Moim zdaniem zupełnie nieakceptowalne.

0

Tak, bez kompresji ten nagłówek nie jest usuwany :) Może czas na webpack 5 i aktualizację tych bibliotek? :)

0
Adam Boduch napisał(a):

Tak, bez kompresji ten nagłówek nie jest usuwany :) Może czas na webpack 5 i aktualizację tych bibliotek? :)

Że loaderów? Nie jest fixnięte jeszcze. Autor sass-loader ma podoben zdanie jak Ci od FA i nie wprowadzili żadnej poprawki.

0

@Adam Boduch: Mamy info że update dart-sass do 1.38.0 ma fixa odnośnie dziwnych bugów z font-awesome.

https://github.com/sass/dart-sass/releases/tag/1.38.0

1

U nas jest wersja 1.49.

0

Czy ten błąd nie spotykany jest tylko na Chrome? U siebie na Firefoksie nie spotkałem się z tym.

0
Marooned napisał(a):

Czy ten błąd nie spotykany jest tylko na Chrome? U siebie na Firefoksie nie spotkałem się z tym.

Ja to widziałem chyba 3 razy w życiu.

2

Jak coś, to monitoruję ten bug w font-awesome; rozwiązanie zaproponowane przez nich rok temu działa tylko połowicznie; Issue jest nadal otwarte. Może coś z tego wyniknie.

0

Dziś pierwszy raz mi się to przydarzyło i sprawdzałem źródło problemu.
Okazuje się że to ten sam problem co â–ª
Po pokombinowaniu w kodzie strony z charsetem znaczki się naprawiają nawet bez przeładowania strony, więc to dowód na to że wszystko się dobrze ładuje, ale nie jest określony charset dla stylów.
Rozwiązaniem by było serwowanie w nagłówku http charsetu dla styli:

Content-Type: text/css; charset=utf-8

screenshot-20220407211029.png

tak samo jak to robi choćby google:

screenshot-20220407211128.png

Nie za bardzo rozumiem czemu jest to takim problemem. Bug zgłoszony wieki temu, rozwiązanie proste i znane

1

Jak zatem to zmienić? W nginx? PR mile widziany :)

1 użytkowników online, w tym zalogowanych: 0, gości: 1