41685 - [BiDi] Infinite loop in compose new message

Status: RESOLVED WORKSFORME

(SeaMonkey :: MailNews: Message Display, defect, P3)

Description

[Franck Portaneri]

When the pref user_pref("browser.display.direction", 1) is set in the prefs.js, 
the Compose New message window does an infinite loop (and crashes on Linux). 

Everything is OK when user_pref("browser.display.direction", 0) is set.

This can be seen on Solaris and Linux platforms for M16 version.

Comment 1

[lchiang]

What does this browser preference do?  What is the default setting for this 
preference?

Comment 2

[scottputterman]

reassigning to ducarroz.

Comment 3

[Franck Portaneri]

This preference is set to 1 for BIDI and Right-To-Left languages support 
(such as Arabic, Hebrew...). However the default setting is 0.

Comment 4

[Jean-Francois Ducarroz]

do you have a stack trace?

Comment 5

[Franck Portaneri]

When user_pref("browser.display.direction", 1) is set and you run
./mozilla -mail
the mail interface comes up in RTL mode (which is correct), but 
when you click on the "New Msg" button, the following trace appears:

....
nsWidget::~nsWidget() of toplevel: 16 widgets still exist.
ComposeMessage folder=null

ComposeMessage from XUL: null
WEBSHELL+ = 5
WEBSHELL+ = 6
[@0x8d1dd7c] RootBox(-1) ###!!! ASSERTION: Infinite loop! Someone won't stop
growing!!: 'passes < 10', file nsStackLayout.cpp, line 261
###!!! Break: at file nsStackLayout.cpp, line 261
[@0x8d1dd7c] RootBox(-1) ###!!! ASSERTION: Infinite loop! Someone won't stop
growing!!: 'passes < 10', file nsStackLayout.cpp, line 261
###!!! Break: at file nsStackLayout.cpp, line 261
[@0x8d1dd7c] RootBox(-1) ###!!! ASSERTION: Infinite loop! Someone won't stop
growing!!: 'passes < 10', file nsStackLayout.cpp, line 261
###!!! Break: at file nsStackLayout.cpp, line 261
[@0x8d1dd7c] RootBox(-1) ###!!! ASSERTION: Infinite loop! Someone won't stop
growing!!: 'passes < 10', file nsStackLayout.cpp, line 261    
.....
                                                                                           

Comment 6

[scottputterman]

cc'ing ftang on the bug. Frank, does this need to be fixed for rtm.  Are 
we supporting any of the languages that require the pref to be set to 1?

Comment 7

[scottputterman]

Frank, do you know the answer to my previous question. We're trying to decide 
whether or not to future this bug.

Comment 8

[scottputterman]

moving to future milestone.  ftang this is incorrect, please reopen.

Comment 9

[Håkan Waara]

I don't understand that code enough to know what the problem is. But I really
think that this case should be investigated more..

Comment 10

[scottputterman]

Frank or Naoki, do we have plans to support BIDI in the near future and if so,
does this bug still occur?

Comment 11

[Mike Kaply (PTO until 9/30) [:mkaply]]

I'm going to take ownership of this since it is a Bidi problem and I will check 
it against the current Bidi builds.

Comment 12

[msanz]

changing QA to andreasb until we have someone in charge of bidi testing

Comment 13

[Mike Kaply (PTO until 9/30) [:mkaply]]

I have removed browser.display.direction now that the official bidi is in and 
on, and as a result, this bug is no longer happening

You can experiment with these prefs:

// ------------------
//  Text Direction
// ------------------
// 1 = directionLTRBidi *
// 2 = directionRTLBidi
pref("bidi.direction", 1);

Do get some of this functionality now. UI is being worked on.

Comment 14

[Andreas Becker]

Changing QA contact to [e-mail].