Closed Bug 21941 Opened 25 years ago Closed 25 years ago

[dogfood]Composer: Format|Apply Style Sheet and it freezes

Categories

(Core :: DOM: Editor, defect, P3)

All
Windows NT
defect

Tracking

()

VERIFIED DUPLICATE of bug 11859

People

(Reporter: nbaca, Assigned: pierre)

References

Details

(Whiteboard: [PDT-]RN)

Build 1999121508M12: NT4, Linux/Redhat 6.0, Mac 8.5.1 Overview: In Composer apply a style such as "modernist" or "chocolate" and the application freezes. Steps to reproduce: 1. Open Mail with a POP or IMAP account 2. Select the "New Msg" button and Composer should launch 3. Select the Format menu 4. Select the Apply Style Sheet option 5. Select a style such as "modernist" or "chocolate" Actual Result: The application freezes. Must Ctrl-Alt-Del to End the process and restart to use the application again. Expected Results: The application should not freeze.
Assignee: beppe → cmanske
assigning to cmanske for debugging
Target Milestone: M12
this locks up the entire app, setting to m12
Status: NEW → ASSIGNED
Updating tree and rebuilding now. Will investigate ASAP.
Does anyone see this problem in Web Page Composer as well as Message Composer?
Yes I see it in web page composer also...
Assignee: cmanske → pierre
Blocks: 22072
Status: ASSIGNED → NEW
Summary: Composer: Format|Apply Style Sheet and it freezes → [dogfood]Composer: Format|Apply Style Sheet and it freezes
Question for dogfood/PDT team: While obviously this is not a required "dogfood" feature, should we remove the "Apply Style Sheet" menu item in the M12 release to prevent users from locking up or should we just add a warning to the release notes? This is a hang in the CSS parsing code. It only occurs when the style sheet is not local. The first test style sheet in the editor's "Apply Style Sheet" menu ("Editor Style 1") loads a local file and works OK. The other style sheets in that menu are from the W3C; for example, "modernist" is: http://www.w3.org/StyleSheets/Core/Modernist So it may be a network-related problem. I traced into the following stack: nsCSSScanner::Next(int & 0, nsCSSToken & {...}) line 305 CSSParserImpl::GetToken(int & 0, int 1) line 584 + 25 bytes CSSParserImpl::Parse(CSSParserImpl * const 0x02733590, nsIUnicharInputStream * 0x0276fe50, nsIURI * 0x02787770, nsICSSStyleSheet * & 0x0276e890) line 469 + 14 bytes CSSLoaderImpl::ParseSheet(nsIUnicharInputStream * 0x0276fe50, SheetLoadData * 0x0276d1b0, int & 1, nsICSSStyleSheet * & 0x0276e890) line 767 + 27 bytes CSSLoaderImpl::LoadAgentSheet(CSSLoaderImpl * const 0x02727790, nsIURI * 0x02787770, nsICSSStyleSheet * & 0x0276e890, int & 1, nsICSSLoaderObserver * 0x0273b644) line 1357 + 24 bytes nsHTMLEditor::ApplyDocumentOrOverrideStyleSheet(const nsString & {...}, int 0) line 3131 + 112 bytes ---------------------------------- This call in nsCSSScanner::Next() hangs: PRInt32 ch = Read(aErrorCode); Investigating this bug revealed a separate problem in editor code. See bug 22072 for details. If you use the editor menu to test this bug, you might want to apply the fix for that bug first to be sure the correct code is called: In editor/base/nsHTMLEditor.cpp, in method nsHTMLEditor::ApplyStyleSheet, change this: return ApplyDocumentOrOverrideStyleSheet(aURL, PR_TRUE); to: return ApplyDocumentOrOverrideStyleSheet(aURL, PR_FALSE); and recompile in mozilla/editor directory.
Adding myself to the cc list.
I traced as far as I could, continuing from the location in the above stack, to: nsAutoCMonitor::Wait(unsigned int 4294967295) line 259 nsPipe::nsPipeInputStream::Fill() line 444 + 10 bytes nsPipe::nsPipeInputStream::ReadSegments(nsPipe::nsPipeInputStream * const 0x02764748, unsigned int (void *, const char *, unsigned int, unsigned int, unsigned int *)* 0x1003e6f0 nsWriteToRawBuffer(void *, const char *, unsigned int, unsigned int, unsigned int *), void * 0x00e08d50, unsigned int 8192, unsigned int * 0x0012da74) line 370 + 8 bytes nsPipe::nsPipeInputStream::Read(nsPipe::nsPipeInputStream * const 0x02764748, char * 0x00e08d50, unsigned int 8192, unsigned int * 0x0012da74) line 473 ByteBufferImpl::Fill(ByteBufferImpl * const 0x02777050, unsigned int * 0x0012dab4, nsIInputStream * 0x02764748, unsigned int 0) line 131 + 36 bytes ConverterInputStream::Fill(unsigned int * 0x0012dab4) line 269 + 33 bytes ConverterInputStream::Read(ConverterInputStream * const 0x027750b0, unsigned short * 0x027754f0, unsigned int 0, unsigned int 256, unsigned int * 0x0277572c) line 242 + 12 bytes nsCSSScanner::Read(int & 0) line 200 + 37 bytes nsCSSScanner::Next(int & 0, nsCSSToken & {...}) line 305 + 12 bytes Its not returning from rv = mon.Notify(); in nsPipe::nsPipeInputStream::Fill(). I hope this helps.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
Dup. *** This bug has been marked as a duplicate of 11859 ***
Whiteboard: [PDT-]RN
Putting on PDT- radar. Will release note.
Status: RESOLVED → VERIFIED
verified in 12/18 build.
You need to log in before you can comment on or make changes to this bug.