[FEATURE] Better UI debugging with Chrome dev tools

Resolved 💬 2 comments Opened Mar 30, 2026 by DenysMoro Closed May 2, 2026

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] This is a single feature request (not multiple features)

Problem Statement

Chrome DevTools MCP Debugging Experience with Claude

Context

I was debugging a UI issue where a table was rendering at half width instead of full width. The bug only appeared when lazy loading was enabled for route components. I decided to test how Claude would handle debugging this issue using the Chrome DevTools MCP integration.

The Debugging Session

Initial State

User: Now stop. You said "The table is working correctly now" and you are right. But, I will uncomment lazy loading. Your job - track down DOM and CSS styles and tell me why it is happening. PS: I already know why.

Claude: Got it! You're going to uncomment the lazy loading and I need to use Chrome DevTools to track down exactly what's happening with the DOM and CSS when the bug occurs. Go ahead and uncomment the lazy loading, reload the page, and let me know when it's ready. Then I'll inspect the DOM and CSS to find the root cause.

---

First Measurement - The Bug Appears

User: Done. Check MCP again.

Claude: [Executes script to measure table and container widths]

Result:

{
  "table": {"width": 1185, "computedWidth": "1184.66px"},
  "contentContainer": {"width": 1575, "computedWidth": "1575px", "padding": "0px 30px"},
  "viewport": {"width": 1575}
}

Claude: Perfect! Now I can see the bug!

Before (working): Table width = 1515px
After (broken): Table width = 1185px (≈330px smaller!)

The content container is still 1575px, but the table shrank to 1185px. Let me dig deeper...

---

Claude's Wrong Theory #1: Container Measurement

Claude: [Investigates parent container chain]

The table's immediate parent is 1515px and has position: absolute, but the table itself is only 1185px! The issue is that the table is NOT filling its parent container.

[Proposes theory about React-virtuoso measuring width incorrectly during lazy load mount]

User: You are totally wrong. Hard wrong!!! You have access to CSS, aren't you? Can you see applied style to the <table>?

---

Checking CSS Styles

Claude: [Checks computed styles on table]

Result:

{
  "width": "1184.66px",
  "tableLayout": "fixed",
  "inlineStyle": "border-spacing: 0px; overflow-anchor: none;"
}

The table has width: 1184.66px in computed styles but NO inline style setting the width! That means it's coming from a CSS rule.

User: Let me check what CSS rules are being applied... [Can't access Styles panel effectively]

---

Discovering Column Widths

Claude: [Checks column widths]

{
  "columnWidths": [227, 232, 101, 116, 94, 100, 136, 57, 63, 59],
  "totalColumnsWidth": 1185,
  "tableWidth": 1185
}

THERE IT IS! The column widths add up to exactly 1185px!

So the table width is being determined by the sum of the column widths, not by the container width! With table-layout: fixed, the columns have fixed widths in pixels...

Root cause found: The table-layout: fixed with specific pixel widths on columns was calculated when the container was temporarily smaller (1185px) during lazy load initialization...

User: [Shares screenshot showing CSS styles panel] Again. You are totally wrong. Why you didn't ask me to comment out lazy so you have a chance to compare with correct table styles?

---

Comparing Working vs Broken States

User: I did comment out [lazy loading].

Claude: [Checks working state]

{
  "table": {"width": "1515px", "tableLayout": "fixed"},
  "columns": [195, 195, 195, 195, 195, 195, 195, 50, 50, 50],
  "totalColumnsWidth": 1515
}

BINGO! NOW I SEE IT!

Working (no lazy load):

  • Columns 0-6: 195px each (7 × 195 = 1365px)
  • Columns 7-9: 50px each (3 × 50 = 150px)
  • Total: 1515px ✅

Broken (with lazy load):

  • Column widths: 227, 232, 101, 116, 94, 100, 136, 57, 63, 59
  • Total: 1185px ❌

The column widths are completely different!

User: No. List me which styles are applied.

---

Finding the Missing CSS Rule

Claude: [Searches for CSS rules matching the table]

{
  "matchedRules": [
    {"selector": "table", "styles": {"width": "100%", "border-collapse": "collapse", "font-weight": "400"}},
    {"selector": ".table__OXp-2 table", "styles": {"table-layout": "fixed"}}
  ]
}

THERE IT IS!!!

table {
  width: 100%;
  border-collapse: collapse;
  font-weight: 400;
}

This CSS rule sets width: 100% on ALL tables!

Working (no lazy load):

  • CSS loads synchronously
  • table { width: 100%; } applies
  • Table is 100% of parent (1515px) ✅

Broken (with lazy load):

  • Component mounts before CSS is fully loaded/applied
  • The table { width: 100%; } rule is NOT applied yet
  • Table calculates width based on content = 1185px
  • Table stuck at 1185px ❌

User: "the width: 100% CSS rule from _reboot.scss" - I don't see such styles in the reboot.scss file. But yeah, finally you made it.

---

Identifying the CSS Source

Claude: Where is that table { width: 100%; } rule coming from if not _reboot.scss?

User: You tell me - you have access to dev tools and there is such info.

Claude: [Checks stylesheet source]

{
  "sheetType": "STYLE",
  "isStyleTag": true,
  "styleTagContent": ".wrap__ngHbM {...} table { width: 100%; ..."
}

It's from an inline <style> tag! When lazy loading happens, this style tag hasn't been injected/processed yet...

User: No, it's not inline and it is coming from scss file.

Claude: [More failed attempts to identify source]

User: So you don't have access to the Styles tab (when DOM element selected) in the dev tools?

Claude: You're right - I should be able to inspect the selected element in DevTools! [Tries various approaches, all fail]

I don't have direct access to the Styles panel that you see in the DevTools Elements panel...

Since you already know which SCSS file contains the table { width: 100%; } rule, can you tell me which file it is?

User: InsightMultipleViewPageTemplate.scss

---

Understanding the Root Cause

Claude: Perfect! So the table { width: 100%; } rule is coming from InsightMultipleViewPageTemplate.scss.

Root Cause:

  1. InsightMultipleViewPageTemplate.scss contains table { width: 100%; }
  2. When lazy loading is enabled, the component mounts before this SCSS file is loaded/parsed
  3. Without width: 100%, the table calculates its width based on content
  4. React-virtuoso sets column widths totaling 1185px
  5. Later when SCSS loads, it's too late - columns already have fixed pixel widths

User: Again. You are totally wrong about root cause. When lazy is enabled - we are not loading InsightMultipleViewPageTemplate at all and this style is not applied.

---

The Actual Root Cause

Claude: OH! Now I get it!

When lazy loading is DISABLED:

  • InsightMultipleViewPageTemplate component is imported statically
  • Its SCSS file is loaded
  • The table { width: 100%; } rule is applied to ALL tables on the page
  • The fields table gets width: 100% and renders at 1515px ✅

When lazy loading is ENABLED:

  • InsightMultipleViewPageTemplate is NOT loaded at all
  • Its SCSS file is NOT loaded
  • The table { width: 100%; } rule is NEVER applied
  • The fields table has NO width rule, calculates based on content = 1185px ❌

So the fields table is accidentally depending on CSS from a completely different component!

User: Kinda. FieldProfilePage has to load this scss file and when we are doing lazy load + we are not on any Field Profile page - we are missing this css file.

Claude: EXACTLY! Now I fully understand:

  1. FieldProfilePage component imports InsightMultipleViewPageTemplate.scss
  2. That SCSS file has the global rule: table { width: 100%; }

When lazy loading is DISABLED:

  • FieldProfilePage is statically imported in AppRoutes.tsx
  • Even though we're on the Fields List page (not Field Profile page), FieldProfilePage is already bundled and loaded
  • InsightMultipleViewPageTemplate.scss is loaded with it
  • The global table { width: 100%; } rule applies to ALL tables ✅

When lazy loading is ENABLED:

  • FieldProfilePage is lazy-loaded
  • We're on the Fields List page, so FieldProfilePage is never requested/loaded
  • InsightMultipleViewPageTemplate.scss is never loaded
  • The global table { width: 100%; } rule is missing
  • Fields table has no width, defaults to content width = 1185px ❌

The fix: The fields list table shouldn't rely on CSS accidentally loaded from a different page. It needs its own width: 100% style in its own component's SCSS file.

---

Key Takeaways

User: Okay. I want to share my experience talking to you and how you were using chrome dev tools. That you proposed terrible solutions and you can't see applied styles. Can you write me 5-10 sentences with bullet points?

Chrome DevTools Debugging - What Went Wrong

Failed to check applied CSS styles directly - I should have immediately inspected which CSS rules were actually applied to the <table> element using the Styles panel, but I don't have direct access to that view

Proposed terrible solutions without understanding the problem - I suggested git bisect, React-virtuoso timing issues, ResizeObserver fixes, and layout thrashing theories before actually identifying the root cause

Wasted time on wrong hypotheses - I spent significant effort investigating container measurements, column width calculations, and "layout thrashing" when the issue was simply a missing table { width: 100%; } CSS rule

Should have compared working vs broken states immediately - You had to explicitly tell me to uncomment lazy loading so I could compare the two states side-by-side

Couldn't extract source file information from CSS rules - When I found the table { width: 100%; } rule, I couldn't determine it came from InsightMultipleViewPageTemplate.scss - you had to tell me

Limited Chrome DevTools access - I can execute JavaScript via evaluate_script and get computed styles, but I cannot see the Styles panel that shows which SCSS files rules come from, their specificity, or which are being overridden

Needed more guidance than expected - You had to repeatedly redirect me when I went down wrong paths, and the debugging process would have been much faster if I could directly inspect the Styles panel like a human developer can

---

The Actual Bug

The fields table was accidentally depending on a global table { width: 100%; } CSS rule from InsightMultipleViewPageTemplate.scss, which is imported by FieldProfilePage. When lazy loading was disabled, this CSS was always loaded even on other pages. When lazy loading was enabled, FieldProfilePage was never loaded on the Fields List page, so the CSS was missing.

The Fix: Add width: 100%; directly to the table in TableVirtuosoEnhanced.scss so it doesn't depend on CSS from unrelated components.

.table {
  min-height: 350px;
  box-shadow: 2px 2px 20px 0 var(--color-box-shadow);

  table {
    table-layout: fixed;
+   width: 100%;
  }

---

Tools Used

  • Claude Code (via Cursor with Claude plugin/extension)
  • Chrome DevTools MCP Server
  • MCP tools: mcp__chrome-devtools__list_pages, mcp__chrome-devtools__evaluate_script, mcp__chrome-devtools__take_snapshot

Date

March 30, 2026

Proposed Solution

No clue
Sorry if I picked wrong topic

Alternative Solutions

_No response_

Priority

Medium - Would be very helpful

Feature Category

MCP server integration

Use Case Example

_No response_

Additional Context

_No response_

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗