Inline-block elements are a conundrum for a11y line boundaries because they contain their own idea of lines. According to an inline-block element, the first element inside it begins a new line. On the other hand, from the perspective of the containing block element, it doesn't begin a new line because it's placed within a line in its enclosing block element. For example:
<p>a<button>b</button>c</p>
This should be considered one single line. Currently, TextLeafPoint treats the button as a separate line because the two frames have different enclosing blocks and line numbers within those.
I'm not quite sure how to deal with this. I think we might have to walk outside of inline-block elements and work from there.

A more complicated example is this:
<p>a<button>b<br>c</button>d</p>
Currently, HyperTextAccessible's handling of this depends on what Accessible you query. That is, if you query the block, the inline-block is included on the same line as the other inline content. If you query the inline-block, you see the separate lines inside it.
That behaviour is weird for TextLeafPoint because it means you'll get different line boundaries depending on where you search from.

For now, I think we should deal with the first example and figure out how to handle the second in a follow-up, especially given that HyperTextAccessible doesn't handle the second particularly well right now either.