Closed Bug 11859 Opened 25 years ago Closed 24 years ago

Loading remote stylesheet in editor fails

Categories

(Core :: Networking, defect, P3)

All
Mac System 8.5
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: sfraser_bugs, Assigned: pierre)

References

Details

(Whiteboard: Release note for M12)

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
Whiteboard: Release note for M9
Target Milestone: M10
This should be release-noted for M9.
K, I added it to bug 11352, RN tracker
Status: NEW → ASSIGNED
Target Milestone: M10 → M12
OpenInputStream is still a big black hole. See bug 10456.

This happens now on linux:

CSSLoaderImpl::LoadAgentSheet: Load of URL
'http://www.w3.org/StyleSheets/Core/Steely' failed.  Error code: 16385
JavaScript Error: uncaught exception: [Exception... "Component returned failure
code: 0x80004001 (NS_ERROR_NOT_IMPLEMENTED) [nsIEditorShell.ApplyStyleSheet]"
nsresult: "0x80004001 (NS_ERROR_NOT_IMPLEMENTED)"  location: "JS frame ::
chrome://editor/content/EditorCommands.js :: EditorApplyStyleSheet :: line 839"
data: no]
Moving Assignee from gagan to warren since he is away.
Assignee: warren → sfraser
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.
Depends on: 18434
Target Milestone: M12 → M13
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. ***
Assignee: sfraser → valeski
Status: ASSIGNED → NEW
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().
cc'ing potts.
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?
Depends on: 22103
No longer depends on: 18434
Assignee: valeski → pierre
Editor is not doing the reading, the style system is. Reassigning to pierre.
Status: NEW → ASSIGNED
Assignee: pierre → valeski
Status: ASSIGNED → NEW
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
Closed: 25 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
Target Milestone: M13 → M14
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
Closed: 25 years ago24 years ago
Resolution: --- → FIXED
qa to sujay
QA Contact: paulmac → sujay
No longer depends on: 22103
verified in 7/25 build
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.