Bugzilla – Bug 190205
firefox crashes in libeditor with typo3's rich text editor
Last modified: 2006-11-24 18:36:04 UTC
I updated my SULI 10.1 with YOU to firefox 1.5.0.4. With this latest update it is not possible to use the rich text editor in TYPO3 backend. I downloaded firefox 1.5.0.4 from mozilla.org, and this version works on SULI 10.1. I also tested the browsers on SLES9 and SULI 10.0 without problem. So the problem is only with the SuSE version of firefox 1.5.0.4 on 10.1.
I can confirm this :-( Typo3 only shows "loading editor", but nothing happens. BTW: The Editor used by Typo3 is HTMLarea Versions: Typo3 3.8.1 + rtehtmlarea 1.0.1 Typo3 extension I could not reproduce the problem using any "htmlarea demo" found with Google, so this seems to happen only inside Typo3. I'm 100% sure this worked with RC3 and 99.99% sure it worked with 10.1 final also. Upgrading to critical because this is a regression caused by the YOU update.
Where can I test this? Not knowing Typo3 ... can you reproduce the bug without an extension installed?
(In reply to comment #2) > Not knowing Typo3 ... can you reproduce the bug without an extension > installed? I just created a fresh user "suse101" (including a fresh Firefox configuration) and could reproduce the problem... (In reply to comment #1) > I'm [...] 99.99% sure it worked with 10.1 final I just verified this by downgrading to MozillaFirefox-1.5.0.3-7.i586.rpm from the 10.1 retail DVD - the rich text editor works again. -> please add 0.01% to the above number ;-) About the permissions of this bug: I understand Andreas restricted access because of the login data - but I would prefer to have this bug public. Robert, can you please mark comment #3 as private and then remove the "susebeta" restriction?
I got another report today with a SEGFAULT when loading the typo3 rich-text editor. But that went away when using the latest Firefox package (not released yet but checked in for SLED). The rich text editor worked afterwards w/o problems. I don't expect a change for your problem though but I want to verify it. So I've uploaded the latest packages to ftp://ftp.suse.com/pub/projects/mozilla/experimental/firefox
Is it still uploading, or is it the wrong url? lftp ftp.suse.com:/pub/projects/mozilla/experimental/firefox> ls -la drwxr-xr-x 2 ftp ftp 4096 Apr 12 09:27 . drwxr-xr-x 8 ftp ftp 4096 Jan 09 05:42 .. lftp ftp.suse.com:/pub/projects/mozilla/experimental/firefox>
It's on our staging server (maybe Eberhardt has it faster than ftp.suse.com ;-)) It will appear there.
Ok, I managed to download the packages. With these new packages, the rich text editor works again.
Nice to hear (although I have no clue how the change would have affected this). The only change should be: ------------------------------------------------------------------- Thu Jun 29 20:13:28 CEST 2006 - stark@suse.de - fixed printing crash if the last used printer is not available anymore (#187013)
We will have a next security update end of june. So I think we won't trigger an update right now for this. The packages on the ftp server will of course stay there for that time.
(In reply to comment #10) > We will have a next security update end of june. I hope you mean july :-) > The packages on the ftp server will of course stay > there for that time. Thanks.
(In reply to comment #8) > Ok, I managed to download the packages. > With these new packages, the rich text editor works again. I can confirm this. Whatever you have done - thanks! ;-)
1.5.0.6 updates with this patch released
(In reply to comment #13) > 1.5.0.6 updates with this patch released I just installed the updates. Result: The graphical editor in Typo3 does NOT work again :-( (I did not test with a fresh user account - this didn't make a difference the last time.) rpm -qa --last |head MozillaFirefox-translations-1.5.0.6-1.3 Mi 16 Aug 2006 09:05:37 CEST MozillaFirefox-1.5.0.6-1.3 Mi 16 Aug 2006 09:05:13 CEST gnome-vfs2-2.12.2-58.11 Di 15 Aug 2006 12:48:39 CEST
Yes, same problem after update on my machine.
i can also verify this issue. htmlarea v1.3.7 from typo3 v4.0.1 loads but never displays anything ... htmlarea v0.4.66 from typo3 v3.7.0 makes firefox segfault Maybe helpfull information: when i use the binary firefox 1.5.0.6 tarball from mozilla.com everything works fine on both typo3/htmlarea versions.
Something strange is going on. The update still has the same patches as the testpackage had. Someone able to get a stacktrace (maybe with debuginfo installed) from the segfault?
The core is to big to upload to bugzilla :( I put it in my export. It should show up shortly ~tami/Export/core.6693.bz2 Firefox v1.5.0.6 Typo3 v3.7.0 htmlarea v0.4.66
#0 0xffffe410 in __kernel_vsyscall () #1 0xb7df1661 in raise () from /lib/libpthread.so.0 #2 0x0808c286 in nsProfileLock::FatalSignalHandler (signo=11) at nsProfileLock.cpp:206 #3 <signal handler called> #4 CallQueryInterface<nsDerivedSafe<nsIDOMAbstractView>, nsIDOMViewCSS> (aSource=0x0, aDestination=0xbff5c5b8) at ../../../dist/include/xpcom/nsISupportsUtils.h:225 #5 0x085299c1 in nsHTMLCSSUtils::GetDefaultViewCSS (this=0x9a87018, aNode=0x9a7ea90, aViewCSS=0xbff5c5b8) at nsHTMLCSSUtils.cpp:618 #6 0x08529cc3 in nsHTMLCSSUtils::GetComputedProperty (this=0x9a87018, aNode=0x9a7ea90, aProperty=0x8aa9a20, aValue=@0xbff5c5e8) at nsHTMLCSSUtils.cpp:546 #7 0x084f2194 in MarginPropertyAtomForIndent (aHTMLCSSUtils=0x9a87018, aNode=0x9a7ea90) at nsHTMLEditRules.cpp:935 #8 0x084f5a67 in nsHTMLEditRules::GetIndentState (this=0x9a7e4f0, aCanIndent=0xbff5c7b0, aCanOutdent=0xbff5c7ac) at nsHTMLEditRules.cpp:979 #9 0x084d9d3e in nsHTMLEditor::GetIndentState (this=0x9a894b0, aCanIndent=0xbff5c7b0, aCanOutdent=0xbff5c7ac) at nsHTMLEditor.cpp:2542 #10 0x0853b0ae in nsOutdentCommand::IsCommandEnabled (this=0x9a88e98, aCommandName=0xbff5c9b8 "cmd_outdent", refCon=0x9a894b0, outCmdEnabled=0xbff5c7d4) at nsComposerCommands.cpp:568 #11 0x0853a6fa in nsOutdentCommand::GetCommandStateParams (this=0x9a88e98, aCommandName=0xbff5c9b8 "cmd_outdent", aParams=0x9b44798, refCon=0x9a894b0) at nsComposerCommands.cpp:602 #12 0x084c9514 in nsControllerCommandTable::GetCommandState (this=0x9a8a730, aCommandName=0xbff5c9b8 "cmd_outdent", aParams=0x9b44798, aCommandRefCon=0x9a894b0) at nsControllerCommandTable.cpp:226 #13 0x084c73b0 in nsBaseCommandController::GetCommandStateWithParams (this=0x9a8a6f0, aCommand=0xbff5c9b8 "cmd_outdent", aParams=0x9b44798) at nsBaseCommandController.cpp:196 #14 0x084c84eb in nsCommandManager::GetCommandState (this=0x9a7eb40, aCommandName=0xbff5c9b8 "cmd_outdent", aTargetWindow=0x953bd78, aCommandParams=0x9b44798) at nsCommandManager.cpp:233 #15 0x083588d6 in nsHTMLDocument::QueryCommandState (this=0x95a9510, commandID=@0x9b441c0, _retval=0xbff5cb44) at nsHTMLDocument.cpp:4094 #16 0xb7ef2a19 in XPTC_InvokeByIndex () at ../../../../../../dist/include/xpcom/xptcstubsdef.inc:251 #17 0x080abc28 in XPCWrappedNative::CallMethod (ccx=@0xbff5cc50, mode=XPCWrappedNative::CALL_METHOD) at xpcwrappednative.cpp:2155 #18 0x080aecf6 in XPC_WN_CallMethod (cx=0x98562c8, obj=0x9a4f350, argc=1, argv=0x9b69ed4, vp=0xbff5cd58) at xpcwrappednativejsops.cpp:1445 #19 0xb7f52a79 in js_Invoke (cx=0x98562c8, argc=1, flags=0) at jsinterp.c:1188 #20 0xb7f4dabc in js_Interpret (cx=0x98562c8, pc=0x93b0407 ":", result=0xbff5d048) at jsinterp.c:3583 #21 0xb7f52ad0 in js_Invoke (cx=0x98562c8, argc=0, flags=0) at jsinterp.c:1208 #22 0xb7f4dabc in js_Interpret (cx=0x98562c8, pc=0x9878615 ":", result=0xbff5d2fc) at jsinterp.c:3583 #23 0xb7f52ad0 in js_Invoke (cx=0x98562c8, argc=1, flags=2) at jsinterp.c:1208 #24 0xb7f466e3 in js_InternalInvoke (cx=0x98562c8, obj=0x9091ae0, fval=161807256, flags=2, argc=1, argv=0x9a7f668, rval=0xbff5d4c0) at jsinterp.c:1285 #25 0xb7f22cc3 in JS_CallFunctionValue (cx=0x98562c8, obj=0x9091ae0, fval=161807256, argc=1, argv=0x9a7f668, rval=0xbff5d4c0) at jsapi.c:4177 #26 0x08390e31 in nsJSContext::CallEventHandler (this=0x9850940, aTarget=0x9091ae0, aHandler=0x9a4fb98, argc=1, argv=0x9a7f668, rval=0xbff5d4c0) at nsJSEnvironment.cpp:1411 #27 0x083950dd in nsGlobalWindow::RunTimeout (this=0x94604f0, aTimeout=0x9a7f678) at nsGlobalWindow.cpp:6389 #28 0x0839fcac in nsGlobalWindow::TimerCallback (aTimer=0x9a7f710, aClosure=0x9a7f678) at nsGlobalWindow.cpp:6752 #29 0xb7ee1f2e in nsTimerImpl::Fire (this=0x9a7f710) at nsTimerImpl.cpp:394 #30 0xb7ee1fe2 in handleTimerEvent (event=0xb2500590) at nsTimerImpl.cpp:459 #31 0xb7ede97c in PL_HandleEvent (self=0xb2500590) at plevent.c:688 #32 0xb7edebba in PL_ProcessPendingEvents (self=0x89ed5e8) at plevent.c:623 #33 0xb7edfee6 in nsEventQueueImpl::ProcessPendingEvents (this=0x89f11b0) at nsEventQueue.cpp:417 #34 0x081e6ad4 in event_processor_callback (source=0x8cbc998, condition=G_IO_IN, data=0x0) at nsAppShell.cpp:67 #35 0xb793892d in g_io_channel_unix_get_fd () from /opt/gnome/lib/libglib-2.0.so.0 #36 0xb790fabd in g_main_context_dispatch () from /opt/gnome/lib/libglib-2.0.so.0 #37 0xb7912cbf in g_main_context_check () from /opt/gnome/lib/libglib-2.0.so.0 #38 0xb7913069 in g_main_loop_run () from /opt/gnome/lib/libglib-2.0.so.0 #39 0xb7c1ecd4 in gtk_main () from /opt/gnome/lib/libgtk-x11-2.0.so.0 #40 0x081e6dc8 in nsAppShell::Run (this=0x8c58630) at nsAppShell.cpp:139 #41 0x085ae882 in nsAppStartup::Run (this=0x8c5b688) at nsAppStartup.cpp:150 #42 0x08085440 in XRE_main (argc=1, argv=0xbff5db54, aAppData=0x86c23a0) at nsAppRunner.cpp:2440 #43 0x08081bb7 in main (argc=1, argv=0xbff5db54) at nsBrowserApp.cpp:61 #44 0xb72ee87c in __libc_start_main () from /lib/libc.so.6 #45 0x08081b21 in _start ()
Created attachment 96515 [details] gdb backtrace with debug symbols also the backtrace
OK, seems that a non-debug build crashes (at least it also does for me) while a debug build survives.
And what about the first problem in comment 16: htmlarea v1.3.7 from typo3 v4.0.1 loads but never displays anything
(In reply to comment #25) > And what about the first problem in comment 16: > htmlarea v1.3.7 from typo3 v4.0.1 loads but never displays anything Let's fix the segfault first.
I've uploaded test packages to ftp://ftp.suse.com/pub/projects/mozilla/experimental/firefox/ Please test. For me the package fixes both problems. And BTW it wasn't an error in the SUSE packages. The same problem is in mozilla.com's builds as well. So I guess it was just luck when it worked. NEEDINFO to all
Yes, this package works for me (rich text editor works with Typo3 4.0)
MozillaFirefox-1.5.0.6-1.4.i586.rpm works here as well :-) (Typo3 3.8.1)
yep, works here too :)
https://bugzilla.mozilla.org/show_bug.cgi?id=349726 Will be finally fixed with next update.
*** Bug 202054 has been marked as a duplicate of this bug. ***
Unfortunately I have to reopen this bug :-( At least the problem is more hidden now - Firefox hangs when I click the "source view" ("<>") button in the HTMLarea editor. I started it from a xterm and got this when clicking source view: An error occurred updating the cmd_cut command An error occurred updating the cmd_copy command An error occurred updating the cmd_delete command ###!!! ASSERTION: You can't dereference a NULL nsCOMPtr with operator->().: 'mRawPtr != 0', file ../../../../dist/include/xpcom/nsCOMPtr.h, line 849 Break: at file ../../../../dist/include/xpcom/nsCOMPtr.h, line 849 Program /usr/lib/firefox/firefox-bin (pid = 13544) received signal 11. Stack: Sleeping for 300 seconds. Type 'gdb /usr/lib/firefox/firefox-bin 13544' to attach your debugger to this thread. I bt'ed firefox in gdb and will attach the gdb log in some minutes. I verified that this is really a regression by rpm -Uhv --oldpackage MozillaFirefox-1.5.0.6-1.4.i586.rpm \ MozillaFirefox-translations-1.5.0.6-1.4.i586.rpm where the source view works. xterm error message with 1.5.0.6: An error occurred updating the cmd_cut command An error occurred updating the cmd_copy command An error occurred updating the cmd_delete command WARNING: NS_ENSURE_TRUE(aOwnerDocument) failed, file nsDocumentFragment.cpp, line 170
Created attachment 99505 [details] gdb output and backtrace from MozillaFirefox-1.5.0.7 (sorry, I forgot to mention the version number of the broken package - it's MozillaFirefox-1.5.0.7-1.2.i586 from today's YOU update)
JFYI: wolfgang is no longer in the company, so any reply or fix might take sometime.
The newest YOU-package MozillaFirefox-1.5.0.7-1.5 changes the bahaviour: When switching to source view in Typo3's HTMLarea editor, Firefox crashes immediately, the xterm only shows /usr/bin/firefox: line 160: 11405 Speicherzugriffsfehler LD_PRELOAD=/usr/$LIB/libaoss.so${LD_PRELOAD:+:$LD_PRELOAD} $MOZ_PROGRAM $@
Created attachment 101044 [details] catchsegv firefox
ping ;-) Any news here? BTW: This crash is reproducable with Firefox on Windows also...
Oh, so it's not a problem with our builds, but an upstream problem? If so, can you file an upstream bug and CC robert@ocallahan.org? Detailing which upstream builds work and don't work would be helpful there.
No need to - it was already reported upstream by someone else: https://bugzilla.mozilla.org/show_bug.cgi?id=353473 which is marked as duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=313400 (includes a patch) Needless to say that I'm willing to test the fix if you provide test packages ;-) (10.1/i586 in my case)
OK, so this will be fixed when we push out our 1.8.0.8 security update. Thanks!
I just booted 10.1 (usually working with 10.2 already ;-) to test this and installed MozillaFirefox-1.5.0.8-0.2 which is available via YOU. I can no longer reproduce the crash when switching to source view in Typo3. If the other reporters agree, this bug can be closed as fixed :-)
Yes, it works for me, too.
then lets close this sucker.