SlickGridの列幅変更が動かない問題を、AIと原因切り分けで解決した記録

はじめに

SlickGridを使った画面で、列幅のドラッグ変更が急に効かなくなりました。
コンソールにはスタックトレースが出ていたので、最初はそれをそのままAIに渡して調べましたが、原因には届きませんでした。

今回は、そのときに実際にやった調査と修正の流れをまとめます。

発生した問題

背景

タブUIの中にSlickGridを置いた構成で、列境界をドラッグしても幅が変わらない状態になっていました。

エラー内容

開発者ツールには次のエラーが出ていました。

jquery.js:9779 Uncaught TypeError: elem.getClientRects is not a function
at jQuery.fn.init.offset (jquery.js:9779:14)
at Object.locate (jquery.event.drop-2.3.0.js:165:16)
at HTMLDocument.<anonymous> (jquery.event.drag-2.3.0.js:370:39)
at jQuery.each (jquery.js:359:19)
at callback.update (jquery.event.drag-2.3.0.js:369:23)
at Object.hijack (jquery.event.drag-2.3.0.js:299:34)
at HTMLDocument.handler (jquery.event.drag-2.3.0.js:188:30)
at HTMLDocument.dispatch (jquery.js:5087:27)
at $event.dispatch (jquery.event.drag-2.3.0.js:382:30)
at elemData.handle (jquery.js:4895:28)

見た目はjQuery周辺の問題ですが、これだけでは判断できませんでした。

まず詰まった点

最初はスタックトレースだけをAIに投げました。
返ってきた内容は方向性としては間違っていないものの、実際の不具合には刺さらず、調査が進みませんでした。

フロントエンドの不具合は、実行中のDOMやイベントの流れを見ないと決め手が出ないことが多いと改めて感じました。

実践的なデバッグプロセス

ステップ1: ブレークポイントで実態を把握する

elem.getClientRects is not a function の箇所で止めて elem を見ると、DOM要素ではなく document が入っていました。
本来の想定と違う値が渡っていたため、そこでエラーになっていました。

ステップ2: AIに具体的な情報を提供して原因を探る

次は、次の情報を添えてAIに再度相談しました。

• エラー箇所で elem に document が渡されている
• SlickGridがタブUI上に配置されている
• ドラッグ&ドロップ関連のイベント処理でエラーが発生している

この時点で、タブ側のドラッグイベントと列幅変更イベントの競合という仮説にたどり着けました。

ステップ3: イベント競合を解決する

調査して確認できたのは次の2点です。

1. タブのドラッグイベントがグリッド側の処理に干渉していた
2. $.fn.offset に document が渡る経路があり、そこで例外が起きていた

対応として、以下を入れました。

// タブのdragstartイベントを無効化
$tab.on('dragstart', function(e) {
  e.preventDefault();
});

// $.fn.offsetにdocumentが渡された場合の対処
// 元のoffset関数をラップして安全にする
var originalOffset = $.fn.offset;
$.fn.offset = function() {
  if (this[0] === document) {
    return {top: 0, left: 0};
  }
  return originalOffset.apply(this, arguments);
};

これで列幅変更自体は動くようになりました。

ステップ4: 新たな問題の発見と最終的な解決

ただし次に、グループヘッダの幅が追従せずレイアウトが崩れる問題が出ました。

以前の案件で同じ要件を扱ったときはX-SlickGridを使っていたことを思い出し、今回も標準SlickGridから移行しました。
結果として、グループヘッダまで含めて意図どおりに追従するようになりました。

学びと教訓

1. スタックトレースだけでは足りない

次の情報を先に取っておくと、AIの回答精度がかなり上がりました。

• ブレークポイントで変数の中身を確認する
• DOM構造やイベントの流れを把握する
• 正常動作時との差分を特定する

2. フロントエンドデバッグの情報収集ポイント

相談前に最低限チェックしたい項目は以下です。

• 変数の実際の値: 期待値との差
• DOM構造: 要素の配置と関係
• イベント伝播: 発火元と伝わり方
• 正常時との差分: 動く画面との違い

3. 将来の展望

ブラウザ操作を含む検証がさらに自動化されれば、この手の調査はもっと短時間で済むはずです。
ただ現状では、人間が観察した事実をAIに渡しながら進める形が一番安定していました。

まとめ

今回うまくいった流れは次のとおりです。

1. エラーの発生状況を観察する
2. ブレークポイントで実行時の状態を詳細に確認する
3. 収集した具体的な情報をAIに提供する
4. AIの提案を元に修正を実施する
5. 新たな問題が発生したら、過去の経験も活用する

スタックトレースだけで進めるより、観察した事実を添えてAIに渡すほうが、原因の特定まで早く進められました。