Najgłupszy kod na crashowanie IE

0

Dzisiaj sobie pracowałem. Pisałem jedno zlecenie, dobra. I teraz rozkład czasu:
Rozplanowanie co i jak - 15 minut.
Napisanie skryptu - godzina.
Dostosowanie go do różnych przeglądarek - 30 minut.
Panikarskie szukanie przyczyny błędu return poza ciałem funkcji w kodzie:

function a() { //stub
return true;
}

pod internet explorerem - 2 godziny.

Tak więc ogłaszam kod na najdziwniejszego forka pod IE6 lub wyższe, w HTML, JS i/lub CSS (wierzcie, takie też są :D), żeby wykorzystać go do mojego podłego planu wsadzenia go do skryptów pisanych przeze mnie i udawania że u mnie działa [diabel]

Każdy może zgłosić dowolną liczbę kodów, jak zbierze się tego sporo, zrobimy głosowanie który kod jest najbardziej pojebany. Do dzieła!

0 
var tbl = document.createElement("table"); 
tbl.innerHTML = "<tr><td>bla</td></tr>";
document.body.appendChild(tbl);

Unknown runtime error, niech się developerzy wkurzają [diabel]

  • http:*icośtam.pl/tmp/4p/pan_kuba.html na ie7 faktycznie - Q
0

Pod IE6 także: user image

Albo przypisywanie niepoprawnych wartości do stylów, np.
element.style.display = "block"; Też potrafi wywalić błąd, jeśli element nie będzie obsługiwał danego stylu. Nie jest to ignorowane, jak w FF, tylko jakiś głupi błąd..

0

@Demonical Monk:
Huh? Gdzie tam masz return poza ciałem funkcji? Miałeś funkcję składającą się tylko z jednej instrukcji return i niczego poza tym i on Ci wywalił taki błąd? :o

@Pan kuba:
To dość znany problem z IE i tabelami. Raz, że IE potrafi sobie dodać tbody do tabeli wirtualnie, a dwa, że w ogóle nie przepada za ustawianiem innerHTML w tabelach. Polecam tutaj użyć metod DOM (np. createElement) oraz metod elementów DOM table i tr -- odpowiednio insertRow i insertCell.

0

Taka ciekawostka którą zaobserwowałem wcześniej podczas pisania tego kodu na zlecenie, co return wywalał przytoczony wyżej błąd.

<body onload="wtfck();">
<select id="select1">
<option value="sanki">Sanki</option>
<option value="buty">Buty</option>
<script type="text/javascript">
function wtfck() {
document.getElementById('select1').innerHTML = '<option value="pucybut">Pucybut</option>';
}
</script>
</body>

To przynajmniej u mnie zawsze powodowało freeza jak c*** i zachodziłem w głowę co się dzieje. Debuger oczywiście nic nie pokazywał. Okazuje się że IE nie radzi sobie z item-index po podmianie opcji. Pomaga dopiero podmiana całego selecta.

0

Nie prościej załączyć 32 CSSy? ;)

0

@somekind:
32 CSS-y to potężny problem wydajnościowy w każdej przeglądarce i w zasadzie na każdej stronie internetowej (chyba że kompletnie nikt tam nie wchodzi i serwer nie ma żadnego obciążenia, choć i tak...).

Najgorsze są moim zdaniem te błędy przeglądarki, które ujawniają się, gdy piszesz -- a przynajmniej starasz się napisać -- normalny kod. Te rzeczy, o których pisał @Demonical Monk, musiałbym jeszcze sprawdzić, bo się na nie nie natknąłem, ale np. problemy z tabelami znam. Pisałem sobie taką prostą funkcję, która potrafiła stworzyć i zwrócić drzewo DOM na podstawie podanego HTML-a. Nic szczególnego -- ot, takie coś na parę linijek oparte o innerHTML. Zdziwiłem się, gdy w IE nieraz to nie działało. Nie działało (i to wrednie) tworzenie np. elementu tr, bo funkcja używała bodajże div-a jako elementu opakowującego, do którego chciała wrzucić tego tr-a. IE się na tym wykrzaczał, a funkcja się "troszkę" skomplikowała.

0

Taka ciekawostka którą zaobserwowałem wcześniej podczas pisania tego kodu na zlecenie, co return wywalał przytoczony wyżej błąd.

<body onload="wtfck();">
<select id="select1">
<option value="sanki">Sanki</option>
<option value="buty">Buty</option>
<script type="text/javascript">
function wtfck() {
document.getElementById('select1').innerHTML = '<option value="pucybut">Pucybut</option>';
}
</script>
</body>

To przynajmniej u mnie zawsze powodowało freeza jak c*** i zachodziłem w głowę co się dzieje. Debuger oczywiście nic nie pokazywał. Okazuje się że IE nie radzi sobie z item-index po podmianie opcji. Pomaga dopiero podmiana całego selecta.

Co ciekawe w nowszych wersjach zdaje się, że UI się nie freezuje (formularze, inputy etc.), otwarcie selecta zajmuje kilka dłuższych chwil i nie ma on żadnych opcji, co przy pisaniu czegoś opartego o AJAX potrafi przyprawić o niezłe nerwy, bo tak na prawdę nie wiesz gdzie co zawiodło, a debugery nie są zbyt precyzyjne pod IE. Za każdym razem zostaje debugowanie "przez dupcenie" jako najgłupsze i jedyne co można zrobić...

0

@Demonical Monk:
Btw. czy był jakiś powód, dla którego innerHTML by zmienić opcje w selekcie? Jakoś nie widzę wielkich plusów korzystania z tego rozwiązania zamiast metod DOM (i rozszerzeń DOM dla elementów HTML). Ja preferuję innerHTML w szablonach, gdzie kod jest bardziej skomplikowany, a także wtedy gdy są problemy z wydajnością. innerHTML jest zwykle szybsze niż DOM, ale w tym wypadku jednak najwidoczniej tak nie było.

Więc użyłbym tu raczej funkcji. Tym bardziej, że kod wewnątrz selekta jest bardzo prosty -- łatwo można by było stworzyć tych parę elementów option, ustawić ich wartości i dodać do selekta.

Przychodzi mi do głowy jedynie to, że może lista opcji była zwracana przez serwer, jako odpowiedź na żądanie ajaxowe. Ale nawet wtedy, jeśli serwer ma wypluć liczbę opcji, czyli par etykieta/wartość, to logiczne byłoby przesłanie tego JSON-em i dodanie za pomocą metod DOM. Mam wrażenie, może nie do końca słuszne, że zapewniłoby to odrobinę więcej bezpieczeństwa. Bo czuję lekki niepokój, gdy wstrzykuję zwrócony z serwera HTML praktycznie nie sprawdzając nawet jego struktury. A gdy już wstrzykuję tak kod do formularza, to niepokój wzrasta jeszcze bardziej. JSON i ręczna modyfikacja DOM u siebie wydaje się odrobinę bezpieczniejszym podejściem.

Fakt, skrypt po stronie klienta trochę by się rozrósł, ale tylko trochę. Nie przepadam za ręcznym budowaniem skomplikowanego drzewa DOM -- kod jest wielki, nieczytelny i koszmarny -- ale zmiana opcji w selekcie leży jeszcze w zasięgu, gdzie opłaca się używać metod DOM.

Przyznaję, że debugowanie pod IE, szczególnie pod tymi starszymi, do najprzyjemniejszych nie należy. W zasadzie to jestem spokojny tylko wówczas gdy po zobaczeniu błędu niemal od razu wiem, który z bugów IE za to odpowiada. A jak jest np. 10 000 linii kodu i "coś nie działa", a ja nie mam pojęcia co i dlaczego... Nie jest to najbardziej komfortowa sytuacja ;). "Dupcenie" było śmieszne, ale w liceum i na początku studiów. Przynajmniej w sensie debugowania.

0

Jeśli chodzi o opcje w <select> to dodam, że pod IE nie można ich ukryć. Nie działa style.display = "none" ani style.visibility = "hidden"

0

Dzisiaj popełniłem dość prosty błąd, przekazywałem sobie parametr do jednej z funkcji i napisałem coś takiego:

funkcja(
{
   opcja: costam,
   drugaopcja: costaminnego,
});

Oczywiście błędem jest przecinek po drugim elemencie - ot, często zapomina się o nim, gdy na bieżąco zmieniamy sobie dane opcje w poszukiwaniu idealnego rozwiązania (tutaj chodziło akurat o mapy google).
Najlepsze jest to, że Firefox sobie to zignorował i wszystko działało. Internet Explorer 8.0.7 sobie to zignorował, to pomyślałem, że całość działać będzie w porządku i poszedłem do domu. Później dostałem telefon, że mapka nie działa, okazało się, że Internet Explorer 8.0.6 już takiej pomyłki nie przepuścił :>.

0
bswierczynski napisał(a)

@somekind:
32 CSS-y to potężny problem wydajnościowy w każdej przeglądarce i w zasadzie na każdej stronie internetowej (chyba że kompletnie nikt tam nie wchodzi i serwer nie ma żadnego obciążenia, choć i tak...).

Robiąc prototyp (ma być szybko, użytkowników niewielu) aplikacji działającej w sieci LAN (użytkowników niewielu, optymalizacja ruchu bez znaczenia) korzystając z komponentów Telerika (niemalże każda kontrolka ma swoje oddzielne style) można pewne rzeczy pominąć, bo w takiej sytuacji nie stanowią problemu wydajnościowego. No, ale nie można, bo IE szaleje.

0

@somekind:
W ogóle w kodzie mocno podzielonym na komponenty zdarza się, że na stronie jest kilkadziesiąt arkuszy stylów lub kilkadziesiąt skryptów. Sam takie coś napisałem (naturalnie z możliwością scalenia plików gdy zajdzie taka potrzeba), ale to nie było do internetu, tylko locala, ew. LAN-a właśnie (wystawienie czegoś na LAN kojarzy mi się raczej z intranetem niż Internetem ;-)). Tylko u mnie tylu arkuszy stylów nie było, za to skryptów było parędziesiąt i IE jakoś to znosi.

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