어제 사파리4 베타 겁내 좋다고 글 올렸었는데.
문제를 발견했다.

IE 에서의 메모리릭을 방지하기 위한 여러가지 방법 중,
try-finally 를 사용하는 방법이 있는데, 설명은 치우고 뭐 아래와 같은 식으로 사용하는 방법이다.

(Language : javascript)

1. function testFunction() {
2.  
3.   var aRet = [ 1, 2, 3 ];
4.   ...
5.  
6.   try {
7.     return aRet;
8.   } finally {
9.     aRet = null;
10.   }
11.  
12. }

저렇게 사용했을 때, 다른 브라우저의 경우에는
정상적으로 testFunction 함수의 리턴값으로 [ 1, 2, 3 ] 을 받아오게 되는데,

사파리4 베타는 finally 안에서 셋팅된 값인, null 을 받아온다;
이것때문에 사파리4 에서 작성한 코드가 마구 오동작;

설마 정식 버젼에서는 고쳐지겠지?

버그 리포팅 궈궈.

I found a javascript problem.

We often use the 'try-finally' codes to avoid IE memory leak like below link.

http://dl.getdropbox.com/u/159225/safari4_bug.html

I expect the return value is [ 1, 2, 3 ],
but the function returns null.

I think it's serious bug.
I sincerely hope to fix this.

내용 추가 :

남태가 첨삭 해 줬음.

김태희 ( 때이-위기의 남자 ) 님의 말 :
  IE memory leak as the following link.
  like a below link.
  a 를 쓰던가 아니면 following 을 쓰던가 해주고

김태희 ( 때이-위기의 남자 ) 님의 말 :
  I expected the return value might be [1, 2, 3] but the function returns 'null'.
  I think it's a serious bug.
  마지막 문장 저렇게 써도 다 알아먹으니 걱정말구

영양가 있는 포스팅인가요

(아무도 투표를 안 했어요) 0점

이미 아시는 분들도 있겠지만 Internet Explorer 의 경우는 <TABLE>, <THEAD>, <TBODY>, <TR> 엘리먼트의 innerHTML 이 읽기전용이라서 innerHTML 을 셋팅 할 수 없는 문제가 있습니다.

그리고 <SELECT> 도 innerHTML 가 읽기전용은 아니지만 막상 사용하면 동작이 이상해지는 문제가 있죠.

IE 에서 이런 문제가 있다는 건 많이 알려진 내용인데요, 오늘 팀원 한 분이 제가 짠 코드가 이상하게 동작한다는 제보를 해주셔서 발견한 문제를 공유드립니다.

이 문제는 IE 가 아닌 FireFox 에서만 발생하는 문제인데요, parentNode 가 존재하지 않는 엘리먼트에다가 innerHTML 로 셋팅하려고 할 때 문제가 발생합니다

이를 테면

(Language : javascript)

<table><tr id=”HELLO”></tr></table>
…
var hello = document.getElementById(“HELLO”);
hello.innerHTML = ‘<td>hello</td><td>world</td>’;

위와 같은 코드에서는 hello 의 parentNode 가 존재하기 때문에 문제가 안 생기지만

(Language : javascript)

var hello = document.createElement(‘tr’);
hello.innerHTML = ‘<td>hello</td><td>world</td>’;
alert(hello.innerHTML); // 결과 : helloworld

위의 코드에서는 hello 의 parentNode 가 존재하지 않기 때문에 문제가 생기는 데요,
innerHTML 에서 텍스트 부분만 쏙 빠져서 적용되네요;

모든 종류의 엘리먼트에 대해서 이런 문제가 생기는 건 아닌 것 같고,
조금 테스트 해본 바로는 THEAD, TBODY, TR 엘리먼트의 innerHTML 을 다룰 때 이런 문제가 발생하는 것 같습니다.

내용이 긴데, 3줄 요약하면,

1. 파이어 폭스에서
2. parentNode 노드가 존재하지 않는
3. THEAD, TBODY, TR 엘리먼트의 innerHTML 을 셋팅하면 이상하게 동작한다

DOM 다루실 때 참고해주세요~

영양가 있는 포스팅인가요

(총 2분이 투표해서 2.5점) 2.5점

파이어폭스를 사용하다보며 아래 같은 에러가 나는 경우가 있다.

이 에러로 특별한 문제가 생기는 것도 아니고 에러가 어디서 나오는 건지 메시지 로그만으로는 당췌 알 수가 없어서 나중에 알아보자 미루고 있다가,
어제 회사 팀원이랑 같이 왜 그럴까 페이지를 파헤쳐봤다.

일단 찾은 원인 중 하나(다른게 더 있을지는 모르겠다)는, 다음 조건을 모두 만족하는 경우.

1. HTML 페이지 안에 IFRAME 이 있고,
2. 그 IFRAME 안에 플래시가 있고,
3. 바깥 HTML 의 document 와 IFRAME 내의 document 의 도메인이 서로 다를 때.

찾은 해결 방법은, 두개의 페이지의 document.domain 를 맞춰주거나,
플래시가 들어있는 IFRAME 페이지에서

(Language : javascript)

1. window.onerror = function() { return true; }

이런 식으로 모든 에러를 걍 무시시키는 것.
사실 아직은 정확한 원인도 최선의 해결방법도 모르겠다-_-a

2008년 3월 24일 내용 추가 :

해당 에러만 무시하도록 아래같은 식으로 하면 나야할 에러는 그대로 나니까 디버깅도 문제 없을 듯.

(Language : javascript)

1. window.onerror = function(err) {
2.   return (typeof err == 'string' && err.indexOf('uncaught exception: Location.toString') == 0);
3. };

영양가 있는 포스팅인가요

(총 12분이 투표해서 3.8점) 3.8점

IE 의 currentStyle 과 비슷한 기능을 구현하기 위해서
타브라우저에서 사용되는 getComputedStyle.

윈도용 Safari3 에서는(맥용 Safari 는 테스트 안했다, 맥으로 바꿔키기 귀찮) position 이 absolute 가 아닐 경우 marginRight 가 짜증나게 나온다.
실제 marginRight 값이 아닌, 엘리먼트에서 브라우저 오른쪽 끝 자락까지의 길이로 나오는 것.

결국 getComputedStyle 하기전에 잠깐 position 를 absolute 로 바꿨다가 되돌려놓는 개꽁수를 사용-_-

아 사파리 매니아들은 당췌 이런 브라우저를 왜 좋아하는거야
CSS 만 3 까지 지원하면 다냐.

영양가 있는 포스팅인가요

(총 3분이 투표해서 3.3점) 3.3점

제가 최근에 만든 플러그인들이 사용하는 태터 플러그인 Base 에 문제가 있네요.
플러그인 자체의 문제라기 보다는 플러그인 제작에 Prototype 을 사용했는데 이것 때문에 태터툴즈 기본 자바스크립트가 오작동을 하는 문제가 있습니다.

1. 지금까지 발견된 오작동은 로그인 상태에서 포스트의 내용 상단의 공개 <-> 비공개 전환링크를 클릭했을때 자바스크립트 에러가 나는 점.
   
   
2. 글 쓰거나 수정하는 에디터에서 위지윅모드 <-> HTML모드 전환할때 변경한 내용이 적용이 안되는 점.

어느 순간부터 안되는가 싶어서 왜 그런가 했더니 제가 만든 플러그인 때문에 그랬군요;

이유는 Prototype 에는 Object 객체의 prototype 를 확장시킨 몇가지 메쏘드들이 있는데, 이 함수들이 태터툴즈의 기본 자바스크립트에서 for-in 구문으로 돌릴때 같이 걸려버리게 되고 예상치 못하게 낚여버린 값들을 처리하다가 에러를 뱉어냅니다.

일단 지금 당장 해결방법은 태터 기본 자바스크립트 소스를 고쳐주는 수밖에 없지만 이건 너무 무책임하고...

Prototype 이 아닌 (Object 를 extend 하지 않는) 다른 프레임워크를 사용하는 식으로 만들어 재배포 해야 할 것 같네요; (태터 플러그인 Base 를 사용하는 모든 플러그인도 전부 수정해야 할 듯 ㅠㅠ)

일단은 jQuery 을 생각하고 있습니다... (아 jQuery 사용법 배워야 겠네 ㅠㅠ)

암튼 그동안 이것때문에 불편하셨던 분들께 죄송합니다 ㅠㅠ (특히 에디터에서의 문제가 무지하게 불편했다는;) 이것때문에 애꿎은 태터 쪽에 버그 리포팅하신 분도 있을지도;

영양가 있는 포스팅인가요

(아무도 투표를 안 했어요) 0점

IE 에서의 scrollLeft/scrollTop 문제

모르면 이유를 찾기가 까다로운 문제이다.

IE6 이상에서는 웹페이지에 DTD 가 명시되었을때 document 객체의 scrollLeft 와 scrollTop 가 올바른 값을 뱉어내지 않는 버그(?)가 있다.

너무나 어처구니 없고 개연성이 없어보이는 버그이기 때문에 이에 대한 정보를 미리 알지 못했다면 DTD 때문에 해당 문제가 생기는 거라고는 추리하기는 불가능하다-_-;

아무튼 해결 방법은 다음과 같다.
document 객체에서 scrollLeft 와 scrollTop 을 뽑아내지 말고
document.documentElement 객체에서 scrollLeft 와 scrollTop 을 뽑아내자.

뭐 이런식으로 함수 하나 만들어서 사용하면 되겠다.

DTD 지정했을때 윈도우 크기 얻어내기

브라우저 자체의 크기가 아니라 HTML 내용이 표시되는 영역의 크기를 얻어내는 방법이다.
이 방법을 찾기 전에는 임의의 엘리먼트(이를테면 div 태그) 하나를 width:100%; height:100% 로 해서 clientWidth 와 clientHeight 을 얻어낸 다음에 다시 크기를 되돌려 놓는 뻘짓거리로 얻어냈었다-_-

방법은 초 간단.
document.documentElement 의 clientWidth 와 clientHeight 로 얻어낼 수 있다.

끝.

영양가 있는 포스팅인가요

(총 2분이 투표해서 3.0점) 3.0점