rust_browser/investigations/google/report.md

Investigation: Google Homepage

URL: https://www.google.com Last investigated: 2026-03-02

Summary

Google's classic homepage renders quite well. The page structure is recognized: top navigation bar with service links (Search, Images, Maps, etc.) on the left and user links (Web History, Settings, Sign in) on the right; centered Google logo image; search input with "Google Search" and "I'm Feeling Lucky" buttons; footer with Advertising/Business Solutions/About Google links and a copyright line. Float layout for the nav bar, <center> centering, and table-based form layout all function. The main issues are around table column percentage widths, default form control styling, and the <nobr> element's height constraint.

Findings

F-001: Table percentage column widths not respected in auto-width tables

• Status: Open
• Found: 2026-03-02
• Category: Layout
• Severity: Medium
• Description: The search form uses a <table> with three <td> elements. The first and third columns have width="25%". In an 800px viewport, these should be roughly 141px each (25% of the table's resolved width). Instead, column 1 is only ~19px wide (just fits  ) and column 3 is ~49px (just fits "Advanced search"). The auto table layout algorithm appears to ignore percentage width hints on cells, sizing them purely by content. This makes the table narrower than expected (~567px instead of ~800px) and shifts the search box slightly left of center.
• Evidence: Layout tree shows td node #75 (col 1) with content width=18.59, td node #77 (col 2) with width=500, td node #95 (col 3) with width=48.87. HTML specifies width="25%" on columns 1 and 3.

F-002: Default input border renders as thick solid black instead of inset

• Status: Open
• Found: 2026-03-02
• Category: Display
• Severity: Low
• Description: The search input <input class="lst"> renders with a 2px solid #1f1f1f (near-black) border on all sides. Real browsers render default input borders with an inset style using lighter grays (typically #767676 or system colors), giving a 3D recessed appearance. The current rendering produces an overly heavy, flat black border around the search box.
• Evidence: Display list shows Border rect=(134.86, 262.44, 514, 34) widths=(2 2 2 2) colors=(#1f1f1f #1f1f1f #1f1f1f #1f1f1f). The input has no explicit border CSS; this is the UA default.

F-003: #gbar height not constraining its layout box

• Status: Open
• Found: 2026-03-02
• Category: Layout
• Severity: Low
• Description: The #gbar div has CSS height:22px and float:left. The layout shows its content height as 22px, but visually the nav bar text and the separator line (div.gbh at y=24) extend slightly below. The height:22px should clip or contain the content, but the absolute-positioned .gbh divs (with position:absolute;top:24px) aren't being positioned relative to #gbar because #gbar isn't a positioned ancestor. This is actually correct behavior per spec, but the visual result differs from Chrome because Chrome's user-agent styles apply additional containment. Minor visual impact.
• Evidence: Layout tree shows #gbar (node #21) content height=22, but the div.gbh elements (nodes #64, #65) are positioned at y=25 as normal flow elements rather than absolute position relative to the containing block.

F-004: position: absolute not applied to .gbh divs

• Status: Open
• Found: 2026-03-02
• Category: CSS Support
• Severity: Medium
• Description: The .gbh class has position:absolute;top:24px;width:100% but the two .gbh divs (horizontal separator lines at top of page) are laid out as normal flow block elements at y=25 rather than being absolutely positioned. They also have left:0 and right:0 inline styles respectively. The position:absolute is either not being parsed or not applied. These divs should be taken out of normal flow and positioned at top=24px within their containing block.
• Evidence: Layout tree shows nodes #64 and #65 (div.gbh) as block elements in normal flow with content at (0, 25, 800, 0). They have border: 1 0 0 0 (from border-top:1px solid #c9d7f1) but are positioned sequentially in the flow rather than absolutely.

F-005: <nobr> element not preventing line wrapping

• Status: Open
• Found: 2026-03-02
• Category: Parsing
• Severity: Low
• Description: The <nobr> element is a non-standard HTML element that should prevent line breaks within its content. While the nav bar content currently fits on one line (so no wrapping occurs), the engine may not recognize <nobr> as having white-space: nowrap semantics. At narrower viewport widths, the nav items could incorrectly wrap. Cannot fully verify without a narrow viewport test.
• Evidence: <nobr> elements present in both #gbar and #guser nav sections. Layout tree shows them as generic inline boxes with no special white-space handling.

F-006: Link underlines rendered as separate rectangles per word fragment

• Status: Open
• Found: 2026-03-02
• Category: Display
• Severity: Low
• Description: Text-decoration underlines for multi-word links (e.g., "Web History", "Sign in") are rendered as separate SolidRect segments per word fragment rather than a continuous underline spanning the entire link text including the inter-word space. This creates visible gaps in the underline between words.
• Evidence: Display list shows "Web" underline at rect=(658.17, 14.50, 20.13, 1) and "History" underline at rect=(680.79, 14.50, 32.14, 1) — a gap of ~2.5px between them (680.79 - 658.17 - 20.13 = 2.49). Similarly, "Sign" and "in" have separate underline rects with a gap.

F-007: display: inline-box fallback not handled correctly

• Status: Open
• Found: 2026-03-02
• Category: CSS Support
• Severity: Low
• Description: The .ds class uses display:inline-box;display:inline-block as a progressive enhancement pattern (inline-box for older IE, inline-block for modern browsers). The engine should ignore the invalid inline-box value and use inline-block from the second declaration. This appears to work correctly based on the layout (node #83 is inline-block), but should be verified that the fallback parsing is intentional and not accidentally working.
• Evidence: CSS .ds{display:inline-box;display:inline-block;...}. Layout shows node #83 as inline-block. Likely working correctly.

Stats

Status	High	Medium	Low	Total
Open	0	2	5	7
Fixed	0	0	0	0