fix: use shared-state background color to avoid nil pointer (#876)

[fsorodrigues]

Summary

Fixes #876 — TUI crashes with nil pointer dereference of markdownStyle when
BackgroundColorMsg not reached

This PR introduces background color shared state, default and fallback behaviors, and changes to the InitializeMarkdownStyle and GetMarkdownRender functions signatures to ensure that *markdownStyle is never nil when dereferenced.

• Closes issue [BUG] TUI crashes with nil pointer dereference when BackgroundColorMsg not reached #876
• I have read the CONTIBUTING.md and AI_POLICY.md guides

AI disclosure (per AI_POLICY.md)

Diagnosis of nil pointer dereference location was done with assistance of GPT-5.4 (via OpenCode). Same AI was also used to identify GetMarkdownRender usage extense given the bugfix plan I'm proposing involved altering the function's signature.

Solution

Here are the changes introduced:

internal/tui/context/context.go

• introduce 2 new fields to the ProgramContext struct: HasDarkBackground bool, BackgroundSource string

interna/tui/markdown/markdownRenderer.go

• alter InitializeMarkdownStyle and GetMarkdownRenderer signatures to include *context.ProgramContext. These ensure the shared state values ctx.HasBackground and ctx.BackgroundSource are available for the create of the markdown renderer.

internal/tui/ui.go

• initialize program context with defaults for ctx.HasBackground and ctx.BackgroundSource
• create fallback behavior that uses lipgloss's compat.HasDarkBackground as boolean for ctx.HasDarkBackground
• set background color fields in context from tea.BackgroundColorMsg when reached
• debug log statements with background color values

internal/tui/components/issueview/activity.go
internal/tui/components/issueview/issueview.go
internal/tui/components/prview/activity.go
internal/tui/components/prview/prview.go
internal/tui/modelUtils.go

• call GetMarkdownRender with context as argument

Testing

Verified the nil pointer derefence panic present on tag v4.24.1 on setup described in #876.

Rebuilt binary with patch (commit 46b5843), removed and reinstalled dash extension from local repo

Started gh dash with debug flag. Verified nil pointer derefence panic is gone and that debug logs describe shared state as expected.

Verified gh dash works normally and renders markdown contents of PRs and issues with expected background

[github-actions]

👋 Hi @fsorodrigues, thanks for the pull request! A scan flagged a concern with it. Could you please take a look?

[pr-task-completion] This PR's body is missing [x] checks on the following tasks from the PR template.

• [] I have read the CONTIBUTING.md and AI_POLICY.md guides

Repositories often provide a set of tasks that pull request authors are expected to complete. Those tasks should be marked as completed with a [x] in the pull request description. Please complete those tasks and mark the checks as [x] completed.

🗺️ This message was posted automatically by OctoGuide: a bot for GitHub repository best practices.

[dlvhdr]

I am not sure how this is supposed to work, but wouldn't we want to use the bubbletea background source when the BackgroundColorMsg arrives?
So I'd assume that we'd want to save the background source in a global var next to markdownStyle to know which source initialized it and if it's not nil but the source is compat - initialize it with the new bubbletea source.
Correct me if I'm wrong..

[fsorodrigues]

so... what I had in mind is a progression of "background color" certainty

• in tui/ui.go we set a default state for dark bg / dark bg source when the Model and Context are created. I when with a hardcoded true, which I'm happy for y'all to do whatever initial state you think is right.
• then in InitMsg we can "upgrade" the background color data in the Context using the value from lipgloss compat, which won't be a hardcoded value.
• finally, if/when the tea.BackgroundColorMsg arrives, we have the "most certain" background color to set the style with "finality". The finality being the reason for that addition to the if condition. However, I do see, now, that I made the bubbletea route effectively dead on arrival 🫤

I'll give it another crack in the morning with your suggestion.

[fsorodrigues]

@dlvhdr I think you can have another look.
On the setup that was crashing (wsl + alacritty + tmux), I now see the style initialized with the compat source.
On a setup that never saw the crash (macOs + ghostty + tmux), it follows the expected progression and reaches the bubbletea source.