775687 - Firefox 14.0.1 does not display css correctly (display:inline, direction:rtl)

Status: RESOLVED FIXED

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

Description

[I. Garzon]

Attachment: Two test cases of the rendering bug when "display: inline;" and direction set to rtl.

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20100101 Firefox/14.0.1
Build ID: 20120713134347

Steps to reproduce:

Firefox does not display css correctly when the body direction set to rtl (right to left) and the element's "display" property is set to "inline". It sets the direction of the element's anchor as if it was ltr (left to right) on every element's innerHtml change caused by a odd occurrence of an onClick event on the element (Test Case 1. Click on "Click Me" and then on then on the line that will be shown there instead of "Click Me").
The same problem becomes even more incoherent in Test Case 2. It seems like the two elements are affecting each other randomly.



Actual results:

The element should be rendered in RTL direction.


Expected results:

Firefox sets the anchor element order to LTR in a innerHtml change caused by onClick event.

Comment 1

[I. Garzon]

Sorry, I accidentally wrote the "Expected Results" in "Actual Results" and the "Actual Results" in "Expected Results".

Comment 2

[Loic]

Mozregression range:

m-c
good=2012-03-20
bad=2012-03-21
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b972b89518c3&tochange=4bdae514b9be

m-i
good=2012-03-19
bad=2012-03-20
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=6dd5b6014511&tochange=46c5015550af

Suspected bug:
Simon Montagu — Add a mParagraphDepth member to BidiParagraphData and cache it on frames to track nested bidi-isolated paragraphs. Use mParagraphDepth (* 2 + isRTL in order to keep LTR even and RTL odd) as the initial paragraph embedding level instead of pushing a stack of embedding codes. Pass the <bdi> frame instead of its first-child to BidiParagraphData::Reset and save a call to GetParent(). Split inline ancestors before and after bidi-isolated paragraphs, in the same way that we currently do between runs in different directions. This required also adding code to SplitInlineAncestors to handle situations where the parent frame is being split before its first child or after its last child. In JoinInlineAncestors, prevent frames that belong to paragraphs isolated from one another from being rejoined. Bug 712600, r=ehsan, roc

Comment 3

[Loic]

I tried with FF17, same result as FF14.

Comment 4

[Alice0775 White]

There are 2 regression.
#1: TestCase1 and Testcase2
It sets the direction of the element's anchor as if it was ltr (left to right) on every element's innerHtml change caused by a odd occurrence of an onClick event on the element 

#2: Testcase2
The same problem becomes even more incoherent in Test Case 2. It seems like the two elements are affecting each other randomly.


#1 Regression window
Good:
http://hg.mozilla.org/integration/mozilla-inbound/rev/b3e48b6d942b
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120319 Firefox/14.0a1 ID:20120319155237
Bad:
http://hg.mozilla.org/integration/mozilla-inbound/rev/fb2cb3d55cb4
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120319 Firefox/14.0a1 ID:20120319162341
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=b3e48b6d942b&tochange=fb2cb3d55cb4
Suspected: Bug 712600

#2 regression window
Good(but #1 problem exists):
http://hg.mozilla.org/integration/mozilla-inbound/rev/bd849d439d6c
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120321 Firefox/14.0a1 ID:20120321162816
Bad:
http://hg.mozilla.org/integration/mozilla-inbound/rev/9f0ebe3d07ff
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120321 Firefox/14.0a1 ID:20120321165321
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=bd849d439d6c&tochange=9f0ebe3d07ff
Suspected: Bug 730562 or Bug 726460

Comment 5

[Alex Keybl [:akeybl]]

This is the first report we've gotten for a longstanding issue. If a low risk fix is found, we'll definitely consider for uplift. No need to track for release.

Comment 6

[I. Garzon]

Tested with Firefox 17 and it's fixed. However, the 4th test of bug 712600 ("Tests from bug 710694") still doesn't render correctly.

Comment 7

[Simon Montagu :smontagu]

I'm fairly sure this was fixed by bug 793233.

Bug 717811 covers the failing "Tests from bug 710694" (which is a typo for "bug 706194")