In Composer, I came across this case where inserting an <hr>, pressing return (which generates a <br> in Composer today), and then inserting another <hr> didn't render the same as it did in the browser. After much further investigation and experimentation, I am filing this bug. I have two attachments to add which can be used to experiment without using Composer. Those will follow. Note: In the one testcase, when adding the tags to the browser via document.write, the browser renders correctly (a bigger gap between the two <hr> tags). In the other testcase, when adding the tags via the dom, the browser shows the two <hr> close together (ignoring a <br> in between). Marc--I'd be happy to do some preliminary legwork on this bug but I need a few pointers.

I'm building right now, but the first thing I need to check is how the content model looks via 'Dump Content' in Viewer. Maybe you have already done this, but we need to know if the BR is getting inserted into the content model before I can get anywhere with the potential layout problems. If it is, then I'll check what frames are getting created, and if not, then it is likely a DOM or ContentSink problem. BTW: I noticed that this is broken in NS6 RTM as well. How critical is this to composer? Should we nominate for Moz 0.9? ... Accepting.

brade says it is pretty important - marking P2 and Mozilla 0.9

The problem is with the BR being appended after the HR in Quirks mode. I think it is a problem because the HR in Quirks mode is really an Inline with a \A after it (using HR:after { content: "\A"; }) and when the BR is appended after the line has already been reflowed, it is not correctly reevaluating the lines and reflowing the BR down to its own line. In STD mode it is OK because HR is a block. My guess is that other cases where content:"\A" is used will probably show the same problem. I'm debugging this now, but it is all new code to me, so patience or assistance is appreciated...

Downgrading slightly - moving to Mozilla 1.0 to make room for top crashers in Mozilla 0.9.1

Updating QA contact to Shivakiran Tummala.

-->m1.1

I know it's gonna be done soon automatically but I'm sick of the target milestone and assignee :-) Besides I don't understand the testcases

<hr> got whacked and the testcases both work identically for me... is this still a problem, brade?

I don't know if this is still an issue or not. I wouldn't be surprised if it was fixed with some other <hr> bug. I think that this can be resolved as worksforme.