IE_javascript 기술 아래 ul li가 중첩되었을 때 발생하는 버그, 문제 해결, 솔루션 프로세스 및 경험을 기반으로 합니다.
- WBOY원래의
- 2016-05-16 17:34:421464검색
버그 확인 단계
1. 버그 위치
js 스크립트에서는 스크립트 실행 순서에 따라 콘솔이나 알림을 사용하여 버그가 발생한 코드 간격을 확인한 다음 해당 간격 내에서 버그가 발생한 특정 코드 세그먼트를 추가로 검색할 수 있습니다.
2.버그 수정
제외를 통해 노드 내용을 삽입할 때 버그가 발생했습니다. 처음에는 이 메서드가 IE67 렌더링을 유발하는 것으로 생각했습니다. , 그리고 innerHTML 메소드로 변경했지만 결과는 여전히 잘못되었습니다.
이때 메모리 누수에 대해 생각해봤는데, 문자열의 루프 스플라이싱 중에 메모리 누수를 일으키는 순환 참조나 다른 이유가 있는지 확인하고 싶었습니다. 그러다가 일부 메소드의 마지막에 일부 변수에 null을 할당했습니다. . 메모리 누수를 방지하지만(작동하는지 모르겠지만 적어도 이것을 시도했습니다) 결과는 여전히 작동하지 않습니다.
데이터가 너무 많아서 렌더링 시 충돌이 발생하는 걸까요? 그래서 스플라이싱을 위한 데이터 길이를 줄였고 효과가 있었습니다. 1~3개의 데이터가 있는 경우 렌더링할 수 있습니다. 이는 해당 방법이 정확하다는 것을 의미하지만 3개 이상의 데이터에 대해서는 IE67이 여전히 응답할 수 없습니다. 그래서 계속해서 하나씩 데이터를 삽입하려고 했는데, 한 번에 한 개씩 데이터를 삽입하는 데 문제가 없으면 몇 번 더 삽입할 수 있었지만 IE에서는 여전히 문제가 있었습니다. 사실 이때 내 생각의 흐름은 이미 빗나갔다.
나중에 동료를 만나러 갔는데 그는 이전에 이 문제를 겪은 적이 있는데 IE67에서 레이블이 올바르게 닫히지 않아서 발생했다고 말했습니다. 네, 이것이 이 버그의 진짜 원인입니다. 나중에 스플라이싱된 문자열을 출력한 뒤 서식 도구를 이용해 포맷을 했는데요. 문자열을 스플라이스할 때 발생한 문제를 빨리 발견해서 버그를 빠르게 수정했습니다. 제가 사용하는 온라인 서식 도구: http://tool.chinaz.com/Tools/JsFormat.aspx
3. 테스트
테스트 중에 우리는 IE가 Chrome과 어떻게 비교되는지 확인하기 위해 HTML 코드 문자열을 작성하고 일부 태그를 닫지 않은 상태로 두었습니다.
코드는 다음과 같습니다. 두 번째 li 태그에서는 ul 태그의 태그 중 하나를 해제합니다
- inner li
- inner li
;
< ul>
닫힘오류 발생
- 내부 li
- 내부 li
- 내부 리
위 그림과 같이 IE와 크롬에서는 정상적으로 표시됩니다.다음에는 개발 도구를 통해 디버깅해 보겠습니다.
IE7~9에서는 닫히지 않은 태그에 전송 오류가 있습니다. .
크롬의 상황을 살펴보겠습니다. 세 번째 li는 정상적으로 DOM 트리에 렌더링되고, 오류가 발생한 스팬 태그에 스팬 닫는 태그가 자동으로 추가됩니다.
4. 요약
HTML을 렌더링할 때 각 브라우저, 특히 IE와 기타 브라우저는 다르게 작동합니다. 크롬과 FF의 내결함성 성능은 매우 좋습니다. 정상적으로 닫히지 않는 페이지에 html 태그가 있어도 이를 지능적으로 식별하여 브라우저에서 정상적으로 표시되도록 하므로 문제가 없습니다. 그러나 나쁜 점은 코드에 문제가 있는지 모르고 모든 것이 괜찮다고 생각한다는 것입니다. IE89에서는 이제 이런 방식으로 처리할 수 있게 되었습니다. 페이지 내용에는 문제가 없는 것 같습니다. 그러나 개발 도구를 통해 잘못된 html 코드가 정상적인 DOM 구조를 가지고 있지 않음을 알 수 있습니다. 그러나 IE67은 그러한 기회를 제공하지 않으며, 그렇지 않으면 직접적으로 충돌이 발생합니다.
Chrome은 실수를 허용하지만 IE는 우리에게 더 엄격하지만 IE는 우리에게 더 높은 요구 사항을 적용합니다. 문득 IE가 있으면 좋겠다는 생각이 들었습니다. . .
어느 날 IE에서 DOM 구조를 렌더링할 수 없다는 사실을 발견했다면 코드에 닫히지 않은 태그가 있는지 기억해 보세요.
< ;/ul>