Bug 1939472 Comment 6 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

(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](https://chromewebstore.google.com/detail/stylus/clngdbkpkpeebahjckkjfobafhncgmne?hl=en) 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):
```css
[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.
(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](https://chromewebstore.google.com/detail/stylus/clngdbkpkpeebahjckkjfobafhncgmne?hl=en) 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):
```css
[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):
```css
: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.

Back to Bug 1939472 Comment 6