User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030209 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030209 In the soon-to-be-attached testcase, the H1 is mirror-rendered while the p element following it renders fine (see my build ID, of course; this did not use to happen up until a while ago). Reproducible: Always Steps to Reproduce: 1. 2. 3.

This is a regression since 1.2b. I hope I didn't cause it myself with bug 187866, but I wouldn't be surprised if I did.

Yep, reversing http://bugzilla.mozilla.org/attachment.cgi?id=111003&action=view makes this bug go away. Hanging my head, and taking the bug.

Comment on attachment 114282 [details] [diff] [review] Patch I would like to refactor PrepareUnicodeText() a bit and make these manoeuvres unnecessary, but for now this is the fix.

+ PRBool isBidiSystem = PR_FALSE; + PRBool bidiEnabled; + aPresContext->GetBidiEnabled(&bidiEnabled); + if (bidiEnabled) { + aPresContext->GetIsBidiSystem(isBidiSystem); [...] + PRBool isBidiSystem = (eCharType_RightToLeftArabic == charType) ? + (hints & NS_RENDERING_HINT_ARABIC_SHAPING) : + (hints & NS_RENDERING_HINT_BIDI_REORDERING); + aPresContext->SetIsBidiSystem(isBidiSystem); + } Convoluted use of the variable name |isBidiSystem|. Seems that |isBidiSystem| is always false outside the block.

Comment on attachment 114282 [details] [diff] [review] Patch Marking as needs-work.

OK, let's do this the hard way :-) I think this also opens a direction towards a fix for bug 75011.

Comment on attachment 115056 [details] [diff] [review] Patch v.2 + aPresContext->SetIsBidiSystem(PR_TRUE); You don't revert to the native state later on?

No, here in Reflow() is where I determine the native state (for cases where we care). With this patch, once the state is determined it no longer gets overridden and reset. |forceArabicShaping| is used instead. The chief problem with my patch to bug 187866 (attachment 111003 [details] [diff] [review]) was that I added handling for an additional exception to the rule and shoved the handling of the rule into an else clause. This patch goes back to the status quo ante for that code block.

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

rbs, can you please re-review in the light of comment 10?

Comment on attachment 115056 [details] [diff] [review] Patch v.2 I had missed that post in my bugmail. r+sr=rbs

Fix checked in.

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