I think from a spec lawering point of view "these are arguably not defined as errors in the specification" is missing the point: the specification just fails to consider that there might be an element without bounding client rects, so everything in that case is undefined behaviour. In general the idea that you can have a coordinate origin that doesn't correspond to a visible point on the screen doesn't seem reasonable. Presumably in the case of `<option>` you want something like "the position it would be displayed, if it were being displayed". But even that doesn't quite work: if e.g. the select has a scrollable UI then there are multiple possible postions the element could be in. So I guess the question is: what's the expected behaviour here? Is it expected that the user does some work to ensure that the element is actually in view, or is the idea that we have some way to dispatch events to specific option elements without actually dealing with the browser-specific select UI? What exactly is Chrome doing in these cases? I agree this is a regression and we should prioritize a fix, but I don't think we should do so without a clear understanding of what we're trying to achieve. If you happen to have a testcase we can use to investigate this behaviour, that would be helpful.
Bug 1773264 Comment 10 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
I think from a spec lawyering point of view "these are arguably not defined as errors in the specification" is missing the point: the specification just fails to consider that there might be an element without bounding client rects, so everything in that case is undefined behaviour. In general the idea that you can have a coordinate origin that doesn't correspond to a visible point on the screen doesn't seem reasonable. Presumably in the case of `<option>` you want something like "the position it would be displayed, if it were being displayed". But even that doesn't quite work: if e.g. the select has a scrollable UI then there are multiple possible postions the element could be in. So I guess the question is: what's the expected behaviour here? Is it expected that the user does some work to ensure that the element is actually in view, or is the idea that we have some way to dispatch events to specific option elements without actually dealing with the browser-specific select UI? What exactly is Chrome doing in these cases? I agree this is a regression and we should prioritize a fix, but I don't think we should do so without a clear understanding of what we're trying to achieve. If you happen to have a testcase we can use to investigate this behaviour, that would be helpful.