NEW Bug 5445
[WebCoreBridge firstRectForDOMRange:] works incorrectly for visible overflowed text
https://bugs.webkit.org/show_bug.cgi?id=5445
Summary [WebCoreBridge firstRectForDOMRange:] works incorrectly for visible overflowe...
Alexey Proskuryakov
Reported 2005-10-20 13:04:41 PDT
(spin-off from bug 5401) If firstRectForDOMRange is called for text that has overflowed its box, it always returns a single-pixel rect at the right border of the box. As Justin has pointed out, the problem is in RenderText::caretRect (...): RenderBlock *cb = containingBlock(); int availableWidth = cb->lineWidth(top); if (style()->whiteSpace() == NORMAL) left = kMin(left, absx + box->m_x + availableWidth - 1); However, simply adding a check like (style()->overflow() != OVISIBLE) is not a complete solution, because the box itself may be nested in another box with overflow: hidden, or otherwise obscured. The attached test case checks for this, too.
Attachments
test case (for run-webkit-tests) (1.83 KB, text/html)
2005-10-20 13:05 PDT, Alexey Proskuryakov
no flags
Safari 15.6 matches Chrome but differs from Firefox (526.48 KB, image/png)
2022-07-30 15:58 PDT, Ahmad Saleem
no flags
Alexey Proskuryakov
Comment 1 2005-10-20 13:05:07 PDT
Created attachment 4425 [details] test case (for run-webkit-tests)
Ahmad Saleem
Comment 2 2022-07-30 15:58:07 PDT
Created attachment 461316 [details] Safari 15.6 matches Chrome but differs from Firefox As can be seen from attached screenshot that in case of text overflow - Safari 15.6 matches with Chrome Canary 106 but differs from Firefox Nightly 105. I am not sure on web-spec or expected behavior but wanted to share updated results. Thanks!
Alexey Proskuryakov
Comment 3 2022-07-30 18:48:44 PDT
Comment on attachment 4425 [details] test case (for run-webkit-tests) The fact that the test renders differently in different browsers is unexpected, but is not the point of this bug. This test relies on features that are only exposed in DumpRenderTree harness, so it needs to be run via run-webkit-tests script. Also, even though this sounds like a Legacy WebKit API bug report, it is really about inline text input behavior, so it's not necessarily obsolete.
Note You need to log in before you can comment on or make changes to this bug.