25년 만에 수정된 Firefox <textarea> 버그

 (bugzilla.mozilla.org)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Firefox의 오래된 Bug 33654는 <textarea>가 ROWS=와 COLS=를 적용할 때 스크롤바 공간까지 더해 지정한 행·열보다 크게 보이던 문제였고, 현재는 Bug 1830576의 중복으로 닫힘
  • overlay scrollbars가 꺼져 있거나 “always show scrollbars” 설정을 쓰는 환경에서 <textarea rows=N>이 대략 N+1행 높이로 계산되는 현상이 반복됨
  • 초기 논의는 글꼴 상속, monospace 강제 적용, w와 W 평균 폭 기반 cols 계산, 스크롤바 공간 예약 방식까지 확장됐고 테스트케이스·패치·스크린샷이 장기간 쌓임
  • 실제로는 rows=1이 3행처럼 보이거나 rows=2가 3행 높이로 보이고, cols=80에서 IE와 Firefox의 줄바꿈 위치가 달라지는 등 폼 레이아웃 제어가 브라우저별로 어긋남
  • Bug 1830576이 VERIFIED FIXED가 되면서 WebKit, Chromium, Firefox의 스크롤바 간격 적용이 일관됐고, Bug 33654는 RESOLVED DUPLICATE로 정리됨

Bug 33654의 상태와 범위

  • Bug 33654는 <textarea>가 ROWS=와 COLS=를 잘못 적용해, overlay scrollbars가 비활성화된 상태에서 가로·세로 스크롤바용 추가 공간이 생기던 결함임
  • 제품과 컴포넌트는 Core :: Layout: Form Controls이며, HTML 폼 컨트롤의 레이아웃과 외형, 특히 textarea 같은 요소가 범위에 들어감
  • 현재 상태는 RESOLVED DUPLICATE of bug 1830576임
    • 중복 대상인 Bug 1830576의 제목은 Firefox sizes <textarea rows=N> as roughly N+1 rows tall, under an "always show scrollbars" configuration
    • Bug 1830576의 상태는 VERIFIED FIXED
  • 버그는 26년 전에 열렸고, 2년 전에 RESOLVED DUPLICATE로 닫힘
  • 메타데이터에는 버전 Trunk, 플랫폼 x86 / All, 유형 defect, 우선순위 P3, 심각도 S3가 표시됨
  • 키워드는 testcase, Whiteboard는 [html][behavior]relnote-devel, 투표 수는 99로 표시됨
  • 첨부파일은 17 files, 17 obsolete files로 표시되며, 테스트케이스·패치·스크린샷이 반복적으로 올라옴

처음 드러난 증상

  • 최초 보고에서 Andrew McMillan은 ROWS=5 COLS=30으로 지정한 TEXTAREA 예제가 대략 ROWS=7 COLS=48처럼 표시된다고 남김
  • 초기 댓글에서는 INPUT TYPE=TEXT와 TEXTAREA가 지정된 글꼴을 제대로 쓰지 않거나, 스크롤바가 나타나도 영역이 너무 높다는 사례가 이어짐
  • 이후 논의는 textarea 레이아웃이 잘못된 정보를 받고 있으며, 열에는 추가 공간이 있고 행은 하나 더 많다는 쪽으로 모임
  • 스크롤바를 위한 공간을 미리 보존하는 방식이 원인일 가능성도 초기에 다뤄짐

글꼴 계산과 초기 패치

  • HTML authoring newsgroup 사례에서는 textarea { font-size: 8pt }와 <textarea cols="40" rows="12">를 함께 쓰면 IE는 너비를 맞게 렌더링하지만, Mozilla는 12pt 글꼴 기준으로 너비를 계산하는 것처럼 보였음
  • arial 글꼴을 쓰는 테스트 파일에는 <textarea NAME=system_code wrap=soft rows=5 cols=30 WRAP style="font-family:arial">가 포함됨
  • Rod는 기본 글꼴에서는 크기 계산이 맞으므로 sizing 자체보다 textarea가 올바른 글꼴을 사용하지 않는 문제가 핵심이라고 봄
  • Kin은 editor의 PlainText 플래그가 설정되면 TextControl의 콘텐츠 영역에 font-family: monospace;를 강제로 적용하는 코드를 발견함
    • 이 코드를 제거하면 올바른 글꼴이 사용됨
    • 그러나 NavQuirks 모드에서는 30열 textarea 안의 30자 문자열이 너비의 약 2/3만 차지하는 문제가 남음
    • 원인으로 nsFormControlHelper가 글꼴에서 w와 W의 평균 너비를 구해 열 수와 곱하고 scrollbar 너비를 더해 textarea 너비를 계산하는 방식이 지목됨
  • Patch to use the correct font.는 plain text editor 초기화 플래그에 eEditorEnableWrapHackMask를 추가하고, font-family: monospace; 적용을 조건부로 제한함
  • 이 패치는 한때 RESOLVED FIXED로 처리됐지만, 원래 리포터가 COLS=...는 맞아도 ROWS=...는 여전히 잘못 동작한다고 알리면서 다시 열림

반복된 재현과 중복 버그

  • 중복 버그 목록에는 <textarea>가 지정된 행보다 한 줄 더 크게 보이거나 rows=1이 3줄처럼 보이는 문제가 다수 포함됨
    • Bug 46106: Textarea displaying more rows than designated.
    • Bug 116779: <textarea rows=1> shows 3 rows
    • Bug 133342: textarea always rendered with one more row than defined
    • Bug 186271: textareas are 1 row taller than specified
    • Bug 206946: <textarea rows="2"> shows ~3 lines
    • Bug 911226: <TEXTAREA> always rendered one line too tall !
  • Interactive testcase는 rows와 cols 값을 버튼으로 바꿀 수 있는 HTML 4.01 Strict 문서였고, font tag나 variable-width font를 사용하지 않음
    • 동작 결과는 지정한 값보다 항상 3 columns가 더 많고, row는 보통 1개 더 많음
    • rows=1을 요청하면 3 rows가 표시됨
  • 2002년 Linux 및 Win2000 trunk builds에서는 <textarea cols=40 rows=2></textarea>가 3 rows로 표시되고, rows=N이면 정확히 N+1 rows가 표시된다는 사례가 나옴
  • W3C HTML 4.01 테스트도 참고 자료로 쓰였고, ROWS 관련 테스트에서 문제가 명확히 보인다는 댓글이 붙음
  • Windows 2000과 Mozilla 0.9.3에서도 rows=1 textarea가 명백히 1 row로 보이지 않는 예제가 올라옴

스크롤바 공간 계산 논의

  • Comment 86은 textarea 크기가 지정된 cols/rows에 scrollbar 공간을 더한 값으로 계산된다고 설명함
  • IE와 달리 Mozilla는 필요할 때만 scrollbar를 표시하기 때문에 사용자들이 이를 깨진 동작으로 느낀다는 분석이 나옴
  • 가능한 선택지로 세 가지가 제안됨
    • textarea 크기 계산 시 scrollbar 크기를 더하지 않기
    • IE처럼 항상 scrollbar 표시하기
    • 표시할 scrollbar만 포함하기
  • 세 번째 선택지는 크기가 scrollbar 표시 여부에 의존하고, scrollbar 표시 여부가 다시 크기에 의존해 순환적이라는 지적을 받음
  • Comment 87은 ROWS와 COLS가 textarea content 크기만 제어하고, scrollbar가 보이면 textarea가 커지는 방식을 네 번째 선택지로 제안함
  • 이후 구현 방향은 scrollbar 없는 width/height로 reflow해 scrollbar 필요 여부를 결정한 뒤, 필요하면 새 width/height로 다시 reflow하는 방식으로 논의됨

사용자에게 보인 영향

  • rows="2"를 지정했는데 3-row 높이 textarea가 나타나면, 입력량을 시각적으로 안내하려는 의도가 흐려짐
    • 한 웹 애플리케이션은 짧은 요약 텍스트를 요청하며 rows="2"를 사용해 “한 줄보다는 많고 에세이는 아닌” 입력량을 안내함
    • Firefox와 IE6, Opera 8의 동작 차이 때문에 같은 rows 값이 사용자 에이전트마다 다른 시각적 안내를 만듦
  • textarea 내용이 스크롤되지 않는 경우에도 Firefox 동작이 잘못됐다는 댓글이 이어짐
    • 주소 입력처럼 대부분 세 줄을 넘지 않을 textarea에 rows="3"을 지정해도 Firefox는 항상 extra row를 표시함
    • 페이지가 불필요하게 커지고, 사용자가 박스가 예상보다 커서 정보를 충분히 채우지 않았다고 생각할 수 있음
  • cols=80 비교에서는 IE가 80개의 1을 scrollbar 가장자리까지 채운 뒤 줄바꿈하지만, Firefox는 80개의 1 뒤에 2개가 더 들어갈 공간이 있고 이후 horizontal scrollbar가 나타난다는 스크린샷 설명이 붙음
  • 2019년에도 문제가 남아 있다는 댓글이 있었고, Discord의 Chat bar is a line taller than usual on Firefox Trello 카드가 영향 사례로 제시됨

장기간 이어진 패치 시도

  • Hideo Saito는 여러 차례 패치와 테스트케이스를 첨부함
    • patch for rows and cols
    • wrap="off" 패치 테스트케이스
    • base patch
    • additional patch for another bug
    • patch which does not remove space
  • 한 접근은 nsTextControlFrame::Reflow를 스크롤바를 제외한 intrinsic size로 수행한 뒤, scrollbar가 있으면 intrinsic size에 scrollbar 크기를 더해 다시 reflow하는 흐름이었음
  • GetScrollbarStyles를 수정해 text control frame이 scrollbar를 auto, hidden, scroll 중 무엇으로 둘지 제어하는 접근도 다뤄짐
  • roc는 nsGfxScrollFrame에 많은 변경을 넣는 방식보다 nsTextControlFrame에서 처리하는 방안을 선호함
  • 이후 패치들은 SetScrollbarStyles, GetScrollbarStyles, SetScrollbarSpace, GetScrollbarOverflowState, FrameNeedsReflow, post-reflow callback 같은 메커니즘을 두고 리뷰와 재작업을 반복함
  • 일부 패치는 review-를 받거나 obsolete 처리됐고, 리뷰어는 trunk에 맞춘 업데이트가 필요하다고 지적함

임시 회피책과 한계

  • CSS textarea{ overflow-x: hidden }를 추가하면 문제가 해결된다는 제안이 있었음
  • 이 방법은 수평 스크롤바가 필요 없는 경우에만 적용된다는 조건이 붙음
  • 다른 댓글은 이 버그가 CSS overflow만으로 고칠 수 없고, Firefox가 textarea에 한 줄을 더 추가해 렌더링하는 유일한 브라우저라고 반박함
  • Emilio Cobos Álvarez는 원인이 scrollbar 크기 때문으로 보이며 <textarea>에 scrollbar-width: none을 적용하면 해결되는 것으로 보인다고 말함
  • 같은 댓글은 그래도 버그 자체는 수정되어야 한다고 덧붙임

최종 정리

  • 3년 전 BugBot은 이 버그의 severity가 상대적으로 낮은 S3이지만 중복 27개, 투표 103개, CC 91개가 있다며 severity 상향 검토를 요청함
  • 버그 요약은 TEXTAREA incorrectly applying ROWS= and COLS=에서 TEXTAREA incorrectly applying ROWS= and COLS= (horizontal / vertical scrollbar extra space, with overlay scrollbars disabled)로 바뀜
  • Daniel Holbert가 Bug 1830576 Firefox sizes <textarea rows=N> as roughly N+1 rows tall, under an "always show scrollbars" configuration을 의존성으로 추가함
  • Luke Warlow는 Bug 1830576이 수정되었으므로 WebKit, Chromium, Firefox의 스크롤바 간격 적용이 일관되게 되었고 이 버그를 닫을 수 있는지 물음
  • Emilio Cobos Álvarez가 이에 동의했고, Bug 33654는 NEW에서 RESOLVED로 바뀌며 DUPLICATE로 닫힘
  • 중복 대상은 Bug 1830576으로 지정됐고, 해당 버그는 VERIFIED FIXED 상태임

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 하! 그 25년 대부분 동안 이 버그를 구독하고 있었음. 당시에는 Firefox가 없었고, 이건 Netscape Navigator가 아니라 그 전후의 Mozilla 쪽 버그로 등록된 것이었음
    왜 구독했는지는 기억나지 않지만 아마 댓글을 달았던 듯함. 몇 년에 한 번씩 알림 메일이 와서 늘 웃겼는데, 며칠 전 드디어 고쳐졌음

    • 그 버그 스레드 구독 상태가 그 긴 세월 동안 살아남았다는 게 놀라움
    • 나도 비슷함. 웹사이트 제작을 직업으로 해볼까 처음 고민하던 시절, 배경이 바탕화면까지 투명하거나 반투명하게 보이는 웹사이트를 상상하며 매료됐던 기억이 있음
      html { background: transparent; } 같은 걸 쓰면 그냥 동작해야 한다고 늘 생각했음. 다만 이번 버그 수정이 실제로 그걸 해주는 건 아님. 우선 웹사이트가 기본으로 선택하는 기능이 아니라, 사용자나 확장이 켤 수 있는 설정임. 아마 그게 낫고, 기본 허용이면 클릭재킹의 새 길이 열렸을 것임
    • “Netscape Navigator 대상으로 등록됐다”기보다는 Mozilla Suite 쪽임. 2000년이면 이미 Mozilla 시대로 꽤 들어온 때였고, Netscape 버그가 Bugzilla에 들어왔을 것 같지도 않음
    • 와, 이 버그가 Firefox 자체보다 오래됐네
    • 다음은 Jira의 프로젝트 간 버전 티켓이 해결될 차례임

  • 주제와는 좀 벗어나지만 “한 달 전” 같은 사람이 읽기 쉬운 기간 표시 유행이 정말 싫음. 그냥 날짜를 보여주면 내가 알아서 계산할 수 있음
    Outlook, 적어도 Mac 버전이 최악임. 오늘 이전 메일은 예를 들어 그냥 “어제”라고만 나오고, 메일을 클릭해야 시간까지 보여줌. 하루에도 메일을 수십 통 받는데 50개 메시지가 줄줄이 “어제”로만 보이면 아무 쓸모가 없음

    • 사람이 읽기 쉬운 표시 위에 마우스를 올리면 정확한 타임스탬프가 나오는 방식이면 좋음
    • 진심으로 이 유행이 빨리 사라졌으면 함. 메일이 그날 오전 6시에 왔는지 밤 11시에 왔는지는 엄청난 차이가 있음. 그냥 “어제”라고만 하는 건 충분하지 않음
      맥주는 차갑게, 타임스탬프는 정확하게가 좋음
    • 틀리기까지 하면 더 최악임. Discogs는 2021년 10월을 “3년 넘게 전”이라고 우김
    • “그냥 날짜를 보여주면 내가 알아서 계산할 수 있다”는 게 내게는 정말 어려움. 날짜나 시간의 흐름 개념 자체에 꽤 큰 어려움이 있음
    • 날짜 위에 마우스를 올리면 정확한 날짜와 시간이 보임

  • Firefox의 Bugzilla는 확실히 가장 오래 운영 중인 버그 추적기 중 하나임. 수많은 개정을 거쳤는데도 원래 느낌이 꽤 남아 있는 게 인상적임. 예전에는 꽤 거칠고 괴물 같은 코드베이스였음
    2000년쯤 Windows 개발 조직에서 Microsoft Access/Outlook 기반의 자체 버그 추적기를 대체하려고 인스턴스를 세운 적이 있음. 복잡했지만 한동안은 거의 최고 수준의 버그 추적기였음. FogBugz도 그 무렵 막 시작하던 때였고, 그 팀은 사용자 경험을 진지하게 고려한 초기 팀 중 하나였다고 봄

    • 지금도 Bugzilla를 이기기 쉽지 않음. 사실 요즘 선택지 중 일부는 Bugzilla보다 너무 나빠서 어떻게 존재하는지 이해가 안 될 정도임. 예를 들어 Dwarf Fortress가 쓰는 Mantis BT는 정말 형편없음
      반대로 FogBugz는 기회가 되면 늘 한번 써보고 싶었던 도구임

  • 이런 걸 보면 마음이 따뜻해짐. 최근 나도 24년 된 Firefox 버그에서 비슷한 일을 겪었음: https://bugzilla.mozilla.org/show_bug.cgi?id=62151

    • 젠장, 이거 때문에 막혀서 헤맸던 기억이 남

  • 장기 미해결 버그 중 가장 거슬리는 건 LibreOffice에서 산점도의 x축을 제대로 날짜 형식으로 지정할 수 없다는 점임
    https://bugs.documentfoundation.org/show_bug.cgi?id=54132
    12년 된 버그임. 댓글을 보면 코드가 너무 “끔찍하게 복잡”해서 고치면 회귀가 날 가능성이 크다며 수정을 꺼리는 분위기임

    • LibreOffice가 Excel에서 내가 좋아하는 기능들을 가져와주길 바랐는데, 이걸 보니 기대가 줄어듦
    • 스프레드시트와 그래프 작성 패키지만 필요하다면 Linux에서는 gnumeric이 좋은 선택임
    • 유지보수자가 자신들이 병합을 허용한 코드를 무서워하게 될 때가 참 좋음

  • 다음에는 XDG를 해줬으면 함. 이것도 20년째 기다리는 중임 [1]
    [1] https://bugzilla.mozilla.org/show_bug.cgi?id=259356

    • XDG 기본 디렉터리가 완전하고 보편적으로 채택될 일은 없을 것 같음. 이미 21년이 지났음. Arch Linux가 이를 따르지 않는 프로그램에 공격적으로 굴지 않았다면, 예컨대 루트 사용자 디렉터리 권한을 잠그는 식이 아니었다면, 최근만큼 커지지도 않았을 것임
      솔직히 이 사양은 사람들이 겪는 실제 문제를 적극적으로 해결하지 않음. 채택 대부분은 $HOME 디렉터리 구성이 거슬린 사람들이 유지보수자를 성가시게 압박한 결과이고, 사용자의 99%는 프로그램이 XDG 기본 디렉터리를 따르든 말든 신경 쓰지 않음. 20년 넘게 널리 채택되지 못한 freedesktop 사양에 따라 그저 “더 깔끔하다”고 주장할 수 있게 만드는 정도임
      개인적으로는 그 느슨한 설정/데이터/캐시 분리와 암묵적 의도를 좋아하지 않음. 모든 것이 그 범주에 들어맞는 것도 아니고, 그러면 시스템 동작을 예측하기 어려워짐. 데몬이 내 캐시를 지울까? 사용자가 설정 폴더를 복사해 다닐까? 정확히 무엇이 백업될까? 사양에는 폴더가 실제로 어떻게 취급돼야 하는지 표준이 없음. 의도적으로 모호하지만, 사람들이 가정하면 깨질 수 있는 방식으로 모호함
      루트에서 /usr를 나누거나, 루트에서 /usr/local을 나누거나, /opt를 두는 것과 비슷함. 지나간 시대의 잔재가 계속 남아 있고, 또 하나를 만들려는 느낌임
      우리 제품에서도 마지못해 지원하지만, 해당 환경 변수가 명시적으로 설정된 경우에만 지원함. 설정되지 않았을 때 모든 Linux 시스템에서 기본값이 이래야 한다는 XDG의 동작은 100% 무시함. MacOS 같은 다른 UNIX 계열이 기대하는 방식과 다르기 때문임. Arch Linux 열성 사용자들이 매주 버그 추적기에 몰려와 채택하라고 요구하는 걸 막을 정도만 넣었고, 그들은 전체 사용자의 1%도 안 됨. 사용자들이 자기 시스템에서 우리 제품 파일을 어디서 찾는지 문서로 안내하는 것만으로도 충분히 어려움. 사용자들이 항상 XDG를 아는 것도 아니고, 대부분에게 XDG는 이미 기대하는 확립된 관례도 아님. 깨끗한 사용자 디렉터리를 원하는 사람들 말고는 강력한 가치가 없는데, 모두를 이 사양으로 옮기기엔 유산이 너무 많음
      솔직히 전부 다시 생각해서 데스크톱 앱이 작은 감옥을 벗어나지 못하는 컨테이너 기반 해법으로 가야 함. snap 앱과 거의 비슷하게 말임. Nix에서 조금 배울 수도 있음. 전 세계 모든 Linux 사용자 앱이 XDG 기본 디렉터리, 심지어 사용자 디렉터리까지 신경 쓰고 채택하게 만드는 건 실패라고 인정해야 함. Mac과 Windows 포트까지 지원하는 것만으로도 충분히 힘든데, 이들은 이런 동작을 따르지 않음. 사용자 권한으로 프로그램을 실행하는 UNIX 권한 모델에서 벗어나 각 프로그램을 자체 uid로 실행해야 함. Android가 그렇게 동작함
    • 맞음, 나도 그걸 기대 중임

  • 복사할 텍스트가 있는데도 복사 옵션이 무작위로 비활성화되는 버그가 제발 고쳐졌으면 함. 정말 미칠 지경임

    • 나만 겪는 게 아니라니 다행임
    • 25년 안에는 고쳐지는지 봐야겠음. 요즘처럼 빠른 웹 환경 기준으로 Mozilla는 가끔 너무 느림

  • AWS는 오래된 버그와 그에 대한 모든 언급을 주기적으로 지워서 이 문제를 해결함

    • 버그를 피하는 타조 전략임

  • 지난 8월 관련 글:
    Happy 25th Birthday to Bugzilla
    https://news.ycombinator.com/item?id=37279543

  • 멋지다! 다만 2000-03-28은 아직 25년 전이 아님

    • 듣고 보니 꽤 이상한 반올림 방식임
    • 맞음. 솔직히 나라면 몇 달 더 기다렸다가 은혼식 기념일에 맞춰 고쳤을 듯함 :P
답변달기