feat: add toolbar state helpers

[arvindell]

Why

We wanted to add a simple toolbar toggle in our app, but the SDK only exposed loadToolbar(). That made us reach into DOM state and clear toolbar storage manually to figure out whether the toolbar was open and how to hide it again.

What changed

• add posthog.isToolbarLoaded()
• add posthog.hideToolbar()
• expose both on the public PostHog type
• add unit coverage for the toolbar extension
• include a changeset

[vercel]

@arvindell is attempting to deploy a commit to the PostHog Team on Vercel.

A member of the Team first needs to authorize it.

[greptile-apps]

Prompt To Fix All With AI

This is a comment left during a code review.
Path: .changeset/clean-schools-hunt.md
Line: 2

Comment:
**`@posthog/core` not changed in this PR**

The changeset bumps `@posthog/core` as `minor`, but no files under `packages/core/` were modified. The diff only touches `packages/browser/` (`posthog-js`) and `packages/types/` (`@posthog/types`). Including an unrelated package risks triggering an unnecessary release of `@posthog/core`.

```suggestion
'@posthog/types': minor
```

**Rule Used:** In the posthog/posthog-js repository, /packages/br... ([source](https://app.greptile.com/review/custom-context?memory=1e5ca16f-9836-4241-953d-21bcf9017456))

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: packages/browser/src/extensions/toolbar.ts
Line: 52-53

Comment:
**Redundant `toolbar.remove()` after `container?.remove()`**

When `container` is found, `container?.remove()` already removes the container's entire subtree from the DOM (including `toolbar`). The subsequent `toolbar.remove()` call is a harmless no-op in that case, but it's superfluous. When `container` is `null`, `toolbar.remove()` is the only effective call, so it's still needed. Consider guarding with `else` or only removing toolbar when there's no container:

```suggestion
        if (container) {
            container.remove()
        } else {
            toolbar.remove()
        }
```

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "fix: reuse toolbar container constant" | Re-trigger Greptile}

[greptile-apps]

@posthog/core not changed in this PR

The changeset bumps @posthog/core as minor, but no files under packages/core/ were modified. The diff only touches packages/browser/ (posthog-js) and packages/types/ (@posthog/types). Including an unrelated package risks triggering an unnecessary release of @posthog/core.

Suggested change

	'@posthog/core': minor
	'@posthog/types': minor

Rule Used: In the posthog/posthog-js repository, /packages/br... (source)

Prompt To Fix With AI

This is a comment left during a code review.
Path: .changeset/clean-schools-hunt.md
Line: 2

Comment:
**`@posthog/core` not changed in this PR**

The changeset bumps `@posthog/core` as `minor`, but no files under `packages/core/` were modified. The diff only touches `packages/browser/` (`posthog-js`) and `packages/types/` (`@posthog/types`). Including an unrelated package risks triggering an unnecessary release of `@posthog/core`.

```suggestion
'@posthog/types': minor
```

**Rule Used:** In the posthog/posthog-js repository, /packages/br... ([source](https://app.greptile.com/review/custom-context?memory=1e5ca16f-9836-4241-953d-21bcf9017456))

How can I resolve this? If you propose a fix, please make it concise.

[greptile-apps]

Redundant toolbar.remove() after container?.remove()

When container is found, container?.remove() already removes the container's entire subtree from the DOM (including toolbar). The subsequent toolbar.remove() call is a harmless no-op in that case, but it's superfluous. When container is null, toolbar.remove() is the only effective call, so it's still needed. Consider guarding with else or only removing toolbar when there's no container:

Suggested change

	container?.remove()
	toolbar.remove()
	if (container) {
	container.remove()
	} else {
	toolbar.remove()
	}

Prompt To Fix With AI

This is a comment left during a code review.
Path: packages/browser/src/extensions/toolbar.ts
Line: 52-53

Comment:
**Redundant `toolbar.remove()` after `container?.remove()`**

When `container` is found, `container?.remove()` already removes the container's entire subtree from the DOM (including `toolbar`). The subsequent `toolbar.remove()` call is a harmless no-op in that case, but it's superfluous. When `container` is `null`, `toolbar.remove()` is the only effective call, so it's still needed. Consider guarding with `else` or only removing toolbar when there's no container:

```suggestion
        if (container) {
            container.remove()
        } else {
            toolbar.remove()
        }
```

How can I resolve this? If you propose a fix, please make it concise.

[github-actions]

This PR hasn't seen activity in a week! Should it be merged, closed, or further worked on? If you want to keep it open, post a comment or remove the stale label – otherwise this will be closed in another week.