321799 - Incorrect behaviour dynamically switching CSS property 'direction' from 'ltr' to 'rtl' and vice versa

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Luciano G. Marcon]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8) Gecko/20051111 Firefox/1.5

Dynamically switching by JavaScript the CSS property ' direction' of a containing box from 'ltr' to 'rtl' and vice versa does not affect the position of the image contained in the box. The containing box (<div></div> tag)has the following CSS properties: {position: absolute; overflow: auto; direction: ltr;...}.
The problem has been detected with the italian version 1.5 and was not present in the previous 1.0.7
See explanatory example at http://valloalpino.altervista.org/bunker/mncs/rvs/rvs5-000.htm 
See steps to reproduce for details.

Reproducible: Always

Steps to Reproduce:
1. Go to web page (see above)
2. Click on the right or left grey arrows that appears alternately beside the caption under the map.
3.

Actual Results:  
The grey arrows swap but the map doesn't move.

Expected Results:  
The grey arrows swap and the map moves inside the windows showing its right or left side.

The web page is compliant with XHTML 1.0 Transitional and works properly with the following browsers:
FF 1.0.7 (Win XP and Linux)
IE 6.0.x (Win XP)
NN 8.0.4 based on Firefox (Win XP)
Opera 8.5 (Win XP and Mac)
Safari (Mac)
The only incorrect behaviour presently known is wit FF 1.5
The web page has been tested by different persons and different systems. See discussion at http://forum.mozillaitalia.org/index.php?topic=15734.0

Comment 1

[Phil Ringnalda (:philor)]

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

Comment 2

[Ria Klaassen (not reading all bugmail)]

This changed between 1.8b2_2005042806 and 1.8b2_2005042906.

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-04-28+05%3A00%3A00&maxdate=2005-04-29+06%3A00%3A00&cvsroot=%2Fcvsroot

Comment 3

[Thomas Andrews]

Smaller example:

  http://www.thomasoandrews.com/examples/mozilla/321799/

Click on the 'Right' link and it should scroll to the right in the div. Then 'Left' should bring you back.

Comment 4

[Luciano G. Marcon]

(In reply to comment #3)
> Smaller example:
> 
>   http://www.thomasoandrews.com/examples/mozilla/321799/
> 
> Click on the 'Right' link and it should scroll to the right in the div. Then
> 'Left' should bring you back.
> 
There is a small difference between the smaller example and the original one: in the smaller it scrolls only by the thickness of the vertical scrollbar, whilst in the original, without vertical scrollbar, it doesn't scroll at all. In both examples the image should move completely to the right and then back to the left.

Other difference: the smaller example does not work with IE 6.0, whilst the original does.

Comment 5

[Thomas Andrews]

Yes, I was trying to create an example which worked in older Firefox versions but didn't work in the latest release.

Specifically, in simplifying the code, I deliberately removed a lot of cross-browser code to make it easier to debug.

Comment 6

[Thomas Andrews]

Okay, I got my example to work in IE.

I'm not sure about your first complaint about my example.  I see there is a vertical scrollbar added to the map <div> on Windows, which Firefox does not add on the Mac for some reason.  When you click 'Left' or 'Right' it does move that scrollbar to the other side, but it is obviously not doing the correct thing with the change.

Comment 7

[Luciano G. Marcon]

(In reply to comment #6)
> Okay, I got my example to work in IE.
> 
> I'm not sure about your first complaint about my example.  I see there is a
> vertical scrollbar added to the map <div> on Windows, which Firefox does not
> add on the Mac for some reason.  When you click 'Left' or 'Right' it does move
> that scrollbar to the other side, but it is obviously not doing the correct
> thing with the change.
> 
Ok, now the behaviour is exactly the same of the original page.
Many thanks for your time.

Comment 8

[:Gavin Sharp [email: [e-mail]]]

It's generally not a good idea to confirm bugs like these without putting them in the right component, and even then, leaving as UNCO is probably best (especially for layout bugs).

Comment 9

[Martijn Wargers (dead)]

Attachment: testcase

Comment 10

[Ria Klaassen (not reading all bugmail)]

(In reply to comment #8)
Yes, I knew. Must have put a tick in the wrong box.

Comment 11

[Boris Zbarsky [:bzbarsky]]

roc, this looks like some sort of reflow over-optimization fallout from bug 240276 to me...

Comment 12

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

FWIW, this is fixed on the trunk but not on the branch.  It would be useful to figure out what fixed it on the trunk.

Comment 13

[Ria Klaassen (not reading all bugmail)]

Something in here:
http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=2006-03-15+03%3A00&maxdate=2006-03-15+22%3A00

Comment 14

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

Probably bug 192767, then.  That's too big to consider for the branch, but we might be able to figure out a small piece of it that would fix this.

Comment 15

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

Actually, now that I look at the testcase more closely, it seems more like bug 318116, which we were not fixing intentionally until bug 192767 was fixed.  So I'm surprised that this is reported as a regression.

Comment 16

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

Presumably the fix means it now scrolls to the right for a different reason than it did before the regression.

Comment 17

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

Attachment: testcase showing why the pre-regression behavior is bad

Comment 18

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

I think the pre-regression behavior is worse than the post-regression behavior, since the behavior with a single large image in the middle of a large chunk of text is really quite bad -- the user might be unaware that there's any text to scroll to.

I don't think we should fix this without taking bug 192767, bug 96394, bug 318116, and all regression fixes from those bugs.  I'm not sure how much that scares people at this point.  (I think there are still some unfixed regressions from those, although they're pretty minor, IIRC.)

Comment 19

[Uri Bernstein]

(In reply to comment #18)
> I don't think we should fix this without taking bug 192767, bug 96394, bug
> 318116, and all regression fixes from those bugs.  I'm not sure how much that
> scares people at this point.  (I think there are still some unfixed regressions
> from those, although they're pretty minor, IIRC.)
> 

Fixing those bugs on the branch will make bidi users very happy (for reasons other than this bug). I've been using trunk builds regularly, and other than the very minor regressions mentioned, I'm not seeing any problems. Still, 192767 was a big patch... so some people might be scared.

Comment 20

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

Minusing for blocking1.8.1 given that we shipped 1.8 with this and it's really a pretty obscure misuse of 'direction'.  It's already fixed on the trunk.

We probably should have considered taking the bugs that fixed this a few months ago for 1.8.1 on their own merits, but I think it's probably a bit late to do that now.

Comment 21

[(no longer active)]

Mass-assigning the new rtl keyword to RTL-related (see bug 349193).