Mozilla 한국 커뮤니티

빛알갱이님이 지적한 대로, 1.0.1로 착각하였던 나이틀리 버전에서 발견된 문제입니다.

ㅁ 주소란에 북마크 끌어놓기시, 오류발생

http://softwant.com/cgi-bin/kimsboard/m ... ror001.jpg

주소입력란에 주소를 북마크바에 마우스끌기를 할 경우, 파이어폭스가 종료됩니다.
위 화면에서 보듯이 알 수 있을 것입니다.

ㅁ 영문버전에서 한글이 포함된 링크 한글깨짐 현상, 따라서 링크 오류발생

http://softwant.com/cgi-bin/kimsboard/m ... ror002.jpg
http://softwant.com/cgi-bin/kimsboard/m ... ror003.jpg

두 이미지에서 보듯이 인코드를 한국어로 하였어도 동일한 현상이 나타나고 있습니다.

ㅁ 고급메뉴에 있는 언어 추가되지 않음

http://www.softwant.com/cgi-bin/kimsboa ... 01-009.jpg

이 문제는 현재 정상적으로 작동하는군요. 문제를 지적하였을 때는 정상적으로 언어추가가 되지않았습니다. 안정성에 문제가 있다고 해야할까요?

ㅁ Sanitize 이용시
ㅁ Sanitize 이용시 Sanitize 대화창이 자동종료되지않음. 취소버튼을 눌러주어야함.

http://www.softwant.com/cgi-bin/kimsboa ... ror004.jpg

원래 구조가 그런 것인 지, Sanitize Now를 클릭하였을 경우, Sanitize가 OK로 바뀌거나 종료할 수 있어야 할 것입니다. 버그라고는 생각지않지만, 처리절차상에 수정되어야하지 않을까 합니다.

지금은 문제가 없지만, 하단 옵션중 Ask me before...가 환경설정에서 체크할 수 있는 상태가 아닌 [비활성상태]로 되어있다는 것입니다.

http://www.softwant.com/cgi-bin/kimsboa ... 01-003.jpg

Sanitize라는 명칭은 한글버전에서 어떤 식으로 처리했는 지 모르지만, 현재 1.0 버전의 Clear All을 유지하는 게 좋을 것이라 봅니다. 현재 명칭으로도 문제가 없는 것을 새로운 단어를 적용하려함으로써 사용자 혼란을 줄 필요는 없겠죠.

자세한 버그 보고에 감사 드립니다. 하지만, 링크 문제는 그림보다는 말로 어느 웹 페이지(URL을 주시고)에 가서 어떤 링크를 눌렀을 때 '깨져' 보인다고 햇으면 더 좋았을 뻔 했습니다.


1. go to http://www.example.com/xyz/abc.html
2. hover the mouse over 'blah blah' link
3. see what's in the status bar
4. click on the link
5. .....


그렇지 않으셨기 때문에 제가 일일이 어떤 상황인지 가정하고, 비슷한 상황을 재현해 보아야 합니다.

아래 링크에서 확인할 수 있습니다.

http://www.softwant.com/cgi-bin/kimsboa ... nc=mozilla

그리고 1.0과 1.0.1의 Keyword guessing에 문제가 있내요.

이것은 다시 올리겠습니다.

빛알갱이 wrote:자세한 버그 보고에 감사 드립니다. 하지만, 링크 문제는 그림보다는 말로 어느 웹 페이지(URL을 주시고)에 가서 어떤 링크를 눌렀을 때 '깨져' 보인다고 햇으면 더 좋았을 뻔 했습니다.

그 문제는 softwant님 사이트의 모질라 사용법 페이지에서 시험해 보았습니다. 문제는 network.standard-url.encode-utf8이 trunk에서는 기본적으로 on이라는데에 있습니다.

이것은 제가 '주장해서' on으로 한 것인데, MS IE의 'always send URLs in UTF-8'에 대응하는 옵션입니다. 그렇게 하자고 한 이유는 IRI가 표준이므로, 표준을 따르자는 뜻이 있었습니다. 그와 더불어 MS IE의 대응하는 옵션이 항상 ON이라도 (그 옵션이 처음 생긴 3-4년 전과 달리) 한국 사용자들이 불편을 겪지 않는 것으로 보아서 켜도 문제가 없으리라고 판단했기 때문입니다. 일단 UTF-8로 보내진 IRI를 제대로 해석하지 못 하는 것은 softwant.com에서 쓰는 서버측 프로그램의 버그입니다. 이 버그는 조만간 고쳐 주실 것을 부탁 드립니다.

제가 든 두번째 이유를 다시 말하면, 한국의 대부분의 사이트가 MS IE의 'always send URLs in UTF-8'에 대응하여 IRI를 제대로 처리하도록 고쳐졌을 것이라고 생각했습니다. 물론, 당연히 예외는 있으리라고 예상했습니다.

문제는 MS IE의 경우 이 옵션이 켜져 있어도 제대로 동작한다는 사실입니다. 그렇다면, 한국 웹 서버측 프로그램이 MS IE에 적응한 것이 아니라 MS IE가 한국 웹 서버측 버그에 대응했다는 얘기가 됩니다. 즉, 일단 IRI(UTF-8을 %-encode한 것 혹은 그냥 raw UTF-8)로 한번 시도해 보고, 안 되면 다시 URL을 참조하는 문서의 인코딩으로 시도하나 봅니다. (이 부분은 시험을 통해 확인해 보아야 합니다.)


제가 저 옵션을 기본으로 켜자고 강력히 주장했고, 제 말을 믿고 다른 개발자들이 켠 것인데, MS IE한테 뒤통수를 맞은 셈이네요. 더 확실하게 알아 보았어야 했는데... 그렇다고 해도 IRI를 쓰는 것이 표준에 맞는 일이므로, 다시 끄자고 할 생각은 없습니다. MS IE처럼 fallback을 시도할 것인지는 생각해 보아야겠습니다.

좀더 자세히 알아 보니 그게 아니었군요. MS IE가 참으로 신기하게 동작하네요.

URI에서 path에 해당하는 부분은 IRI 방식대로 UTF-8로 바꾼 후에 %-encode합니다. 그런데, query에 해당하는 부분은 IRI를 따르지 않고, 종전 방식대로 링크를 건 문서의 문자 인코딩에 대해 %-encode합니다. 예를 들어,
가 있다면 MS IE가 써버에 보내는 URL은 다음과 같습니다.
http://www.example.com/%EA%B0%80%EB%82%98.pl?
field=%B0%A1%B3%AA

같은 '가나'이지만, path 부분에서는 '%EA%B0%80%EB%82%98'이지만, query 부분에서는 '%B0%A1%B3%AA'입니다.

이것은 상당히 심각한 문제로군요. post를 쓸 때에는 문제가 안 되지만, get을 쓸 경우에 두 브라우저를 모두 다 지원하려면 서버측 프로그램이 할 일이 많아집니다.

물론, 써버측 프로그램이 동적으로 생성하는 html도 UTF-8이고, 처리도 내부적으로 Unicode를 써서 한다면 아무런 문제가 없습니다. 하루 속히 UTF-8로 넘어 가야 할 또다른 이유로군요.