User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:21.0) Gecko/20100101 Firefox/21.0 (Beta/Release) Build ID: 20130511120803 Steps to reproduce: After updating to Firefox 21 this bug appears. the browser hang when trying to change to any RTL languages (Arabic, Hebrew, Farsi,...) Anyone can head to this webtrees script demo and try to change the language in main view to any RTL language (eg. Arabic, Hebrew, Farsi) and the browser will hang!!! and you have to kill it or wait till the ram is full to see the crash report!. http://installatron.com/webtrees/demo Tested it with many PC, same result if using FF21, NO problem with IE or Chrome!. FF20 had no problem as well. Actual results: Firefox 21.0 hangs (Not responding) every time trying to view/login to RTL page of webtrees. Expected results: just redirect to the correct page!.

Hang confirmed in FF21, but not in FF24 (Nightly). Could you confirm it's fixed in Nightly (see http://nightly.mozilla.org/).

bp-d7590d84-a267-4d32-87c2-da6692130517 Stack using http://benjamin.smedbergs.us/crashfirefox.exe (run crashfirefox.exe to kill the Firefox process and then report the crash (via the crashreporter) so that we can see the stack at the time of the hang)

Fixed window Bad: http://hg.mozilla.org/integration/mozilla-inbound/rev/4e6834c859a8 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20130220 Firefox/22.0 ID:20130220204500 Good: http://hg.mozilla.org/integration/mozilla-inbound/rev/0a9618b1dd2a Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20130220 Firefox/22.0 ID:20130220230357 Fixed pushlog http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=4e6834c859a8&tochange=0a9618b1dd2a I guess Bug 838489 fixes the problem

(In reply to Alice0775 White from comment #2) > bp-d7590d84-a267-4d32-87c2-da6692130517 > Stack using http://benjamin.smedbergs.us/crashfirefox.exe > (run crashfirefox.exe to kill the Firefox process and then report the crash > (via the crashreporter) so that we can see the stack at the time of the hang) I have wait it yesterday till Firefox crash and way I'v done what you asked send a report and this is a copy AdapterDeviceID: 0x0614 AdapterVendorID: 0x10de Add-ons: ar%40dictionaries.addons.mozilla.org:3.1.20110602,undoclosedtabsbutton%40supernova00.biz:3.7.1,%7Bb9db16a4-6edc-47ec-a1f4-b86292ed211d%7D:4.9.14,%7Ba7c6cf7f-112c-4500-a7ea-39801a327e5f%7D:2.0.14,fastdial%40telega.phpnet.us:4.3.3,%7B972ce4c6-7e08-4474-a285-3208198ce6fd%7D:21.0,%7Bd10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d%7D:2.2.4,firebug%40software.joehewitt.com:1.11.3 AvailablePageFile: 3257929728 AvailablePhysicalMemory: 2554785792 AvailableVirtualMemory: 3076259840 BuildID: 20130511120803 CrashTime: 1368797915 EMCheckCompatibility: true FramePoisonBase: 00000000f0de0000 FramePoisonSize: 65536 InstallTime: 1368542160 Notes: AdapterVendorID: 0x10de, AdapterDeviceID: 0x0614, AdapterSubsysID: 34d01458, AdapterDriverVersion: 9.18.13.1422 D2D? D2D+ DWrite? DWrite+ D3D10 Layers? D3D10 Layers+ WebGL? EGL? EGL+ GL Context? GL Context+ WebGL+ ProductID: {ec8030f7-c20a-464f-9b0e-13a3a9e97384} ProductName: Firefox ReleaseChannel: release SecondsSinceLastCrash: 80908 StartupTime: 1368785822 SystemMemoryUsePercentage: 40 Theme: classic/1.0 Throttleable: 1 TotalVirtualMemory: 4294836224 URL: http://www.kufaishi.com/index.php?lang=ar Vendor: Mozilla Version: 21.0 Winsock_LSP: MSAFD Tcpip [TCP/IP] : 2 : 1 : MSAFD Tcpip [UDP/IP] : 2 : 2 : %SystemRoot%\system32\mswsock.dll MSAFD Tcpip [RAW/IP] : 2 : 3 : MSAFD Tcpip [TCP/IPv6] : 2 : 1 : %SystemRoot%\system32\mswsock.dll MSAFD Tcpip [UDP/IPv6] : 2 : 2 : MSAFD Tcpip [RAW/IPv6] : 2 : 3 : %SystemRoot%\system32\mswsock.dll RSVP TCPv6 Service Provider : 2 : 1 : RSVP TCP Service Provider : 2 : 1 : %SystemRoot%\system32\mswsock.dll RSVP UDPv6 Service Provider : 2 : 2 : RSVP UDP Service Provider : 2 : 2 : %SystemRoot%\system32\mswsock.dll This report also contains technical information about the state of the application when it crashed.

If Firefox crashed, type about:crashes in URL bar then provide a crash link (bp-...).

(In reply to Loic from comment #5) > If Firefox crashed, type about:crashes in URL bar then provide a crash link > (bp-...). Thanks for explaining her u go https://crash-stats.mozilla.com/report/index/d34819bc-2a6a-4c92-bb5f-c8ead2130517

markup around user-generated content..... https://support.mozilla.org/en-US/questions/959614

Simon, can you please take a look?

I can confirm that this would be fixed on ff21 by porting the patch for bug 839886, but is there any chance that we would do that?

Minimal testcase for the hang: data:text/html;charset=utf-8,<input type="search" placeholder="חפש" dir="auto"> The bug is somewhere in handling of placeholder text in a input field with dir="auto", and as I said in the previous comment it was fixed by bug 839886. Until the fix is released in firefox 22, it will be possible to workaround by removing the dir="auto" from the input field.

(In reply to Simon Montagu :smontagu from comment #9) > I can confirm that this would be fixed on ff21 by porting the patch for bug > 839886, but is there any chance that we would do that? I assume it depends on how widespread in the Web the use of dir="auto" is.

Simon, can you help understand how widespread the issue may be ? DirAuto is a Fx21 feature and has been on the trains for a while now and we have not seen this before. Hence wanted to get a sense of how common is this testcase or scenario in real world websites ? Can't this wait to be fixed in Fx22 or use the workaround you mentioned in comment 10 ?

I personally wouldn't expect dir=auto be widely used just yet...

I don't have any evidence, but I also don't think dir=auto is widespread yet at all, and since as far as we know the issue is only triggered with input fields with placeholders, that will make it even rarer.

So should we mark this as a dupe of bug 839886 and move on?