sujay Reporter
	Description • 24 years ago

using 4/24 build of netscape

1) launch netscape
2) launch composer
3) insert default 2 x 2 table
4) click on the HTML Source tab at bottom
5) click on Show All Tags tab at bottom
6) click on Normal tab

notice the table gets enlarged and the caret
becomes big..

	Kathleen :Brade
	Comment 1 • 24 years ago

We are stuffing in an extra <br> in each empty cell.  :-/

	kinmoz
	Comment 2 • 24 years ago

There are actually 2 problems here:

The first one ... The big caret is the result of bug #47040, which doesn't 
preserve the caret position when switching between the modes.

I believe the big caret is acceptable/expected if the caret is placed before the 
table.

The 2nd one ... Like brade said above we are inserting a 2nd set of <BR>s in 
blank table cells, which I assume is the result of some rules post processing. 
The rules shouldn't be adding them to the table cells because they aren't empty.

	Joe Francis Assignee
	Comment 3 • 24 years ago

I bet this is a regression caused by my IsEmptyNode() changes.  There are times 
when I want to consider blocks with just a br empty.  This isn't one of them.  I 
should probably break it out into two different calls:  "IsEmpty" and 
"LooksEmpty".  :-)

	Joe Francis Assignee
	Comment 5 • 24 years ago

patch to editor/base/nsHTMLEditor.cpp attached.  need r/sr

patch explained: it used to be that callers to IsEmptyNode() would indicate 
whether or not a br node with the special moz attribute counted in determining if 
a node was empty.  So if we were trying to figure out if we needed to add a br 
node, we would call with that param false, but if we were trying to figure out if 
a node "looked" empty, we would call with it true.

For my fixes to 71362 I started moving IsEmptyNode away from dependency on moz-br 
nodes, and towards a more general approach of simply counting the number of brs 
(of any kind) inside the node.  But I didn't do a complete job, which led to this 
bug.  Now IsEMptyNode no longer cares about moz-brs at all, and we are back to 
happy land.  

We are almost to the point where we could stop using moz-brs, but the selection 
adjusting code is still cares about them, so I can't rip them out completely yet.

	Kathleen :Brade
	Comment 6 • 24 years ago

this seems good to me (tested the patch on Mac build from yesterday) r=brade

	sujay Reporter
	Comment 7 • 24 years ago

I can verify after this bug gets marked RESOLVED-FIXED...is the patch
in the tree?

did someone forget to mark this fixed? just checking...

	Joe Francis Assignee
	Comment 8 • 24 years ago

no one forgot.  I still need sr.

	kinmoz
	Comment 9 • 24 years ago

FYI, I gave Joe a verbal sr=kin last week. I believe Joe checked in his 05/01/01
13:44 patch already. Not sure if he's keeping this open on the caret issue or not.

	Kathleen :Brade
	Comment 10 • 24 years ago

caret issue is a different bug (caret not being placed correctly when going 
between tabs)

	Simon Fraser [no longer active]
	Comment 11 • 24 years ago

r/sr=sfraser

	Joe Francis Assignee
	Comment 12 • 24 years ago

ooops, forgot to mark fixed

	Keyser Sose
	Comment 13 • 24 years ago

*** Bug 80448 has been marked as a duplicate of this bug. ***

	Kathleen :Brade
	Comment 14 • 24 years ago

*** Bug 82682 has been marked as a duplicate of this bug. ***

	sujay Reporter
	Comment 15 • 24 years ago

verified in 5/30 build.