티스토리 뷰


1) 문제의 발견.

어제 브라우저에서 새창 링크를 사용할 때 새창에서 링크가 동작하지 않는 에러가 발생하는 것을 확인했다. 집에서 확인한거라서 기술적으로 왜 안되는지 정도만 분석을 했고 오늘 출근하고 나서 본격적인 확인에 들어갔다. 

 

집에서 확인했을 때는 <a> 태그에서 target=_blank 속성을 이용했을 때 문제가 발견하는 것으로 확인이 됐다. 크롬 개발자도구에서 _blank를 삭제하니 제대로 동작이 되었고 href="javascript:moveFunc;" 와 같은 식으로 링크가 이동하도록 자바스크립트 함수가 걸려있는 페이지였다. 

 

동적인 url 생성이 필요한 페이지라 자바스크립트로 이동 함수를 걸어두었던 것이다. 


2) 링크 동작 에러의 원인 분석

이 방식이 화근이 되었다. 최근에 비슷하게 크롬 업데이트 이후 동작에 이슈가 있어서 문제의 원인을 바로 크롬 업데이트부터 체크해봤다. 혹시나가 역시나였다. 바로 구글에서 해당 이슈가 검색 되었다. 검색은 'chrome target _blank 76' 정도로 검색했더니 두번째 글에서 해당 이슈가 검색 되었다. 

 

https://support.google.com/chrome/thread/11481572?hl=en

 

I have a problem with href:"javascript: ... " in Chrome 76.0.3809.100. - Google Chrome Help

 

support.google.com

해당 쓰레드에서 댓글로 해당 버그에 대한 크로미엄 레포트를 찾을 수 있었고, 

 

Reported as a bug here: https://bugs.chromium.org/p/chromium/issues/detail?id=992244

 

Issue 992244 - chromium - An open-source project to help move the web forward. - Monorail

 

bugs.chromium.org

곧 원인을 알수 있었다. 원래부터 새창( new window)에서 이전의 자바스크립트를 불러올수가 없는 게 스펙이라는 거다. 기존이 되었던 방식이 잘못된 동작 방식이고 76 버전에서 고쳐졌다는 것이 더 맞는 표현이었던 거다. 하지만 잘못된 스크립트로 동작하고 있었던 레거시 사이트들은 모두 영향을 받게 되었지만... ( ㅠㅠ ) 

javascript 링크를 사용하여 _blank 새창을 열면 이렇게 에러가 발생한다.

이미 예전에 파폭에서 관련 이슈가 있었지만 사이트가 수정되도록 가이드를 받은 사실이 있었다. 뭐 이 방식 자체가 표준적인 방식이 아니라는 것 정도만 이해하고 넘어가도 될것 같다. 내가 알기로도 이런 방식은 좀 의문이 들었으니까. 

https://bugzilla.mozilla.org/show_bug.cgi?id=1404858

 

1404858 - Site depends on broken webkit/blink mis-handling of target on javascript: links

NEW (nobody) in Web Compatibility - Desktop. Last updated 2019-04-29.

bugzilla.mozilla.org


3) 링크 동작 에러 해결 방법

우선은 target=_blank 를 쓰면서 href="func()" 와 같이 스크립트 함수를 사용하는 곳은 모두 수정대상이 되었다. 수정은 window.open 방식으로 바꿔주면 끝이다. 물론 상황에 따라서 _blank를 없애주어 새창이 아닌 창으로 이동해도 될듯 하다. 

 

문제의 링크 : https://bugs.chromium.org/p/chromium/issues/detail?id=992244

https://bugs.chromium.org/p/chromium/issues/detail?id=992244

뭐 몇군데 되지 않고 수정방법이 워낙 간단하여 한시간도 채 걸리지 않아 모두 수정했지만 그동안 문제가 되었던 기간을 생각해보면 간단한 문제라고는 할수 없는 일이다. ( 광고비와 기회비용, 브랜드 이미지 등등.... ㅠㅠ )


4) 처리 후 잡설...

내부적으로 테스트 자동화나 사이트 모니터링을 할수 있는 체계가 너무나 부족하다는 것도 다시금 체감하게 되었다. 홈페이지든 모바일 페이지든 동작에 대한 테스트 시나리오를 자동화하여 24시간을 항시 체크할수 있도록 구축해놓아야 지금과 같은 문제를(즉, 원인을 대비할수 없는 문제들을 ) 방비할수 있으리라...

 

아니면 크로미엄과 같은 대단위 큰 프로젝트, 그리고 업데이트 마다 사용자들에게 큰 리스크를 줄수 있는 패치에 대해서 메일링 될수 있도록 체계가 잡혀있었으면 한다. ( 벌써 두번째라고 76 이슈만... ㅠㅠ )


댓글과 좋아요는 쓰니에게 큰 힘이 됩니다. 


댓글
최근에 올라온 글
최근에 달린 댓글