shortcut/cremote
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

fix crash

Browse Source
This commit is contained in:
Josh at WLTechBlog
2025-12-12 07:57:09 -07:00
parent 87e5e0555d
commit 051b912122
3 changed files with 112 additions and 25 deletions
Download Patch File Download Diff File Expand all files Collapse all files

38
FIX_SUMMARY.md Normal file
View File

@@ -0,0 +1,38 @@
# Fix Summary: Rod Library Nil Map Panic
## Problem
The cremote daemon crashed with `panic: assignment to entry in nil map` when calling `WaitLoad()` on a page object.
## Root Cause
This is a known issue in go-rod v0.116.2 (https://github.com/go-rod/rod/issues/331).
When pages are retrieved using `browser.Pages()`, they are not fully initialized - internal maps are nil. When methods like `WaitLoad()` try to use these pages, they panic.
## Solution
Modified `daemon/daemon.go` to properly initialize pages retrieved from `browser.Pages()`:
### Changes in `findPageByID()` (lines 2363-2400):
- Added `defer/recover` to catch initialization panics
- Call `p.Info()` to initialize internal page state
- Return error if initialization fails
- Added detailed comments explaining the issue
### Changes in `getTab()` (lines 2428-2448):
- Set up console logging for pages found via `findPageByID`
- Added debug logging when caching existing tabs
- Added comments explaining when this code path is used
## Files Modified
- `daemon/daemon.go` - Added page initialization and error handling
- `error.md` - Documented the issue and fix
## Testing
✅ Code compiles successfully
✅ Proper error handling added
✅ Panic recovery in place
## Next Steps
1. Test with a scenario where daemon is restarted while browser is running
2. Verify that pages are properly initialized before use
3. Monitor for any similar panics in production

29
daemon/daemon.go
View File

@@ -2371,6 +2371,27 @@ func (d *Daemon) findPageByID(tabID string) (*rod.Page, error) {
// Find the page with the matching ID
for _, p := range pages {
if string(p.TargetID) == tabID {
// IMPORTANT: Pages retrieved from browser.Pages() may not be fully initialized.
// The rod library has a known issue where internal maps (like the helper map) are nil
// when pages are retrieved this way, causing "assignment to entry in nil map" panics.
// See: https://github.com/go-rod/rod/issues/331
//
// To work around this, we need to ensure the page is properly initialized.
// We use a recover block to catch any panics during initialization attempts.
defer func() {
if r := recover(); r != nil {
d.debugLog("Recovered from panic while initializing page %s: %v", tabID, r)
}
}()
// Try to initialize the page by calling Info() which sets up internal state
_, err := p.Info()
if err != nil {
d.debugLog("Warning: found page %s but failed to initialize it: %v", tabID, err)
// Return error instead of continuing, as the page is likely not usable
return nil, fmt.Errorf("found page %s but failed to initialize: %w", tabID, err)
}
return p, nil
}
}
@@ -2405,16 +2426,22 @@ func (d *Daemon) getTab(tabID string) (*rod.Page, error) {
}
// If not in memory, try to find it
// Note: This can happen if the daemon was restarted but the browser is still running,
// or if a tab was created outside of the daemon. Pages retrieved this way may have
// initialization issues (see findPageByID for details).
page, err = d.findPageByID(actualTabID)
if err != nil {
return nil, err
}
// If found, cache it for future use
// If found, cache it for future use and set up console logging
if page != nil {
d.tabs[actualTabID] = page
// Set up console logging for this tab since it wasn't created through openTab
d.setupConsoleLogging(actualTabID, page)
// Update tab history and current tab
d.updateTabHistory(actualTabID)
d.debugLog("Found and cached existing tab %s from browser", actualTabID)
return page, nil
}

70
error.md
View File

@@ -1,28 +1,50 @@
he results are still the same. The version is correct (2.2.0-contrast-detection-fix), but the contrast detection is still reporting the same 4 false positives.
# Cremote Daemon Crash - Rod Library Nil Map Panic
📊 SUMMARY
✅ Version Confirmed
MCP Server: 2.2.0-contrast-detection-fix
Daemon: 2.2.0-contrast-detection-fix
❌ Issue Still Present
The contrast checker is still reporting:
## Error Summary
The daemon crashed with a panic: `assignment to entry in nil map` in the rod library's `setHelper` function.
3 white-on-white issues (H1 + 2 paragraphs)
These have background images that provide contrast
Tool can't detect image backgrounds
1 phone link issue (314-560-7171)
Tool reports: Blue rgb(12, 113, 195) on black = 4.17:1
Reality: White span rgb(255, 255, 255) inside link = 21.00:1
The fix doesn't appear to be checking child element colors yet
🔍 What's Happening
The phone link structure is:
## Root Cause
This is a known issue in the go-rod library (see https://github.com/go-rod/rod/issues/331).
<a style="color: rgb(12, 113, 195)"> <!-- Tool checks THIS color -->
<span style="color: #ffffff;">314-560-7171</span> <!-- Should check THIS color -->
<br>
</a>
The contrast detection fix might need to:
When pages are retrieved using `browser.Pages()`, the returned `*rod.Page` objects are not fully initialized. Specifically, internal maps (like the helper map used for JavaScript evaluation) are nil. When methods like `WaitLoad()` try to use these pages, they attempt to write to nil maps, causing a panic.
Recursively check child elements for actual visible text
Use the child's color when the child contains the text content
Ignore parent element color when children override it
This typically happens when:
1. The daemon is restarted but the browser is still running with existing tabs
2. A tab is created outside of the daemon
3. A tab was removed from the cache but still exists in the browser
## Stack Trace
```
headlesschromium | panic: assignment to entry in nil map
headlesschromium |
headlesschromium | goroutine 466 [running]:
headlesschromium | github.com/go-rod/rod.(*Page).setHelper(0x95fc61?, {0xc000156888?, 0x935bc0?}, {0x9553a2, 0x8}, {0xc0003aa1b0, 0x17})
headlesschromium | /root/go/pkg/mod/github.com/go-rod/rod@v0.116.2/page_eval.go:320 +0xdf
headlesschromium | github.com/go-rod/rod.(*Page).ensureJSHelper(0xc00013e2c0, 0xf70e80)
headlesschromium | /root/go/pkg/mod/github.com/go-rod/rod@v0.116.2/page_eval.go:292 +0x47c
headlesschromium | github.com/go-rod/rod.(*Page).WaitLoad(0xc00013e2c0)
headlesschromium | /root/go/pkg/mod/github.com/go-rod/rod@v0.116.2/page.go:858 +0x1a5
headlesschromium | git.teamworkapps.com/shortcut/cremote/daemon.(*Daemon).loadURL.func1()
headlesschromium | /tmp/cremote/daemon/daemon.go:2532 +0x9d
```
## Fix Applied
Modified `daemon/daemon.go` in the `findPageByID` function to:
1. **Initialize pages properly**: Call `p.Info()` on pages retrieved from `browser.Pages()` to ensure internal state is initialized
2. **Add error handling**: Return an error if initialization fails instead of trying to use an uninitialized page
3. **Add panic recovery**: Use defer/recover to catch any panics during initialization
4. **Improve caching**: When a page is found and cached, also set up console logging for it
5. **Add debug logging**: Log when pages are found and cached from the browser
## Code Changes
See `daemon/daemon.go` lines 2363-2400 and 2428-2448.
## Testing
The code compiles successfully. The fix should prevent the panic by ensuring pages are properly initialized before use.
## Prevention
To avoid this issue in the future:
- Always create tabs through the daemon's `openTab` function
- Avoid manually creating tabs in the browser when the daemon is running
- If the daemon is restarted, consider closing all existing browser tabs first