cannot type new line after inputting HTML text




18 years ago
7 years ago


(Reporter: tracy, Assigned: buster)



Firefox Tracking Flags

(Not tracked)




18 years ago
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 can get a new line after plain 
text, after an image or after a horizontal line.

Comment 1

18 years ago
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

Comment 2

18 years ago
My win2k build with the changes from me (blake checked in) does not 

show this problem. I didn't do it.

Comment 3

18 years ago
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)


Comment 4

18 years ago
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 

Comment 5

18 years ago
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?

Comment 6

18 years ago
I'm not seeing this problem in Composer or MsgCompose in my Win32 or Linux
Netscape_20000922_BRANCH debug build either.

Comment 7

18 years ago
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??

Comment 8

18 years ago
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.

Comment 9

18 years ago
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.

Comment 10

18 years ago
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.

Comment 11

18 years ago
I tried rebuilding with Kin's suggestion of copying over the file from the branch 
but that did not fix this bug.

Comment 12

18 years ago
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?

Comment 13

18 years ago
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

Comment 14

18 years ago
Is this really a blocker? I don't think so.
Severity: blocker → major
Keywords: smoketest

Comment 15

18 years ago
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

Comment 16

18 years ago
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

Comment 17

18 years ago
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

Comment 18

18 years ago
I see similar bizarre behaviour on branch builds with brade's repro instructions

Comment 19

18 years ago
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.

Comment 20

18 years ago
...reverting my changes to nsLineLayout.cpp seem to have no effect on this bug.
(*whew*) Is this known to be a regression?

Comment 21

18 years ago
yo buster, any ideas?

Comment 22

18 years ago
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

Comment 23

18 years ago
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?

Comment 24

18 years ago
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?

Comment 25

18 years ago
waterson--see bug #56168 filed by sfraser

Is the fix/backout by buster checked in?

Comment 26

18 years ago
fix checked in.  backed out the fix for bug 43914.  on trunk only, r=waterson
Last Resolved: 18 years ago
Resolution: --- → FIXED


18 years ago
Keywords: vtrunk

Comment 27

18 years ago
mark vtrunk keyword for asa to verify.

Comment 28

18 years ago
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.
Keywords: vtrunk
You need to log in before you can comment on or make changes to this bug.