In the editor, choose Format -> Apply Style Sheet -> Oldstyle (or one of the other W3C style sheets at the bottom of the submenu. On Mac, it asserts "No response" in nsHTTPChannel::OpenInputStream(), then crashes the machine hard. On Linux, a different crash happens. This all worked fine in the old netlib.
On Linux (RH6.0), I also see a crash, but the stack trace is a little different: #0 0x4033aac9 in ConverterInputStream::ConverterInputStream (this=0x86817d0, aStream=0x40a16a2c, aConverter=0x884ccf0, aBufferSize=0) at nsUnicharInputStream.cpp:189 #1 0x4033b100 in NS_NewConverterStream (aInstancePtrResult=0xbfffd34c, aOuter=0x0, aStreamToWrap=0x40a16a2c, aBufferSize=0, aCharSet=0x0) at nsUnicharInputStream.cpp:312 #2 0x40f66485 in CSSLoaderImpl::LoadAgentSheet (this=0x8579fc8, aURL=0x884cfe0, aSheet=@0xbfffd3ac, aCompleted=@0xbfffd3a8, aCallback=0x41dae168 <nsHTMLEditor::ApplyStyleSheetToPresShellDocument(nsICSSStyleSheet *, void *)>, aData=0x86153a0) at nsCSSLoader.cpp:1308 #3 0x41dab2f5 in nsHTMLEditor::ApplyStyleSheet (this=0x86153a0, aURL=@0xbfffd408) at nsHTMLEditor.cpp:2586
Simon, do we need this for M9
This should be release-noted for M9.
K, I added it to bug 11352, RN tracker
Moving Assignee from gagan to warren since he is away.
I can't get anything to happen when I try to apply a style sheet. Is this still hooked up? Note that we are still waiting on OpenInputStream to be implemented (however that may affect this bug). Reassigning back to Simon for reevaluation.
Status: NEW → ASSIGNED
Summary: Crash loading remote stylesheet in editor → Loading remote stylesheet in editor fails
This is not a crash, just a failure. Fixing summary.
Yes, this is failing because CSSLoaderImpl::LoadAgentSheet() calls NS_OpenURI(nsIInputStream **...) which calls nsHTTPChannel::OpenInputStream() which is not implemented. Marking dependent on 18434, moving out.
Bulk move of all Necko (to be deleted component) bugs to new Networking component.
*** Bug 21941 has been marked as a duplicate of this bug. ***
From Pierre Saslawsky concerning bug 21941: "It freezes in nsPipe: this is an I/O or a threading issue. I'm going to reassign the bug to the Necko people." Since 21941 was marked a duplicate of this, I'm reassigning to network group. Look at 21941 for more stack info if needed.
Whiteboard: Release note for M9 → Release note for M12
I think the underlying problem is as described in bug 18434; there is some threading badness with nsHTTPChannel::OpenInputStream().
Current protocol implementations of OpenInputStream() require that the returned stream be read on a seperate thread. Current implementations simply call AsyncRead() underneath. Can the editor use AsyncRead() instead?
Editor is not doing the reading, the style system is. Reassigning to pierre.
As described by cmanske in bug 21841, the reading is done somewhere way underneath the style system. The stack shows: nsCSSScanner::Read(int&) ConverterInputStream::Read(unsigned short*,unsigned int,unsigned int,unsigned int*) ConverterInputStream::Fill(unsigned int*) ByteBufferImpl::Fill(unsigned int*,nsIInputStream*,unsigned int) nsPipe::nsPipeInputStream::Read(char*,unsigned int,unsigned int*) nsPipe::nsPipeInputStream::Fill() Then it freezes in nsAutoCMonitor::Wait(). None of these objects implements AsyncRead(). I hate to do that but I have to reassign to Valeski again.
So who's initiating the load? Whoever is doing that needs to use AsyncRead() instead. OpenInputStream() blocks, we can't block the main thread. I"m not sure what you meain by "none of htese objects implements asyncread", all the network protocols do.
The load is initiated in CSSLoaderImpl::LoadAgentSheet() (as pointed out above). The CSS loader should be changed to read data asyncronously, and the unichar stream converter should implement the nsIStreamConverter interface to handle the async data conversion. Is this code called in the browser? If so this is probably a thread blocker (thus time sink).
I'm afraid it works that way by design: the agent sheet must be loaded synchronously. What can we do to make it work without blocking the thread forever?
FYI : This function works for me with a local stylesheet, but only once. Trying it a second time fails, but with no errors returned or no crashes.
By definition, synchronous == blocking, which is a bad thing in a GUI app. We're investigating a re-write of the OpenInputStream calls on the necko side. It's a big and lengthy change though. I'll take a look at re-writing the CSS agent stuff, and accompanying converter, to do the right thing.
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → WONTFIX
blocking reads are illegal on the UI thread. I don't have time to rework the reader to go async.
how come we're not gonna fix this? it freezes the editor...
pierre will have to fix stylesheet loading to be async.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Reassign to pierre
Assignee: valeski → pierre
Status: REOPENED → NEW
Taking over 1/3 of Pierre's NEW bugs to help reduce his doomage factor
Assignee: pierre → attinasi
Reassigned back to me these bugs that shouldn't have left my list.
Assignee: attinasi → pierre
Fix checked in nsCSSLoader.cpp. The command has been re-enabled in editorOverlay.xul. The editor folks will be happy again: it's quite fun to play with that command. I'm sorry it was broken for so long. FYI, I opened two related bugs: bug 32069 and bug 32070.
Status: NEW → RESOLVED
Last Resolved: 19 years ago → 19 years ago
Resolution: --- → FIXED
qa to sujay
QA Contact: paulmac → sujay
verified in 7/25 build
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.