(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.
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): ```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.