User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/11.1.2 Safari/605.1.15 Steps to reproduce: Please open the attached html document. Resize the browser's width to trigger vary the paragraph's width, and watch the red box trailing the anchor in the paragraph. Actual results: The red box is sometimes drawn several lines above where it is meant to be drawn. There does not appear to be an issue with the box placement on the X axis, but the Y axis is often incorrect. Expected results: The red box should always be drawn on the same line as the anchor, in between the blue text and the period.

It seems that when the bounding box for the anchor crosses over 2 lines, the red box is drawn relative to the top line, and not the box as a whole. `bottom: -3px` should be relative to the box of the entire anchor. Setting `display: inline-block` on the anchor does "fix" the issue, but the anchor will no longer break over multiple lines.

I can also reproduce the issue on Nightly64.0a1 Windows10 x64.

This triggers a bunch of warnings like: > We shouldn't be backing up more than once! Someone must have set a break opportunity beyond the available width, even though there were better break opportunities before it. When run in a debug build, fwiw. Do you know if this is a regression? i.e., has this worked in earlier Firefox versions? If so it'd be really helpful to know.

Nice testcase! I don't think this is a recent regression, at least. We have some existing bugs on file that involve hitting this same assertion, though I don't know offhand if this is directly equivalent to any of them: e.g. bug 1140279, bug 1486541. Back in bug 512978 it was only a warning, apparently, but may still be the same issue.

@jfkthame @emilio I tested back to version 40.0, and I could reproduce this issue in every major version between 62.0 and 40.0 (macOS).

A further observation: when the width is such that the testcase displays incorrectly, the position of the red box may be quite unstable (as well as wrong); reloading the page or zooming in and then out again may cause it to shift to a new -- but still incorrect -- position. (Results vary depending on the exact width/line-break involved.)

This may be similar to bug 779896 and bug 1144259, and may be fixed by doing bug 255139.