260196 - Reproducible Composer crashes with nested font size tags [@ nsStyleSet::ProbePseudoStyleFor ]

Status: RESOLVED INCOMPLETE

(Core :: DOM: Editor, defect)

Description

[Michel Bougon]

User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.3) Gecko/20040910
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.3) Gecko/20040910

About half of the time, in Composer,  when I apply a "-a" font-size on a short
text in Georgia font,  Mozilla crashes.      Here are two crashes --

2004 September 18th, 06h10
Composer
Making font-size "-a" on a 2-line Georgia font paragraph

MOZILLA caused a stack fault in module GKLAYOUT.DLL at 0177:613efb13.
Registers:
EAX=615d1718 CS=0177 EIP=613efb13 EFLGS=00010206
EBX=02684f88 SS=017f ESP=00552000 EBP=0055201c
ECX=00000000 DS=017f ESI=02684f88 FS=184f
EDX=0064ce3c ES=017f EDI=02684e3c GS=0000
Bytes at CS:EIP:
56 ff 50 34 5f 5e c2 08 00 b8 ff ff 00 80 c2 18 
Stack dump:
02d90490 02684f88 02684f88 613efae4 02d90490 02684e3c 00000000 00552048 613f374f
02684f88 02d90490 0227e850 02684f08 02684e3c 00000000 00000000 


2004 September 14th, 17h45
Composer
Making font-size "-a" on a centered Georgia few words

MOZILLA caused a stack fault in module GKLAYOUT.DLL at 0177:613efb13.
Registers:
EAX=615d1718 CS=0177 EIP=613efb13 EFLGS=00010206
EBX=03187434 SS=017f ESP=00552000 EBP=0055201c
ECX=00000000 DS=017f ESI=03187434 FS=814f
EDX=0064ce3c ES=017f EDI=031873e8 GS=0000
Bytes at CS:EIP:
56 ff 50 34 5f 5e c2 08 00 b8 ff ff 00 80 c2 18 
Stack dump:
02c37a30 03187434 03187434 613efae4 02c37a30 031873e8 00000000 00552048 613f374f
03187434 02c37a30 047b5c40 031873b4 031873e8 00000000 00000000 

Reproducible: Sometimes
Steps to Reproduce:
1.  Apply "-a" fontsize to a short Georgia paragraph
2.  Watch the "-a" button turn Black and remain black for about 30 seconds
3.  Comtemplate a Mozilla crash
Actual Results:  
Mozilla crashes

Expected Results:  
Not To Crash ........  ;-) 

This is not new ... it was happening in version 1.7.2  ...  and most likely in
1.7.1 and 1.7.0  ... ...   On Windows 98SE fully updated and constantly scrubbed ...

Comment 1

[Michel Bougon]

One more crash ... ... ...

Note that the EIP is the same in all three crashes.     So, it is not a random
crash,  but a crash caused by a very specific processor instruction.

2004 September 18th, 07h29
Composer
Making font-size "-a" on a 1-line, Georgia font, few-words paragraph

MOZILLA caused a stack fault in module GKLAYOUT.DLL at 0177:613efb13.
Registers:
EAX=615d1718 CS=0177 EIP=613efb13 EFLGS=00010206
EBX=02ded2e4 SS=017f ESP=00552000 EBP=0055201c
ECX=00000000 DS=017f ESI=02ded2e4 FS=489f
EDX=0064ce3c ES=017f EDI=02ded298 GS=0000
Bytes at CS:EIP:
56 ff 50 34 5f 5e c2 08 00 b8 ff ff 00 80 c2 18 
Stack dump:
0292ed10 02ded2e4 02ded2e4 613efae4 0292ed10 02ded298 00000000 00552048 613f374f
02ded2e4 0292ed10 026006d0 02ded264 02ded298 00000000 00000000 

Comment 2

[Andrew Schultz]

the information windows gives you isn't really useful.  please submit a talkback
report and then get the stacktrace here http://talkback-public.mozilla.org/ or
just mention the talkback ID here.

Comment 3

[Michel Bougon]

AJSchult

Speaking from the perspective of machine language,  and Assembly Language
debugging, I could not have provided a more precise description of the crash
origin.    I provided the EIP register that indicates the exact processor
Instruction that led to the crash,  as well as all the other registers and the
full processor stack.    So, in a machine-language様evel  debugger one can go
exactly to the failing Instruction and explore around it, and see exactly what
is going on.

What am I missing ?    Thank you !

Michel

Comment 4

[Colin S]

Michel-
Such a crash report does not explain where in the Mozilla source the crash
occurred. Talkback provides much better data on where in which module the crash
occurs.

Comment 5

[Michel Bougon]

AJSchult

I can see your point if you want to debug from a "higher level".    Of course,
this assumes that the lower levels have no bugs.............. ;-)

Thank you for your prompt answer.
Michel

Comment 6

[Gérard Talbot]

Michel,

What value do you have for 
Edit/Preferences.../Appearance category/Fonts/Minimum Font Size? Do you have a
Minimum Font Size set?
In which Editing mode (Normal, HTML Tags or Preview?) are you using when such
crash happens?
Do you experience crash if you increase the font-size with +a?
What are you settings for 
Edit/Preferences.../Composer/
Retain original or Reformat HTML? and for Use CSS styles instead of HTML
elements and attributes?
You chose "Version: trunk": do you experience crash with a trunk build?
How do you select the text that you want to decrease the font size? Does the
selected text involve more than 1 node (ie more than 1 HTML element)?
Can you provide a *reduced* test page in which this situation, crash occured?

I agree with the Colin and Andrew that talkback report would be very useful here.

As far as I can test this over here, I do not crash while using Mozilla 1.8a4
build 2004091512 under XP Pro SP2 here.

Comment 7

[Michel Bougon]

Hi Drunclear !

 >>>> What value do you have for 

 >>>> Edit/Preferences.../Appearance category/Fonts/Minimum Font Size? 
Do you have a Minimum Font Size set?

It is set to -- "None"


 >>>> In which Editing mode (Normal, HTML Tags or Preview?) are you using when
such crash happens?

I am in -- Normal


 >>>> Do you experience crash if you increase the font-size with +a?

I do not know.   I will do it later......   Right now I am not ready for a crash.


 >>>> What are you settings for 
Edit/Preferences.../Composer/
Retain original or Reformat HTML? 

I am set to --  Reformat

and for Use CSS styles instead of HTML
elements and attributes?

I have never used CSS.    (I get rid of them when I download a webpage)


 >>>> You chose "Version: trunk": do you experience crash with a trunk build?

I am using the "Stable" 1.7.3  (from the ftp site)


 >>>> How do you select the text that you want to decrease the font size? 

I either drag over it,  OR,  I drag over the left margin


 >>>> Does the selected text involve more than 1 node (ie more than 1 HTML
element)? 

Yes.   Actually, I just found out that it is HORRIFIC what Composer has been
generating .... Here it is --

< SNIPPET BEGINS >

... metaphors are one communication
mechanism that can function to reconcile discrepancies in meaning,
i.e., through metaphors equifinal meaning can be created.<br>
<br>
</font></font></font></font></font></font></font></font></font></font></font></font></font></font>
<div align="center"><font face="Georgia" size="3"><font face="Georgia"
size="3"><font face="Georgia" size="3"><font face="Georgia" size="3"><font
face="Georgia" size="3"><font face="Georgia" size="3"><font
face="Georgia" size="3"><font face="Georgia" size="3"><font
face="Georgia" size="3"><font face="Georgia" size="3"><font
face="Georgia" size="3"><font face="Georgia" size="3"><font
face="Georgia" size="3"><font face="Georgia" size="3">48/ASQ, March
1986</font></font></font></font></font></font></font></font></font></font></font></font></font></font><br>
</div>
<hr size="2" width="100%"><br>
<blockquote><font face="Georgia" size="3"><font face="Georgia" size="3"><font
face="Georgia" size="3"><font face="Georgia" size="3"><font
face="Georgia" size="3"><font face="Georgia" size="3"><font
face="Georgia" size="3"><font face="Georgia" size="3"><font
face="Georgia" size="3"><font face="Georgia" size="3"><font
face="Georgia" size="3"><font face="Georgia" size="3"><font
face="Georgia" size="3"><font face="Georgia" size="3">Figure 2. <br>
Metaphors and organized action: The iterative process of
sense making
and action
taking.</font></font></font></font></font></font></font></font></font></font></font></font></font></font><br>
<br>

< SNIPPET ENDS >


After seeing this horror,  I am going to Turn OFF Composer's
Autoformat..............

The pile up comes from Composer because I started from a plain text file, and I
manually added the <P>  and <BR> throughout,  and I only added at the top the line
<BODY marginwidth=66> <font face="Georgia" size="3">



 >>>> Can you provide a *reduced* test page in which this situation, crash occured?

Yes, with pleasure.   In my next installment,  after I am confident that I have
boiled it down to the minimal code.

It may well be the case that after I remove all the excess tags piled on by
Composer (Autoformat?),  that the crashes will no longer occur (until enough
excess tags have again piled on).....

Cheers 
Michel

Comment 8

[Michel Bougon]

Further below, is a snippet from the original large html file.

In Composer 1.7.3 , this snippet will crash *everytime* one does either one of
these actions --

 -- Set the 1-line paragraph labeled "THREE" to fontsize "-a"

 -- Set the 1-line paragraph labeled "THREE" to fontsize "+a"

I did it by highlighting by dragging from right to left over the line (which is
generally is easier to do than left to right),  and then clicking on either "-a"
or "+a".

The "-a" or "+a" button turns black and remains black until the crash occurs
roughly 45 seconds later.

Again, the pile up of tags comes from Composer (in the large original html file)
because I started from a plain text file.   I manually added the <P>  and <BR>
throughout,  and I added at the top of the original plain text file the lines
<html><head></head>
<BODY marginwidth=66> <font face="Georgia" size="3">

Incidentally, having "Autoformat" either ON or OFF makes no difference.  
Probably because it is too late, the pile up of tags is already in place.   
Thus, one of the new questions is whether Autoformat is responsible for creating
the pileup of tags.

Here is the snippet.  (Again, the pile up of tags was created by Composer in the
original large html file) --

<html>
<head></head>
<BODY marginwidth=66> <font face="Georgia" size="3">

<p>
ONE ... metaphors are one communication
mechanism that can function to reconcile discrepancies in meaning,
i.e.,
through metaphors equifinal meaning can be created.<br>

<p>
TWO ... metaphors are one communication
mechanism that can function to reconcile discrepancies in meaning,
i.e.,
through metaphors equifinal meaning can be created.<br>
<br>
</font></font></font></font></font></font></font></font></font></font></font></font></font></font>
<div align="center"><font face="Georgia" size="3"><font face="Georgia"
size="3"><font face="Georgia" size="3"><font face="Georgia" size="3"><font
face="Georgia" size="3"><font face="Georgia" size="3"><font
face="Georgia" size="3"><font face="Georgia" size="3"><font
face="Georgia" size="3"><font face="Georgia" size="3"><font
face="Georgia" size="3"><font face="Georgia" size="3"><font
face="Georgia" size="3"><font face="Georgia" size="3">THREE ... 48/ASQ, March
1986</font></font></font></font></font></font></font></font></font></font></font></font></font></font><br>
</div>
<hr size="2" width="100%"><br>
<blockquote><font face="Georgia" size="3"><font face="Georgia" size="3"><font
face="Georgia" size="3"><font face="Georgia" size="3"><font
face="Georgia" size="3"><font face="Georgia" size="3"><font
face="Georgia" size="3"><font face="Georgia" size="3"><font
face="Georgia" size="3"><font face="Georgia" size="3"><font
face="Georgia" size="3"><font face="Georgia" size="3"><font
face="Georgia" size="3"><font face="Georgia" size="3">FOUR ... Figure 2. <br>
Metaphors and organized action: The iterative process of
sense making
and action
taking.</font></font></font></font></font></font></font></font></font></font></font></font></font></font><br>
<br>
</body>
</html>


Cheers !
Michel
PS --  Should not Autoformat do some cleanup ?  (eg, remove tag pairs around
null text,  such as <b></b>  or <font xxxx></font>

Comment 9

[Andrew Schultz]

Attachment: stacktrace

I get a hang with linux trunk, but only because it takes a while to blow the
stack (which also explains why talkback doesn't catch the crash).

Comment 10

[Andrew Schultz]

Attachment: testcase

load this in composer, hit "-a" ==> hang (crash)

Comment 11

[Andrew Schultz]

confirmed with linux trunk 2004091905

Comment 12

[zug_treno]

Attachment: Page with 8,9 and 10 nested fonttags

It seems that 8 nested <font size="3"> tags make mozilla slow for a few
seconds, 9 tags make mozilla unresponsive for a longer time and with 10 tags
mozilla crashes after about 15s. (rv:1.8a2 Gecko/20040702)

Comment 13

[zug_treno]

I think composer tries to make each individual fonttag one step smaller, so with
2 fonttags around the selected text it becomes x-small, with 3 tags xx-small,
with 4 tags xxx-small and so on. After selecting text with 7 nested fonttags and
clicking the "-a" button once the text is very small but still visible, with 8
tags the text disappears.

Comment 14

[Gérard Talbot]

First of all, thank you Michel for your cooperation in trying to identify the
source of the problem.

Note that any browser can and will crash when trying to dynamically
update/modify heavily, deeply nested elements like that.

IMO, the real issue is to prevent Composer from creating pointlessly,
unneedlessly so many nested font nodes like that.
> I manually added the <P>  and <BR> throughout,  and I only added at the top 
> the  line <BODY marginwidth=66> <font face="Georgia" size="3">
This is where the problem start. Maybe we could even create steps to reproduce this.

One recommendation I advise you to do from now on, Michel, when you're using
Composer: it's to always use (or visit+view frequently) the HTML Tags editing
mode so that you can see what is happening, what element or node you're
selecting, pasting, copying, and to use the statusbar for selecting a node. I
also advise you to have "Use CSS styles instead of HTML elements and attributes".

Comment 15

[Boris Zbarsky [:bzbarsky]]

> Note that any browser can and will crash when trying to dynamically
> update/modify heavily, deeply nested elements like that.

Sorry, but that's bullshit.  We shouldn't be crashing on this.

Over to core editor.  ccing Daniel, since he probably knows this code.  Is the
solution here to use an iterative, not recursive, approach?

Comment 16

[[e-mail]]

Attachment: Partial backtrace

Comment 17

[Michel Bougon]

Bzbarsky

Actually, an even Greater BS is Composer spinning itself into a TOTALLY
UNECESSARY Ever Deeper Nest of <FONT  tags.

I suspect that this bug has to do with a very old bug, never fixed, where "Paste
Without Formating",  actually (a) closes the current nesting, (b) inserts using
the  <body> -specified format, (c) reopens the just-closed nesting.    The
result is an insert totally out of whack with the context of the insertion, as
well as code that Composer usually refuses to edit further, and that must be
fixed manually.

Well,  one day ... ... ...   In the meantime, I have written several Slickedit
RE macros to regularly cleanup after Composer messes its nest.   Otherwise,
after a while I can no longer edit previously edited regions, or the whole
Mozilla crashes.....

Also, another several-years-old bug, never fixed, is to be able to invoke an
external programming editor (with macros, etc) ... ... Just like Netscape
Communicator was doing from day one, ten year ago.

Cheers !!!
Michel

Comment 18

[Michel Bougon]

Drunclear

You write -- ""I also advise you to have "Use CSS styles instead of HTML
elements and attributes".""

If I follow your advice, and I use the following starting file in Composer --

<html>
<head>
<title>Play With CSS</title>
content="text/html; charset=iso-8859-1>
<style type="text/css">
<!--
p {
font-family: Verdana, Arial, Helvetica, sans-serif;
font-size: 12px;
color: #000000;
line-height: 16px;
}
.customer {
font-family: Verdana, Arial, Helvetica, sans-serif;
font-size: 9px;
font-style: italic;
line-height: normal;
color: #000000;
}
.quote {
font-family: Verdana, Arial, Helvetica, sans-serif;
font-size: 10px;
line-height: normal;
color: #000000;
}
li {
font-family: Verdana, Arial, Helvetica, sans-serif;
font-size: 12px;
color: #000000;
}
-->
</style>
</head>
<body marginwidth="66">
<br>
<br>
</body>
</html>

Then, in Composer, when I click on the button "Chose a paragraph format", the
CSS styles I just defined are NOT listed.

When I click on  | Format | Text Style | , the CSS styles I just defined are NOT
listed.

So, right now, I am at a loss for using CSS in Composer.   Could you tell me how
I make the CSS styles I just defined to be listed under one of the Composer
buttons, so that I can select one of them and apply it to a paragraph???

Thank you !
Michel

Comment 19

[Gérard Talbot]

> You write -- ""I also advise you to have "Use CSS styles instead of HTML
> elements and attributes".""
> 

and that was merely an off-topic friendly advice given to you on the fly.
Bugzilla is a place for submiting, confirming, fixing real bugs by volunteers in
mozilla components, you know. Anything that does not help, that does not address
positively, constructively the topic of the bug or aiming at fixing the bug is
not welcomed, often annoy a majority of people, including developers.

>  Could you tell me how
> I make the CSS styles I just defined to be listed under one of the Composer
> buttons, so that I can select one of them and apply it to a paragraph???
> 

I have answered your question in netscape.public.mozilla.editor; thread is "How
to style paragraphs in Composer"
snews://secnews.netscape.com:563/ciurps$[e-mail]
Next time, please submit your webpage problem to a mozilla newsgroup.

Comment 20

[Gérard Talbot]

This bug might after all be the same as bug 240459 where the user tries to copy
an inline element (like a <font> or <img>) within a block element and he ends up
creating a nested element inside the block element.

Comment 21

[Gérard Talbot]

At the very least, this bug is dependent of bug 71117 

Comment 22

[Ronald Tilby]

Testcases WFM using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060601 Minefield/3.0a1 ID:2006060105 [cairo]

Comment 23

[Andrew Schultz]

Ronald: How exactly did you test this in Firefox?

The testcase still hangs with linux seamonkey trunk build 2006060108.  I should add to the testcase instructions in comment 10 that it's necessary to select the text before hitting the "-a" button.

Comment 24

[Pavel Cvrcek [:JasnaPaka]]

Maybe related to this bug.

Mozilla Firefox JavaScript Handler Race Condition Memory Corruption Vulnerability
Info: http://www.securityfocus.com/bid/19488/info
Exploid: http://lcamtuf.coredump.cx/ffoxdie.html

Firefox 1.5.0.6 and latest Trunk crashes with "nsStyleSet::ProbePseudoStyleFor".

Talkback: TB22203197K

Comment 25

[Andrew Schultz]

that's bug 348514.  stack overflow or memory corruption crashes can crash just about anywhere.  the frame at the top isn't particularly relevant.

Comment 26

[Wayne Mery (:wsmwk)]

crashes also on windows 20061025 

I don't see how this is related to bug 240459 (260916 not related to div) and dependent on bug 71117, which may or may not get fixed b/c it asks for accepting the HTML that isn't current supported.

Comment 27

[Jesse Ruderman]

Does this still crash?