Closed
Bug 77558
Opened 24 years ago
Closed 24 years ago
table gets screwed up after toggling between Normal & Source modes
Categories
(Core :: DOM: Editor, defect, P2)
Core
DOM: Editor
Tracking
()
VERIFIED
FIXED
mozilla0.9.1
People
(Reporter: sujay, Assigned: mozeditor)
References
Details
(Whiteboard: fix in hand)
Attachments
(1 file)
(deleted),
patch
|
Details | Diff | Splinter Review |
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..
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.
Assignee: kin → jfrancis
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". :-)
Status: NEW → ASSIGNED
Priority: -- → P2
Target Milestone: --- → mozilla0.9.1
Assignee | ||
Comment 4•24 years ago
|
||
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.
Whiteboard: fix in hand; need reviews
Comment 6•24 years ago
|
||
this seems good to me (tested the patch on Mac build from yesterday) r=brade
Whiteboard: fix in hand; need reviews → fix in hand; need sr=
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...
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.
Comment 10•24 years ago
|
||
caret issue is a different bug (caret not being placed correctly when going between tabs)
Summary: table and caret get screwed up after toggling between Normal and Source modes → table gets screwed up after toggling between Normal & Source modes
Whiteboard: fix in hand; need sr= → fix in hand
Assignee | ||
Comment 12•24 years ago
|
||
ooops, forgot to mark fixed
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•