262195 - list items extremely outdent when left floating object exists

Status: RESOLVED FIXED

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

Description

[Tsahi Asher]

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.

Comment 1

[Tsahi Asher]

Attachment: test case

Comment 2

[Tsahi Asher]

Comment on attachment 160575 [details]
test case

woops, wrong mime..

Comment 3

[Tsahi Asher]

actually, they don't nessesarily outdent the page, but their containing block,
as seen in the URL.

Comment 4

[Tsahi Asher]

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.

Comment 5

[Asaf Romano (gone)]

regressed in bug 74880, probably.

Comment 6

[Uri Bernstein]

*** Bug 244899 has been marked as a duplicate of this bug. ***

Comment 7

[Uri Bernstein]

*** Bug 271561 has been marked as a duplicate of this bug. ***

Comment 8

[Hideo Saito]

Attachment: testcase #2

Comment 9

[Hideo Saito]

Attachment: patch

Comment 10

[Hideo Saito]

Attachment: screen shot for testcase #2

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

Comment 11

[Hideo Saito]

Attachment: patch

Comment 12

[Hideo Saito]

Attachment: screen shot for test case

screen shot by my build with a patch

Comment 13

[Boris Zbarsky [: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....

Comment 14

[Boris Zbarsky [:bzbarsky]]

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

[Hideo Saito]

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;
   }
 }

Comment 16

[Hideo Saito]

Attachment: patch

Comment 17

[Hideo Saito]

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

Comment 18

[Asaf Romano (gone)]

bz wasn't cced (see comment 14 / 17)

Comment 19

[Hillel Taub-Tabib]

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

Comment 20

[Hideo Saito]

Attachment: 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'.

Comment 21

[Boris Zbarsky [: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...

Comment 22

[Hideo Saito]

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.

Comment 23

[Boris Zbarsky [: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 24

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 171514 [details] [diff] [review]
patch

Per comment 23.

Comment 25

[Uri Bernstein]

*** Bug 295713 has been marked as a duplicate of this bug. ***

Comment 26

[Uri Bernstein]

*** Bug 296958 has been marked as a duplicate of this bug. ***

Comment 27

[Nir Soffer]

Attachment: 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.

Comment 28

[Simon Montagu :smontagu]

*** Bug 297704 has been marked as a duplicate of this bug. ***

Comment 29

[Uri Bernstein]

*** Bug 301335 has been marked as a duplicate of this bug. ***

Comment 30

[Hideo Saito]

Attachment: 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.

Comment 31

[Boris Zbarsky [:bzbarsky]]

So why is that change correct?

Comment 32

[Hideo Saito]

Attachment: testcase for list marker

Comment 33

[Hideo Saito]

Attachment: screen shot for list marker

Comment 34

[Hideo Saito]

(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]).

Comment 35

[Boris Zbarsky [:bzbarsky]]

So does this also break if the list-item has a non-auto width?

Comment 36

[Hideo Saito]

Attachment: 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.

Comment 37

[Hideo Saito]

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

Comment 38

[Boris Zbarsky [:bzbarsky]]

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

[Hideo Saito]

(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?

Comment 40

[Boris Zbarsky [:bzbarsky]]

> 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 41

[Boris Zbarsky [:bzbarsky]]

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?

Comment 42

[Boris Zbarsky [:bzbarsky]]

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?

Comment 43

[Simon Montagu :smontagu]

*** Bug 318349 has been marked as a duplicate of this bug. ***

Comment 44

[Shoshannah Forbes]

Attachment: 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

Comment 45

[Simon Montagu :smontagu]

For the record, attachment 206199 [details] is also fixed by attachment 191010 [details] [diff] [review].

Comment 46

[lɛʁi לערי ריינהארט]

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]]

Comment 47

[lɛʁi לערי ריינהארט]

(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:
 ‏This is a minor edit 
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 ←
and
http://yi.wiktionary.org/wiki/MediaWiki:Previousdiff?action=edit
containing
‪Previous diff →‬


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]]

Comment 48

[lɛʁi לערי ריינהארט]

(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

[Shoshannah Forbes]

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

[Hideo Saito]

Attachment: 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 + ...

Comment 51

[Boris Zbarsky [: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

[Hideo Saito]

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.

Comment 53

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 54

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

FWIW, I'd think this bug would be most likely to be fixed in nsBlockReflowState::ComputeBlockAvailSpace.

Comment 55

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Hmm.  It seems to me that the comment in nsHTMLReflowState.h is wrong.

Comment 56

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

...although probably the most important caller, nsBlockReflowState's constructor, assumes that it's correct.

Comment 57

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Then again, the inconsistency could be the reason nsBlockFrame::AlignBlockHorizontally does work more often than it ought to.

Comment 58

[Hideo Saito]

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

Comment 59

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 60

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 61

[Uri Bernstein]

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

Comment 62

[Uri Bernstein]

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

Comment 63

[Uri Bernstein]

(In reply to comment #62)
> bug 332798 for the "over-indentation with right floats"

Should be: bug 332978.

Sorry for the spam.

Comment 64

[Nir Soffer]

(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

Comment 65

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

What version are you testing in?

Comment 66

[Nir Soffer]

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

Comment 67

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 69

[Zvika Ben-Haim]

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

[Udi Oron]

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

Comment 71

[Zvika Ben-Haim]

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.

Comment 72

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

It's fixed in the 1.9 / Gran Paradiso alpha releases.

Comment 76

[pazit dabush]

here example: the AdSense frame thrughs the list to on to the navbar:
http://taxi-eilat.mimos.co.il/