Closed Bug 21941 Opened 20 years ago Closed 20 years ago

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

Categories

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

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: 20 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.