list items extremely outdent when left floating object exists

RESOLVED FIXED in mozilla1.9alpha1

Status

()

Core
Layout: Text
--
major
RESOLVED FIXED
13 years ago
a year ago

People

(Reporter: Tsahi Asher, Assigned: mkaply)

Tracking

(Blocks: 1 bug)

1.0 Branch
mozilla1.9alpha1
Points:
---
Bug Flags:
blocking1.8b5 -

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(8 attachments, 7 obsolete attachments)

(Reporter)

Description

13 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910

when you have an object floating left, and a list, either ordered or unordered
after it, the list items outdent the page.

Reproducible: Always
Steps to Reproduce:
1.open the url or the reduced test case i will attache here
2.observe the page
3.

Actual Results:  
list items in front of the left floating object are outdented about the same
width as the width of the object, thus creating a horizontal scrolbar.

Expected Results:  
items should be aligned on the right edge of the page, opposite to the object.

this didn't happen in mozilla 1.6. i will try to find the nightly where this
first happened. it could be a regression from bug 205235.
(Reporter)

Comment 1

13 years ago
Created attachment 160575 [details]
test case
(Reporter)

Comment 2

13 years ago
Comment on attachment 160575 [details]
test case

woops, wrong mime..
Attachment #160575 - Attachment mime type: text/plain → text/html
(Reporter)

Comment 3

13 years ago
actually, they don't nessesarily outdent the page, but their containing block,
as seen in the URL.
(Reporter)

Comment 4

13 years ago
unless i'm making a supid mistake here, i found this as far back as a nightly
from february 6th. too late at night now to check further.
Status: UNCONFIRMED → NEW
Ever confirmed: true
regressed in bug 74880, probably.
*** Bug 244899 has been marked as a duplicate of this bug. ***
*** Bug 271561 has been marked as a duplicate of this bug. ***

Comment 8

13 years ago
Created attachment 169516 [details]
testcase #2

Comment 9

13 years ago
Created attachment 169520 [details] [diff] [review]
patch

Comment 10

13 years ago
Created attachment 169521 [details]
screen shot for testcase #2

A lower half shows an original display, and the upper half of a screen shot
applies a patch.

Updated

13 years ago
Component: Layout: BiDi Hebrew & Arabic → Cmd-line Features

Updated

13 years ago
Component: Cmd-line Features → Layout: BiDi Hebrew & Arabic

Comment 11

13 years ago
Created attachment 169635 [details] [diff] [review]
patch
Attachment #169520 - Attachment is obsolete: true

Comment 12

13 years ago
Created attachment 169636 [details]
screen shot for test case

screen shot by my build with a patch

Updated

13 years ago
Attachment #169635 - Flags: review?(bzbarsky)
I'll try to look at the patch when I get back in town, but offhand I bet this is
a dup of one of the existing -moz-float-edge bugs....
For what it's worth, review would be helped along by an explanation, either in
the bug or in the patch, of what the various nontrivial changes are trying to
accomplish (in particular the nsHTMLReflowState.cpp changes, but also the others).

Comment 15

13 years ago
Comment on attachment 169635 [details] [diff] [review]
patch

I found a following wrong changes in the patch. It seems that the left margin
should not be added. I will test again and explain it.

   // Logic which is common to blocks and tables
   if (isAutoLeftMargin) {
     if (isAutoRightMargin) {
       // Both margins are 'auto' so their computed values are equal
-      mComputedMargin.left = availMarginSpace / 2;
-      mComputedMargin.right = availMarginSpace - mComputedMargin.left;
+      mComputedMargin.left += availMarginSpace / 2;
+      mComputedMargin.right += availMarginSpace - availMarginSpace / 2;
     } else {
-      mComputedMargin.left = availMarginSpace;
+      mComputedMargin.left += availMarginSpace;
     }
   } else if (isAutoRightMargin) {
-    mComputedMargin.right = availMarginSpace;
+    mComputedMargin.right += availMarginSpace;
   }
 }
Attachment #169635 - Flags: review?(bzbarsky)

Comment 16

13 years ago
Created attachment 171514 [details] [diff] [review]
patch
Attachment #169635 - Attachment is obsolete: true

Comment 17

13 years ago
(In reply to comment #14)
> For what it's worth, review would be helped along by an explanation,

I explain this patch using sample styles and figures as follows.

ul{  margin: 0 ul_mR 0 ul_mL;  padding: 0 ul_pR 0 ul_pL; }
li{  margin: 0 li_mR 0 li_mL;  padding: 0 li_pR 0 li_pL; }

wA is width of the window
<------------wA----------->

wB is remainder which subtracted margins and paddings from wA 
<--><--------wB-------><-->

The detail of wB is figured as follows. The value of sum is calculated at
nsHTMLReflowState::CalculateBlockSideMargins.

<----------------------------------wB------------------------------------>
 ul_mL ul_pL                     content                      ul_pR ul_mR
<----><-----><------><-------><------------><-------><------><-----><---->
               li_mL   li_pL                  li_pR    li_mR
             <-----------------aAvailWidth------------------>
             <--------------------sum----------------------->

If sum is less than aAvailWidth like as following figure, availMarginSpace is
remainder which subtracted sum from aAvailWidth. If the direction is RTL, I
think that li_mL should be added availMarginSpace, but not be set availMarginSpace.

<----------------------------------wB------------------------------------>
 ul_mL ul_pL                   content                    ul_pR ul_mR
<----><-----><------><-------><--------><-------><------><-----><---->
               li_mL   li_pL              li_pR    li_mR
             <-----------------aAvailWidth------------------>
             <------------------sum---------------------><-----table----->
                                                         <-->
                                                         availMarginSpace

The case of the table floats on the right side, I think that these changes for
nsHTMLReflowState::CalculateBlockSideMargins are not right becaue margins of the
li tag increase. Then, each margins are recalculated by the changes for
nsBlockReflowContext::ReflowBlock.

The changes for nsBlockFrame::ReflowBullet are to get the right x-position of
the marker if the direction is RTL. The x-position of that marker is calcurated
by adding li_pL, li_pR and content width to x-position whose value is zero.

           li_mL   li_pL                  li_pR    li_mR
          <------><-------><--content---><-------><------>
                 /\                              /\ x-position of the marker 
                  if x is zero, here is marker.   if the direction is RTL.
bz wasn't cced (see comment 14 / 17)

Comment 19

13 years ago
*** Bug 289138 has been marked as a duplicate of this bug. ***

Comment 20

13 years ago
Created attachment 182278 [details] [diff] [review]
patch

In the previous patch, the changes for nsBlockReflowContext::ReflowBlock are
not necessary, if not calculating the margin is possible when left margin or
right margin is not 'auto'.

Updated

13 years ago
Attachment #171514 - Attachment is obsolete: true
Attachment #182278 - Flags: review?(bzbarsky)
So let me see if I understand correctly.  The bug is that the bullet of the list
item is ending up somewhere too far out (unlike the ltr case).  Right?

If so, what's with the change to ComputeBlockSideMargins?  That change is
definitely wrong, since it leads to the wrong computed margins; the only thing
keeping it from causing obvious problems is that we ignore the computed margins
in nsBlockReflowContext::AlignBlockHorizontally, but we probably want to stop
doing that once the reflow branch lands...

Updated

13 years ago
Attachment #182278 - Attachment is obsolete: true
Attachment #182278 - Flags: review?(bzbarsky)

Comment 22

13 years ago
Comment on attachment 171514 [details] [diff] [review]
patch

> The bug is that the bullet of the list item is ending up 
> somewhere too far out (unlike the ltr case).  Right?

Yes, I intended to describe the reason of the changes on comment #17.
In the following illustration, x-position of the marker is calculated like as
"li_pL + content + li_pR". This calculation is equel to "aAvailWidth - li_mL -
li_mR".

	  <-----------------aAvailWidth------------------>
	   li_mL   li_pL		  li_pR    li_mR
	  <------><-------><--content---><-------><------>
		 /\				 /\ x-position of the marker 
		  if x is zero, here is marker.   if the direction is RTL.

> If so, what's with the change to ComputeBlockSideMargins?

The marker shifts, since CalculateBlockSideMargins replaces
|mComputedMargin.left| with |availMarginSpace| as 'auto' margin. This problem
is illustrated as follows.

the case of the float object places in the left side:
   <-----------------------------aAvailWidth-------------------------->
			li_mL	li_pL		       li_pR	li_mR
   <---float object---><------><-------><--content---><-------><------>
   <-availMarginSpace-><---------------------sum---------------------->

the case of the float object places in the right side:
   <-----------------------------aAvailWidth-------------------------->
     li_mL   li_pL		    li_pR    li_mR
   <------><-------><--content---><-------><------><---float object--->
   <---------------------sum----------------------><-availMarginSpace->

I think that |availMarginSpace| should be added to |li_mL|. The changes for
nsBlockReflowContext::ReflowBlock recalculates the left margin.
Attachment #171514 - Attachment is obsolete: false

Updated

13 years ago
Attachment #171514 - Flags: review?(bzbarsky)
As I understand, ComputeBlockSideMargins is supposed to produce the computed
margin for the element.  If code elsewhere is using this margin instead of some
other value it actually wants to be using, then said code should be fixed,
instead of hacking ComputeBlockSideMargins....
Comment on attachment 171514 [details] [diff] [review]
patch

Per comment 23.
Attachment #171514 - Flags: review?(bzbarsky) → review-
*** Bug 295713 has been marked as a duplicate of this bug. ***
*** Bug 296958 has been marked as a duplicate of this bug. ***

Comment 27

12 years ago
Created attachment 185598 [details]
another test case

Note how the width of the floating element effect the offset of the lists. I
don't have any idea how that code works, but seems that the width of the
floating element is subtracted from the location of the list.
*** Bug 297704 has been marked as a duplicate of this bug. ***

Updated

12 years ago
Flags: blocking1.8b4?

Updated

12 years ago
Flags: blocking1.8b4? → blocking1.8b4-
*** Bug 301335 has been marked as a duplicate of this bug. ***

Comment 30

12 years ago
Created attachment 190890 [details] [diff] [review]
patch for marker's position

I try to fix one of this problems, that is the position of the marker box on
rtl direction. In changes, the distance from the marker box is able to be
calculated without using computed left margin as follows.

x = rs.mComputedWidth		     <-- content width
  + reflowState.mComputedMargin.left
  + rs.mComputedBorderPadding.left   <-- li_pL
  + rs.mComputedBorderPadding.right  <-- li_pR

 <-----------------aAvailWidth------------------>
   li_mL   li_pL		 li_pR	  li_mR
 <------><-------><--content---><-------><------>
	/\				/\ x-position of the marker 
	if x is zero, here is marker.	if the direction is RTL.

Updated

12 years ago
Attachment #171514 - Attachment is obsolete: true
Attachment #190890 - Flags: review?(bzbarsky)
So why is that change correct?

Comment 32

12 years ago
Created attachment 191005 [details]
testcase for list marker

Comment 33

12 years ago
Created attachment 191006 [details]
screen shot for list marker

Comment 34

12 years ago
(In reply to comment #31)
> So why is that change correct?

This problem issues if list-style-position property is outside.
There is a comment at nsBlockFrame::ReflowBullet as follows.

             // According to the CSS2 spec, section 12.6.1, outside marker box
             // is distanced from the associated principal box's border edge.
             // |rs.availableWidth| reflects exactly a border edge: it includes
             // border, padding, and content area, without margins.

However, |rs.availableWidth| includes margings. I try to calculate the distance
from the left border edge (that is a blue box on screen shot of attachment 191006 [details]).
So does this also break if the list-item has a non-auto width?

Comment 36

12 years ago
Created attachment 191010 [details] [diff] [review]
patch for x origin

I think that it is not correct for x origin to add |mSpace.x| and
|mMargin.left| if rtl direction, since both |mSpace.x| and |mMargin.left|
include floaded object's width. The computed margins are calculated at
nsHTMLReflowState::CalculateBlockSideMargins. I try to recalculate the left
margin in order to remove the floated width.
Attachment #191010 - Flags: review?(bzbarsky)

Comment 37

12 years ago
(In reply to comment #35)
> So does this also break if the list-item has a non-auto width?

Yes, the width is specified in whichever <div.rtl> and <li.rtl>, the marker goes
out.
Version: Trunk → 1.0 Branch
Again, it's not obvious to me why this patch is right (if only because I'm not
fully familiar with the code).  Please put clear comments explaining why it's
the right thing to do with any non-obvious code you write in this file, please?

Comment 39

12 years ago
(In reply to comment #38)
> Again, it's not obvious to me why this patch is right (if only because I'm not
> fully familiar with the code).  Please put clear comments explaining why it's
> the right thing to do with any non-obvious code you write in this file, please?

My basic idea for this problem is that the pages should be displayed
symmetrically in the rtl and ltr directions.

There is a origin's x-coordinate on a left border edge in the both case of ltr
and ltr directions. In the rtl direction, the distance from marker box is
calculated from adding 'content width' and 'left and right borderpadding'. I
think that 'content width' is equel to |rs.mComputedWidth| and
|reflowState.mComputedMargin.left| offsets the marker to right. Is this
explanation still non-clear?
> I think that 'content width' is equel to |rs.mComputedWidth|

Yes.

> Is this explanation still non-clear?

That's much better.  Put that in the patch, perhaps?
Comment on attachment 191010 [details] [diff] [review]
patch for x origin

>diff -p8 -Naur ./layout/generic/nsBlockReflowContext.cpp.org 
>+    nscoord leftMargin = mMargin.left;

Why init it here?  Why not just have an else clause you set it to mMargin.left
in?

>+    if (NS_STYLE_DIRECTION_RTL == aFrameRS.mStyleVisibility->mDirection &&
>+        NS_UNCONSTRAINEDSIZE != aFrameRS.availableWidth &&
>+        NS_UNCONSTRAINEDSIZE != aFrameRS.mComputedWidth &&
>+        0 != aFrameRS.mComputedWidth) {

Why this last check?  Why shouldn't the bullet on a <li style="width: 0"> do
the right thing?

How does this affect rtl nodes that do not have -moz-float-edge set?  Will this
do the right thing?  Did you test?
Attachment #191010 - Flags: review?(bzbarsky) → review-
Comment on attachment 190890 [details] [diff] [review]
patch for marker's position

>diff -p8 -Naur ./layout/generic/nsBlockFrame.cpp2 
>              // border, padding, and content area, without margins.
>-             ? rs.availableWidth + reflowState.mComputedMargin.left :
>+             ? rs.mComputedWidth + reflowState.mComputedMargin.left +
>+               rs.mComputedBorderPadding.left +
>+               rs.mComputedBorderPadding.right :

So isn't that the same as rs.availableWidth - rs.mComputedMargin.right?

If not, why not?  If so, why not just use that?
Attachment #190890 - Flags: review?(bzbarsky) → review-
*** Bug 318349 has been marked as a duplicate of this bug. ***

Comment 44

12 years ago
Created attachment 206199 [details]
Another testcase, this time with a right float

Another testcase for this bug, this time with an image floated to the right of an RTL list.
Notice how the text wrappes properly, but the bullets don't
For the record, attachment 206199 [details] is also fixed by attachment 191010 [details] [diff] [review].
adding testcase
http://he.wikipedia.org/wiki/user:Gangleri/bugzilla/00033/link_1

this bug is identical to
https://bugzilla.mozilla.org/show_bug.cgi?id=262195
== [bug MediaZilla 262195]: list items extremely outdent when left floating object exists

best regards reinhardt [[user:gangleri]]
(In reply to comment #44)
> Created an attachment (id=206199) [edit]
> Another testcase, this time with a right float
> 
> Another testcase for this bug, this time with an image floated to the right of
> an RTL list.
> Notice how the text wrappes properly, but the bullets don't

Hallo!
attachment id=206199 works fine in IE

This is all new for me but I am chasing errors related to "non-textual entities" in MediaWiki. See 179393 comment 11.

I understand that the bullets in attachment id=206199 are "non-textual entities". Others are imags, radio buttons, editboxes, checkboxes etc.
How does the complete list looks like?

There are some differences between Firefox and IE about BiDi rendering / displaying these entities. A typical example is
http://he.wikipedia.org/w/index.php?title=Special:Search&search=%D7%90%D7%90%D7%90&fulltext=%D7%97%D7%A4%D7%A9
please note that IE displays the space between the checkboxes and the text right to them but Firefox does not.
Is there already a report (bug) about this? Who is correct?
Is there a tracking bug about BiDi and "non-textual entities" 
I can provide a large amount of examples. For some I have seen or implemented myself some workarounds.

A workaround to solve the problem with checkboxes can be seen at
http://yi.wiktionary.org/wiki/MediaWiki:Minoredit?action=edit
containing HTML entities of the Unicode characters:
&nbsp;&rlm;This is a minor edit&nbsp;
However in order to translate the UI to RTL languages some messages can be encoded only as Unicode
http://yi.wiktionary.org/wiki/MediaWiki:Nextdiff?action=edit
containing
Next diff &#8592;
and
http://yi.wiktionary.org/wiki/MediaWiki:Previousdiff?action=edit
containing
&#8234;Previous diff &#8594;&#8236;


Regarding
http://he.wikipedia.org/w/index.php?title=Special:Search&search=%D7%90%D7%90%D7%90&fulltext=%D7%97%D7%A4%D7%A9
please see that the textbox in Firefox displays only *two* alephs but IE displays *three*. Last (three) is the proper value encoded in the php parameters.
Is there already a report (bug) about this?

On the long term I search the proper configuration for
http://test.leuksman.com/index.php?title=714&oldid=10715
would be happy for any feedback. Thanks in advance!

best regards reinhardt [[user:gangleri]]
(In reply to comment #47)

> This is all new for me but I am chasing errors related to "non-textual
> entities" in MediaWiki. See 179393 comment 11.

See bug 179393 comment 11

> I understand that the bullets in attachment id=206199 are "non-textual
> entities". Others are imags, radio buttons, editboxes, checkboxes etc.
> How does the complete list looks like?

Do tabs belong to this list?
See the long links at
http://bugzilla.wikimedia.org/show_bug.cgi?id=4102#c5
[bug MediaZilla 04102] BiDi: Mozilla Firefox and Netscape can not display enough space between tabs if LTR / RTL properties of content language and selected user interface differ
Would be happy to know what is wrong in the page source at
http://test.wikipedia.jp/w/index.php?title=%E5%88%A9%E7%94%A8%E8%80%85:Gangleri&oldid=25532&uselang=he

Comment 49

12 years ago
another live example: the AdSense frame thrughs the list to on to the navbar:
http://www.seoisrael.co.il/seo-information-sources.asp

Comment 50

12 years ago
Created attachment 206510 [details] [diff] [review]
patch

Again, I try to calculate correct computed margins.

As to changes for CalculateBlockSideMargins, I think that margins are calculated using availableWidth of the frame, but not mComputedWidth of the parent, since mComputedWidth of the parent includes floating objects, and sum of border, padding, computed margins and content area is equal to the availableWidth.

As to changes for nsBlockFrame::ReflowBullet, x-coordinate is calculated as follows, since availableWidth includes border, padding, margins and content area.

availableWidth - mComputedMargin.left - mComputedMargin.right + ...
Attachment #190890 - Attachment is obsolete: true
Attachment #191010 - Attachment is obsolete: true
Attachment #206510 - Flags: review?(bzbarsky)
I won't be able to look at this for at least two weeks, possibly longer.  Even then, sorting through this patch will take me a lot of time (I see nothing obviously incorrect now, but I can't tell whether it's right).  You may want to try getting review from David instead...

Comment 52

12 years ago
Comment on attachment 206510 [details] [diff] [review]
patch

David, could you review this patch?

When the left margin(if direction is rtl) or the right margin(if direction is ltr) becomes auto, I think that the margins are calculated from availableWidth of the frame.
Attachment #206510 - Flags: superreview?(dbaron)
Attachment #206510 - Flags: review?(dbaron)
Attachment #206510 - Flags: review?(bzbarsky)

Updated

12 years ago
Blocks: 137995
Comment on attachment 206510 [details] [diff] [review]
patch

>+++ ./layout/generic/nsBlockFrame.cpp	Thu Dec 22 00:25:12 2005
>@@ -7168,18 +7168,19 @@ nsBlockFrame::ReflowBullet(nsBlockReflow
>   // from the rest of the frames in the line
>   nscoord x = 
> #ifdef IBMBIDI
>            (rs.availableWidth != NS_UNCONSTRAINEDSIZE &&
>             NS_STYLE_DIRECTION_RTL == GetStyleVisibility()->mDirection)
>              // According to the CSS2 spec, section 12.6.1, outside marker box
>              // is distanced from the associated principal box's border edge.
>              // |rs.availableWidth| reflects exactly a border edge: it includes
>-             // border, padding, and content area, without margins.
>-             ? rs.availableWidth + reflowState.mComputedMargin.left :
>+             // border, padding, margins and content area.
>+             ? rs.availableWidth + reflowState.mComputedMargin.left -
>+               rs.mComputedMargin.left - rs.mComputedMargin.right :
> #endif
>              - reflowState.mComputedMargin.right - aMetrics.width;

This change is pretty clearly wrong based on the documentation in nsHTMLReflowState.h.  Do you have evidence that that comment is wrong?  What?  Also, you only fixed half the comment.
FWIW, I'd think this bug would be most likely to be fixed in nsBlockReflowState::ComputeBlockAvailSpace.
Hmm.  It seems to me that the comment in nsHTMLReflowState.h is wrong.
...although probably the most important caller, nsBlockReflowState's constructor, assumes that it's correct.
Then again, the inconsistency could be the reason nsBlockFrame::AlignBlockHorizontally does work more often than it ought to.

Comment 58

12 years ago
> Do you have evidence that that comment is wrong? 

The container block represents the amount of room for the frame's border, padding, margins and content area. The width of the content area is equel to the computed width, and the width of the container block is equel to the available width (that is, |mComputedWidth| of |mReflowState| is equel to |availableWidth| of child's |mReflowState|). I think that the available width includs the margins.
So what would help me review this is if I could figure out where we implement block horizontal margins, i.e., where the code is that:
 * reduces the widths, and
 * moves the block horizontally.
I actually couldn't find the code to do the former when I tried to briefly a few days ago, and I didn't yet look for the latter.

Though I still think comment 54 may be correct.
(In reply to comment #59)
>  * moves the block horizontally.

Er, I know where that is (nsBlockReflowContext::ReflowBlock, using the output of nsBlockReflowContext::AlignBlockHorizontally).  So the only question is where the code that reduces available widths to account for margins lives.
Status update:

The original testcase (attachment 160575 [details]), as well as "another test case" (attachment 185598 [details]) were fixed by the fix to bug 192767 (or one of the other bugs which were fixed at the same time).

Testcase #2 (attachment 169516 [details]) and "testcase for list marker" (attachment 191005 [details]), which are both only about wrongly-placed list markers, are still broken as they were.

"Another testcase, this time with a right float" (attachment 206199 [details]) has changed behaviour: the list markers now appear correctly, but the actual text is shifted too much to the left.

I would suggest resolving this bug as FIXED (since the issue in the original report is fixed), and submitting separate bugs for the remaining issues (which do not necessarily have anything to do with left floated objects).

Updated

12 years ago
Attachment #206510 - Attachment is obsolete: true
Attachment #206510 - Flags: superreview?(dbaron)
Attachment #206510 - Flags: review?(dbaron)
I filed bug 332975 for the "incorrectly-positioned list markers with left-margin" issue, and bug 332798 for the "over-indentation with right floats" issue.

I'm marking this bug FIXED (by the fixes for bug 192767 / bug 96394). 
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9alpha
(In reply to comment #62)
> bug 332798 for the "over-indentation with right floats"

Should be: bug 332978.

Sorry for the spam.

Comment 64

11 years ago
(In reply to comment #61)
> Status update:
> 
> The original testcase (attachment 160575 [details]), as well as "another test case"
> (attachment 185598 [details]) were fixed by the fix to bug 192767 (or one of the other
> bugs which were fixed at the same time).

Really? Check again "another test case" https://bugzilla.mozilla.org/attachment.cgi?id=185598

This bug is NOT fixed.

A site that breaks because of this bug:
http://www.beofen-tv.co.il/cgi-bin/chiq.pl?%EE%E4_%E7%E3%F9
What version are you testing in?

Comment 66

11 years ago
Tested with Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.2) Gecko/20070219 Firefox/2.0.0.2
It's not supposed to be fixed in that version.  It was checked in to the trunk on March 21, 2006, but Firefox 2.0.0.2 is based on a branch from August 12, 2005.

Updated

10 years ago
Duplicate of this bug: 394654

Comment 69

10 years ago
Since I am still getting this bug with Firefox 2.0.0.6 (the latest version), I assume that again the problem is that FF has an old version of the core. Is there any way I can get FF to work with a newer core? This is a very irritating bug!

Comment 70

10 years ago
Please try to elaborate, which version of firefox should have this bug fixed?





Comment 71

10 years ago
I get this bug with:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6
which, as far as I know, is the latest official release.
It's fixed in the 1.9 / Gran Paradiso alpha releases.
Duplicate of this bug: 432139
Duplicate of this bug: 319291

Updated

9 years ago
Duplicate of this bug: 421731

Updated

9 years ago
Component: Layout: BiDi Hebrew & Arabic → Layout: Text
QA Contact: zach → layout.fonts-and-text

Comment 76

a year ago
here example: the AdSense frame thrughs the list to on to the navbar:
http://taxi-eilat.mimos.co.il/
You need to log in before you can comment on or make changes to this bug.