Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Triple click line selection in Firefox #14

Open
manstie opened this issue Nov 10, 2020 · 4 comments
Open

Triple click line selection in Firefox #14

manstie opened this issue Nov 10, 2020 · 4 comments

Comments

@manstie
Copy link

manstie commented Nov 10, 2020

How to reproduce:

  1. Open http://edg2s.github.io/rangefix/ in Firefox 82.0.2
  2. Triple click to select the whole line with the example image
  3. image
@edg2s
Copy link
Owner

edg2s commented Nov 10, 2020

Thanks. It looks like with triple click on FF the range becomes [<p> ... </p>] (start/end node: p, offsets: [0,2]), whereas on Chrome, triple click stills selects inside text nodes: <p>[ ... ]</p>.

Setting this programmatically in Chrome gives incorrect rectangles:

image

I would say this is a bug in both browsers, although clearly more problematic in FF.

@edg2s
Copy link
Owner

edg2s commented Nov 10, 2020

The cause of this bug appears to be the display: inline-block <img> which is wrapped in an display: inline <u>. If i remove the inline wrapper, everything works fine in all browsers:

image

@edg2s
Copy link
Owner

edg2s commented Nov 10, 2020

@edg2s
Copy link
Owner

edg2s commented Nov 14, 2020

According to a comment on the Firefox task, this is behaving according to specification:

So spec is in https://drafts.csswg.org/cssom-view-1/#dom-range-getclientrects:

For each element selected by the range, whose parent is not selected by the range, include the border areas returned by invoking getClientRects() on the element.

So it seems to me that if <u> is selected by the range completely, then we'd return an smaller rect than if it wasn't per the above definition (because when <u> is not fully selected, then we union the getClientRects() of the text and the image, instead of just returning the rects of the <u>). That seems unfortunate, though it's what the spec seems to call for.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants