Closed
Bug 258928
Opened 20 years ago
Closed 18 years ago
misplaced padding of inlines which are RTLed or have RTL text
Categories
(Core :: Layout: Text and Fonts, defect)
Core
Layout: Text and Fonts
Tracking
()
RESOLVED
FIXED
People
(Reporter: eyalroz1, Assigned: mkaply)
References
(Blocks 2 open bugs)
Details
(Keywords: rtl)
Attachments
(5 files)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a3) Gecko/20040817 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a3) Gecko/20040817 Padding which is applied to consecutive (_not_ single!) inline elements such as <a> and <span>, is not applied when their containing block element's direction is RTL or if they contain text in an RTL script such as Hebrew. In some cases the padding is applied outside of the inline element instead of inside, and only on one side. Note: this bug screws up the mozdev navigation bar if you're trying to create a Hebrew version of your project website. Reproducible: Always Steps to Reproduce:
Reporter | ||
Comment 1•20 years ago
|
||
Reporter | ||
Comment 2•20 years ago
|
||
This bug may be related to bug 178991 (unclickable links if near parenthesis) and bug 197955 (3 separate hyperlinks all pointed to the same place) - links are inline elements... Why oh why must gecko be so broken?!
Reporter | ||
Comment 3•20 years ago
|
||
Correction: looking at my testcase again (am I blind or what?) it seems that this bug is also manifested for a single span, with direction RTL and an RTL-language-text span. I hope these are not two separate bugs.
Reporter | ||
Comment 5•20 years ago
|
||
Although this bug is about padding, not margins, it seems that indeed the problem is the one mentioned in 121633. *** This bug has been marked as a duplicate of 121633 ***
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
Comment 6•20 years ago
|
||
Padding and margins are different beasties.... reopening and marking dependent.
Reporter | ||
Comment 7•20 years ago
|
||
Since this bug is not a dupe and has merited reopening, it is valid. Plus I now have my new confirm privs...
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 8•20 years ago
|
||
The bug description is not good. There are two problems: 1. Missing padding 2. right padding or margins increase as you increase the number of elements. With 10 elements in my testcase, it is almost left aligned! This is very annoying bug for RTL users. I suspect its related to the RTL list bug when they were indented out of the page. Maybe the fix of that bug is responsible for this. I don't remember that increasing right padding/margin before that bug was fixed.
Reporter | ||
Updated•20 years ago
|
Summary: Padding not applied to inline elements which are RTLed or have RTL text → misplaced padding of inlines which are RTLed or have RTL text
Comment 9•20 years ago
|
||
This is a way to workaround this bug, by floating the <li> elements instead of displaying them as inline. There is one catch, with narrow window, the floated li float down to the next line, which breaks the design visually. The only other way I found is use good old table for this kind of interface.
Comment 10•19 years ago
|
||
*** Bug 277693 has been marked as a duplicate of this bug. ***
Comment 11•19 years ago
|
||
It seems that the padding is being replaced by a margin when displaying text in RTL layout.
Reporter | ||
Comment 12•19 years ago
|
||
(In reply to comment #11) > It seems that the padding is being replaced by a margin > when displaying text in RTL layout. No, I don't think that's it. More like: the non-padded RTL content is positioned at the leftmost part of the area, whose calculated width includes both the unpadded content and the padding; and the padding is not drawn. It's not as though you get margins from both sides.
Reporter | ||
Comment 13•19 years ago
|
||
Simon has suggested that the problem is with nsBidiPresUtils::RepositionInlineFrames(), which ignores a frame's padding when repositioning it's children; in line 633 it says frame->SetPosition(nsPoint(rect.XMost(), frame->GetPosition().y)); and rect.XMost() is what's wrong.
Comment 14•19 years ago
|
||
*** Bug 308032 has been marked as a duplicate of this bug. ***
Comment 15•19 years ago
|
||
*** Bug 318802 has been marked as a duplicate of this bug. ***
Comment 16•18 years ago
|
||
This does not depend on bug 121633. In fact, fixing that bug is going to be a lot more difficult than this one.
Comment 17•18 years ago
|
||
Hi, but the patch we submitted for 121633 fixes this one as well. Mohsen Naderi (naderi@metanetworking.com)
Comment 18•18 years ago
|
||
The testcases attached to this bug are all fixed by the fix to 299065, so marking FIXED. However, see bug 328168 for additional problems with paddings in bidi and RTL text.
Status: NEW → RESOLVED
Closed: 20 years ago → 18 years ago
Resolution: --- → FIXED
Comment 19•18 years ago
|
||
*** Bug 258949 has been marked as a duplicate of this bug. ***
Comment 20•18 years ago
|
||
*** Bug 290160 has been marked as a duplicate of this bug. ***
Comment 21•16 years ago
|
||
Mass-assigning the new rtl keyword to RTL-related (see bug 349193).
Keywords: rtl
Component: Layout: BiDi Hebrew & Arabic → Layout: Text
QA Contact: zach → layout.fonts-and-text
Comment 22•15 years ago
|
||
Reftest based on attachment 162619 [details] checked in in http://hg.mozilla.org/mozilla-central/rev/b7b8d7526192
Flags: in-testsuite+
You need to log in
before you can comment on or make changes to this bug.
Description
•