1.10 KB, text/html
1.47 KB, text/html
1.29 KB, text/html
330 bytes, text/html
11.77 KB, patch
|Details | Diff | Splinter Review|
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:
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?!
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.
It has to be a dupe.
OS: Windows XP → All
Hardware: PC → All
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
Last Resolved: 14 years ago
Resolution: --- → DUPLICATE
Padding and margins are different beasties.... reopening and marking dependent.
Status: RESOLVED → UNCONFIRMED
Depends on: 121633
Resolution: DUPLICATE → ---
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
Created attachment 162619 [details] Another testcase 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.
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
Created attachment 162839 [details] Workaround for authors 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.
13 years ago
*** Bug 277693 has been marked as a duplicate of this bug. ***
Created attachment 180930 [details] A simple testcase of LTR-RTL It seems that the padding is being replaced by a margin when displaying text in RTL layout.
(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.
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.
*** Bug 308032 has been marked as a duplicate of this bug. ***
*** Bug 318802 has been marked as a duplicate of this bug. ***
This does not depend on bug 121633. In fact, fixing that bug is going to be a lot more difficult than this one.
Created attachment 211550 [details] [diff] [review] This patch fixes the problem Hi, but the patch we submitted for 121633 fixes this one as well. Mohsen Naderi (firstname.lastname@example.org)
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
Last Resolved: 14 years ago → 12 years ago
Resolution: --- → FIXED
*** Bug 258949 has been marked as a duplicate of this bug. ***
*** Bug 290160 has been marked as a duplicate of this bug. ***
Mass-assigning the new rtl keyword to RTL-related (see bug 349193).
Component: Layout: BiDi Hebrew & Arabic → Layout: Text
QA Contact: zach → layout.fonts-and-text
Reftest based on attachment 162619 [details] checked in in http://hg.mozilla.org/mozilla-central/rev/b7b8d7526192
You need to log in before you can comment on or make changes to this bug.