1939472 - chatgpt.com - A dot is present under the message input field area

Status: VERIFIED WORKSFORME

(Web Compatibility :: Site Reports, defect, P2)

Description

[Raul Bucata]

Environment:
Operating system: Windows 10
Firefox version: Firefox stable

Steps to reproduce:

1. Navigate to: https://chatgpt.com/
2. Perform account login
3. Once on the chatgpt message page, refresh the page
4. Observe

Expected Behavior:
There are no glitches

Actual Behavior:
A dot in present under the message input area, on the left side

Notes:

• Reproduces regardless of the status of ETP
• Reproduces in firefox-nightly, and firefox-release
• Does not reproduce in chrome

Created from https://github.com/webcompat/web-bugs/issues/145658

Comment 1

[Raul Bucata]

Attachment: Chr vs FF

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

Since nightly and release are affected, beta will likely be affected too.
For more information, please visit BugBot documentation.

Comment 3

[Daniel Holbert [:dholbert]]

The dot here is from this element in ChatGPT's DOM:

<div data-radix-popper-content-wrapper="" style="position: fixed; left: 0px; top: 0px; transform: translate(370px, 539px); min-width: max-content; --radix-popper-transform-origin: 0% 0px; z-index: auto; --radix-popper-available-width: 877.5px; --radix-popper-available-height: 424.5px; --radix-popper-anchor-width: 768px; --radix-popper-anchor-height: 96px;"><div data-side="bottom" data-align="start" data-state="open" role="dialog" id="radix-:R19nnkkuiiklj5:" style="--radix-popover-content-transform-origin: var(--radix-popper-transform-origin); --radix-popover-content-available-width: var(--radix-popper-available-width); --radix-popover-content-available-height: var(--radix-popper-available-height); --radix-popover-trigger-width: var(--radix-popper-anchor-width); --radix-popover-trigger-height: var(--radix-popper-anchor-height);" tabindex="-1"></div></div>

If I add [data-radix-popper-content-wrapper] { display: none; } in e.g. a Stylus rule, then the issue goes away. Or if, instead of display:none, I use e.g. border: 30px solid cyan, then the dot becomes more prominent, as you might expect.

Comment 4

[Daniel Holbert [:dholbert]]

It looks like that element is focused (or at least has :focus-visible applied) by default, and that grants outline:auto which in Firefox draws this outline, whereas in Chrome it draws nothing.

Comment 5

[Daniel Holbert [:dholbert]]

Yeah, so there are two differences here that I'm seeing, which both contribute to this problem.

(1) Chrome and WebKit do not draw any outline for outline:auto, if the element has zero height and/orwidth. Whereas Firefox does draw a (very small) outline.

(2) In Firefox, this data-radix-popper-content-wrapper element (or its child?) seem to get focus by default at pageload, for some reason (which in turn grants it that outline:auto, which in turn makes it paint a small outline, which in this case looks like a dot). It doesn't seem to get focus by default in Firefox, though.

These issues combine to cause this problem -- the wrong element is focused at pageload, and that element is 0x0 and happens to draw a tiny ring when it's focused which makes it look like a little graphical glitch.

Comment 6

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #3)

The dot here is from this element in ChatGPT's DOM:

<div data-radix-popper-content-wrapper=""  [etc...]

Actually the relevant element is the child of that element, which for me has id="radix-:R19nnkkuiiklj5:" but I'm guessing that ID is sort of arbitrary and might not stay the same over time. So it's easier to find the element via the data-radix-popper-content-wrapper attribute on its parent.

(In reply to Daniel Holbert [:dholbert] from comment #5)

(2) In Firefox, this data-radix-popper-content-wrapper element (or its child?) seem to get focus by default at pageload, for some reason

Actually, good news - this part is true in Chrome as well, some of the time at least. There's just some nondeterminism at pageload time that made this sometimes not happen for me.

Here are two user-styles that I applied in the Stylus extension in Chrome to help with poking at Chrome's beahvior here:
STYLE A: make the zero-size element a bit bitter, to artificially trigger the same results in Chrome (nerfing difference (1) from comment 5):

[data-radix-popper-content-wrapper] > * { min-width: 10px; min-height: 10px; }

STYLE B: just add some custom styling to whatever is focused (whether that^ element or some other one):

:focus-visible { height: 50px; width: 200px; background: red; }

STYLE A makes the same bug reproduce for me most of the time in Chrome. When it doesn't reproduce, STYLE B helps illustrate why -- sometimes (not always) the chat message textbox gets autofocused at pageload and the zero-sized element does not get focus.

Comment 7

[Daniel Holbert [:dholbert]]

I filed bug 1940347 on the fact that we draw an outline around the 0-sized element, which I think is the only real behavioral difference that results in this issue here.

Comment 8

[Daniel Holbert [:dholbert]]

Attachment: screenshot of how the ChatGPT UI looks in March 2026 (no dot anymore)

I can't repro anymore - it looks like the design has changed now (see screenshot), and I don't see this dot or the adjacent UI, and there's no mention of data-radix-popper-content-wrapper (from comment 3) in the page's DOM at all anymore.

--> Closing as WFM - though Raul, would you mind confirming that this is fixed for you as well?

Comment 9

[Raul Bucata]

I can confirm that this is also fixed for me, with the same mention that is seems that an UI update was received

Comment 10

[Daniel Holbert [:dholbert]]

Thanks!