misplaced padding of inlines which are RTLed or have RTL text

RESOLVED FIXED

Status

()

Core
Layout: Text
--
major
RESOLVED FIXED
14 years ago
9 years ago

People

(Reporter: Eyal Rozenberg, Assigned: mkaply)

Tracking

(Blocks: 2 bugs, {rtl})

Trunk
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(5 attachments)

(Reporter)

Description

14 years ago
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

14 years ago
Created attachment 158604 [details]
testcase
(Reporter)

Comment 2

14 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

14 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.
It has to be a dupe.
OS: Windows XP → All
Hardware: PC → All
(Reporter)

Comment 5

14 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
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 → ---
(Reporter)

Comment 7

14 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

14 years ago
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.
(Reporter)

Updated

14 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

14 years ago
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.
*** Bug 277693 has been marked as a duplicate of this bug. ***

Comment 11

13 years ago
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.
(Reporter)

Comment 12

13 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

13 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.

Updated

13 years ago
Blocks: 294181

Updated

13 years ago
Blocks: 290160
*** Bug 308032 has been marked as a duplicate of this bug. ***
*** Bug 318802 has been marked as a duplicate of this bug. ***

Updated

12 years ago
Blocks: 137995

Updated

12 years ago
Depends on: 299065

Updated

12 years ago
Blocks: 258949
This does not depend on bug 121633. In fact, fixing that bug is going to be a lot more difficult than this one.
No longer blocks: 277693
No longer depends on: 121633

Comment 17

12 years ago
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 (naderi@metanetworking.com)
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 ago12 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. ***

Updated

12 years ago
Blocks: 285718

Comment 21

10 years ago
Mass-assigning the new rtl keyword to RTL-related (see bug 349193).
Keywords: rtl

Updated

10 years ago
Component: Layout: BiDi Hebrew & Arabic → Layout: Text
QA Contact: zach → layout.fonts-and-text
You need to log in before you can comment on or make changes to this bug.