Bug 105409
| Summary: | Refactor RenderText::linesBoundingBox() code for returning correct logical rect values. | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Arpita Bahuguna <arpitabahuguna> |
| Component: | Layout and Rendering | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED INVALID | ||
| Severity: | Normal | CC: | rniwa |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
Arpita Bahuguna
RenderText::linesBoundingBox() returns an IntRect as per the writing mode.
Thus, appropriate "logical" left, right, top and bottom calls are made to retrieve the corresponding values.
logicalLeft(), logicalRight(), logicalTop() and logicalBottom() (called on the inlineBox), all return values as per the writing mode.
Yet, while computing the width and height for the returned rect, we further interchange the values (for vertical writing mode), even though that has already been taken care of (by using the logical method calls).
This ultimately results in the returned rect not having the width and height set as per the writing mode. Or, in other words, the width and height set on the returned rect are always as per the horizontal writing mode.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Arpita Bahuguna
Verified the issue stated here to not be true. Upon further analysis have found that the confusion perhaps arises due to our comprehension of the terms logicalLeftSide and logicalRightSide when compared with the width and height.
In the horizontal writing mode, we have the leftSide and the rightSide indicate values as per their general convention as do the width and height.
But in the vertical writing mode, the logicalLeft points to the top value and the logicalRight points to the bottom value of the rect whereas the computed width and height values continue to be indicative of the actual width and height of the rect (with the width being equal to the font height and the height being equal to the actual text length).
Thus the implementation is indeed proper (although perhaps a bit misleading).
I propose to close this issue here.
Arpita Bahuguna
Closing since not an issue (see #1).