Bug 190205

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.