Closed Bug 332360 Opened 19 years ago Closed 18 years ago

Incorrect rendering with float: right and direction: rtl on list elements

Categories

(Core :: Layout: Text and Fonts, defect)

Product:
Core
Component:
Layout: Text and Fonts
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: munzirtaha, Assigned: hsaito54)

References

Details

(Keywords: rtl, testcase)

Attachments

(3 files, 3 obsolete files)

Testcase
634 bytes, text/html
Details
testcase2
768 bytes, text/html
Details
updated patch
5.70 KB, patch
dbaron
: review+
dbaron
: superreview+
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060324 Ubuntu/dapper Firefox/1.5.0.1 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060324 Ubuntu/dapper Firefox/1.5.0.1 While browsing many Arabic (which is a right-to-left language) sites, I always notice strange problems with firefox. Yesterday, I tried to play a little with CSS and noticed that firefox handling of css rules is buggy when float: right and direction: rtl; is used. Here I put two simple pages that proves it. <html> <head> <style type="text/css"> ul { display: inline; } li { float: right; direction: rtl; } </style> </head> <body> <table> <tr> <td> <ul> <li>One</li> <li>Two</li> <li>Three</li> </ul> </td> </tr> The display: inline rule should render the above(below?) in one line </table> </body> </html> <html> <head> <style type="text/css"> ul { border-bottom: 1px solid; } li{ direction: rtl; float: right; } } </style> </head> <body> <ul> <li> Bug #1: No bullets appear! </li> <li> Bug #2: The first two bugs appear on one line! </li> <li> Bug #3: Using float: right, renders border-bottom over the unordered list. </li> </ul> </body> </html> Reproducible: Always Steps to Reproduce: 1.Just copy/paste these couple of pages 2.Browser them with Firefox 3.Read the bugs description here and on the text of the page itself
*** Bug 332361 has been marked as a duplicate of this bug. ***
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9a1) Gecko/20060331 Firefox/1.6a1 - Build ID: 0000000000 Confirmed. The bullet points are rendered on the right-hand side of the <li> text (which is correct), but they're about a page's width too far out to the right.
Status: UNCONFIRMED → NEW
Component: General → Layout: BiDi Hebrew & Arabic
Ever confirmed: true
Keywords: testcase
Product: Firefox → Core
Summary: firefox has buggy CSS handling when float: right and direction: rtl; is used → Incorrect rendering with float: right and direction: rtl bon list elements
Version: unspecified → Trunk
Attached file Testcase —
Umm!Thanks Philip Withnall for pointing out that it's rendered far to the right and I need to move the horizontal scrollbar to see them. Of course, there shouldn't be a scrollbar at all and this is the reason I didn't notice it ;) I also apologize if this bug should be divided into more than one bug and I was in a hurry to polish it more.
Component: Layout: BiDi Hebrew & Arabic → Build Config
Product: Core → Firefox
Version: Trunk → 1.0 Branch
OS: Linux → All
Product: Firefox → Core
Hardware: PC → All
Version: 1.0 Branch → Trunk
Component: Build Config → Layout: BiDi Hebrew & Arabic
QA Contact: general → layout.bidi
This is somewhat similar, and therefore likely related to, bug 332975.
Depends on: 332975
Summary: Incorrect rendering with float: right and direction: rtl bon list elements → Incorrect rendering with float: right and direction: rtl on list elements
Blocks: 332975
No longer depends on: 332975
Attached file testcase2 (obsolete) —
Status: NEW → ASSIGNED
Attached patch patch (obsolete) — — Splinter Review
Uri, could you look at this patch? I think that the relative position from the width of list elements should be used instead of the available width.
Attachment #217665 - Flags: review?(uriber)
Comment on attachment 217665 [details] [diff] [review] patch I'm sorry, but I'm not qualified to review patches in this area. Please request review from one of the Layout peers. Anyway, I think that if you make this change, you have to modify the comment accordingly (currently it explains the usage of |rs.availableWidth|, which you are removing).
Attachment #217665 - Flags: review?(uriber)
Attached file testcase2 —
testcase for float:left and float:right Uri, thanks for your advice. I will do so.
Attachment #217664 - Attachment is obsolete: true
Attached patch patch (obsolete) — — Splinter Review
David, could you review this patch?
Attachment #217665 - Attachment is obsolete: true
Attachment #217707 - Flags: review?(dbaron)
Sorry it took me so long to get to this. The code in the patch looks ok (although now you should just use reflowState.ComputedWidth() instead of aState.mContentArea.width), but I don't understand the comment. And now that the reflow branch has landed I don't see any reason anyone would want to switch back to availableWidth, so I don't think any comment is necessary.
Attached patch updated patch — — Splinter Review
This is updated to the trunk, with my comments addressed, and with automated reftests added that will catch a regression.
Attachment #217707 - Attachment is obsolete: true
Attachment #217707 - Flags: review?(dbaron)
Attachment #257773 - Attachment is patch: true
Attachment #257773 - Attachment mime type: application/octet-stream → text/plain
Assignee: nobody → saito
Status: ASSIGNED → NEW
Revised patch checked in to the trunk. Sorry for the huge delay, and thanks for the patch.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Any chance this could go on the 1.8 branch since it is such a small fix? We're seeing this with one of our products.
Mass-assigning the new rtl keyword to RTL-related (see bug 349193).
Keywords: rtl
Component: Layout: BiDi Hebrew & Arabic → Layout: Text
QA Contact: layout.bidi → layout.fonts-and-text
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: