Closed Bug 56102 Opened 25 years ago Closed 25 years ago

cannot type new line after inputting HTML text

Categories

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

Product:
Core
Component:
DOM: Editor
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: tracy, Assigned: buster)

Details

commercial builds: windows 2000-10-11-06-Mtrunk linux 2000-10-11-09-Mtrunk -open composer type in HTML text -type newline/return expected results: cursor moves down a line tested results: cursor stays at end of current text. note: this only happens after HTML text....you can get a new line after plain text, after an image or after a horizontal line.
This is pretty bad regression. cc: asa since it's on the trunk. We're waiting to see if this is also on the branch. Mark smoketest for now to get on radar. Asa and others may disagree; if so, pls change if only affecting trunk builds.
Severity: critical → blocker
Keywords: smoketest
My win2k build with the changes from me (blake checked in) does not show this problem. I didn't do it.
this is not on branch builds: windows 2000-10-11-09-MN6 linux 2000-10-11-09 nor is it on mac trunk build 2000-10-11-09-M18(actually Mtrunk)
note: this is affecting the mac trunk build in mail. and when I rechecked, it was momentarily there in the composer. opened a new composer window and it went away.
I can't reproduce this in either my Mac mozilla debug build from the trunk or my Linux mozilla debug build from the trunk. ... WorksForMe... Tracy: what kind of text are you typing? Can you paste some here? Are you typing in Composer or Mail Compose?
I'm not seeing this problem in Composer or MsgCompose in my Win32 or Linux Netscape_20000922_BRANCH debug build either.
brade....good to know it's not on the mozilla builds. I'm simply typing in text changing it to bold or color or any HTML text. once you do, the enter/newline won't move the cursor down the page. kin.....are you testing a 9/22 build??
Ok, so adding a color or bold is key to triggering this bug. I see the problem in my trunk build on linux. If I make some text red and then hit the return key afterwards, the caret moves to the next line, but typing anything at the keyboard is then ignored. If I place the caret elsewhere in the document I am able to type.
I can now reproduce on both Linux and Mac trunk builds. The key is to type some bold text, press return and try to continue typing bold text. The text is actually there but it isn't being rendered.
kin thinks that this is caused by fixes that went into the NOFIX branch, and landed in the Netscape branch, but are missing from the trunk. nsHTMLEditor.cpp seems to be the only file involved.
I tried rebuilding with Kin's suggestion of copying over the file from the branch but that did not fix this bug.
all smoketesting is done. this is the only blocker and I am holding the commercial trunk for this. so this bug is only on the trunk, correct?
I've seen this at least since last Friday (though Joe says it's been there much longer than that), when deleting text first. E.g. New Msg from mail, decide I don't want my signature in this message, sweep out everything (which is just the signature and a line or two before it) and hit delete, and now I'll see the bug on every return. The returns are really there (if you start typing, you'll see the return then), the caret just does not move down a line until you type something.
Is this really a blocker? I don't think so.
Severity: blocker → major
Keywords: smoketest
This bug affects mozilla and commercial trunk builds only. This is how to reproduce this particular bug: * new composer window * type 123 * press control-b (bold) * type abc * press return/enter * type def [note: you won't see this text yet] * press control-b (un-bold) * type 456 I've tried backing out various checkins but still haven't found the right one :-(
Hardware: PC → All
Since this doesn't occur in branch builds, I'll let Asa make the call on whether it's a blocker. I'm not sure if this affects the Mozilla M18 builds. It sounds like there are more steps involved. However, should we keep the trunk closed before more checkins occur to make it easier to find the cause of this bug?
Summary: cannot type new line after inputting HTML text → cannot type new line after inputting HTML text (ie. bold)
Whiteboard: trunk only
Could be my checkins for bug 54005. I'm trying them now...
Summary: cannot type new line after inputting HTML text (ie. bold) → cannot type new line after inputting HTML text
Whiteboard: trunk only
I see similar bizarre behaviour on branch builds with brade's repro instructions
The behavior on the branch is different; at least the text shows up when I type. I downloaded the MTrunk build from 10/10 20 on Macintosh and I see this problem.
...reverting my changes to nsLineLayout.cpp seem to have no effect on this bug. (*whew*) Is this known to be a regression?
yo buster, any ideas?
Yea, buster, what gives ;) That nsBlockFrame #if 0 around the line dirtying is the culprit, sending to you... Thanks, Steve, for remembering that change!
Assignee: beppe → buster
I'll back out the offending change. waterson-san, this is the optimization we've been testing for speeding up typing in large docs. bummer. It looks like we'll need to put in some conditional code that skips this step under normal circumstances, but detects edge cases like this one. jg: so, youz wanna me check this in now, or after the trunk opens?
Status: NEW → ASSIGNED
I think editor is getting layout into a wedged state (cf. brade's repro steps still cause weird failure on branch builds). So I'm *still* not convinced that we need that code :-). But yes, let's get it backed out for now! brade: do you want to file a bug on the branch build problems, or should I?
waterson--see bug #56168 filed by sfraser Is the fix/backout by buster checked in?
fix checked in. backed out the fix for bug 43914. on trunk only, r=waterson
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Keywords: vtrunk
mark vtrunk keyword for asa to verify.
Verified Fixed with 101308 mozilla trunk linux build on RedHat6.2, 101308 mozilla trunk win32 build on NT4 and 101308 mozilla trunk mac build on OS9. Removing vtrunk keyword and setting to Verified.
Status: RESOLVED → VERIFIED
Keywords: vtrunk
You need to log in before you can comment on or make changes to this bug.