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 `&nbsp;`) 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 |