Go to webmail.netscape.com login go to write mail Try to type in to: cc: or bcc: result: you can't. But you can type in the subject field.

assigning to myself. I think this is a problem with the way block/inline code reports maxElementSize. Attaching minimized test case. You will only be able to reproduce this in a reasonably narrow window. If you make the window wider, it works as expected.

marking potential beta1 bugs

PDT+

the real problem here is that the block code needs to maintain starts/ends-with-nbsp on a per-span and per-frame basis to properly compute the max-element-size of the block.

The line state does remember whether the line wrapped. I added that, because I needed it. That might get you what you need

just added a test case that shows that the text control is getting mouse and key events. if you click on the control, a webshell gets created, and if you type, characters are added. you can't see them, but if you hit the submit button they'll get sent off as part of the query URL. latest guess: an incremental reflow error in inline code that prevents the webshell from getting located properly. rod has a similar sounding problem with select controls.

Here's what's going on here. Basically, an incremental reflow is not getting to its target frame. Let's look at the over-simplified test case: <Block><Span>text<TCF></Span></Block> TCF is "Text Control Frame", but it could be a select or a number of other frame types that rely on incremental reflows. The (simplified) frame model at the time of the incremental reflow looks like this: Block Line_1 Span_1 Text Line_2 Span_2 TCF The incremental reflow is targeted at the TCF. The mPath in the reflow command has Block > Span_2 > TCF. The block code marks both Line_1 and Line_2 dirty. Why? Not sure, probably to give Line_1 an oppurtunity to pull up content from Line_2. The block code calls reflowState->GetNext() and stores the next frame in reflow path Span_2. When Line_1 is reflowed, nsLineLayout::ReflowFrame(Span_1, ...) causes Span_2 to be deleted, by calling nsBlockFrame::DeleteChildsNextInFlow(Span_1). Now that Span_2 has been deleted, the block code continues it's incremental reflow moving on to Line_2. When it checks to see if any of the children of Line_2 are in the reflow path, the answer is "no" because the original Span_2 is gone. So the incremental reflow never gets to the TCF in the new replacement for Span_2. I can see 3 approaches for trying to fix this: 1) create an "endangered" list for the span's next-in-flow, rather than actually deleting them. As next-in-flows need to be inserted, we grab them off this list if possible. I think the "if possible" criteria is "if the prev-in-flow didn't change", meaning the last child frame on that line has identical content as before. I'm a bit fuzzy on that. This would maintain our pointer identity for the span frame in all cases where it matters, though I'm not sure I can articulate just what that means. All incremental reflows where the target does not change width? 2) Change the flow of control to mark only the target's containing line as dirty, at least initially. Do the incremental reflow "normally." Then, detect if the incremental reflow caused anything to change size. If it did, go back and mark the prev-in-flow and the current lines dirty and do a resize reflow. 3) Set up a notification mechanism to fix up the "next frame in reflow path" pointer. Somehow, we'd have to detect that next-in-flows are being created and match them with the target, so we knew how to properly target the incremental reflow. This could get complicated if there are multiple levels of continued frames. Troy, Nisheeth, Rick: any other approaches? Any opinion which is most likely the right way to go? This seems to effect a fair number of important pages, so I'm marking this P1.

forgot to add rickg and nisheeth to cc-list. please see my previous comment.

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

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

when verifying, please verify both webmail and netaddress

fixed in nsBlockFrame.cpp. Added a separate code path to correctly propogate incremental reflow to children of continued span frames. Could be more efficient, but that's a separate issue.

I'm re-opening the bug because: - the fix is unacceptable and doesn't work correctly if floaters are involved - I was listed as a reviewer even though I specifically objected to the proposed solution Because the code doesn't call ReflowDirtyLines() we aren't recovering the floater state and so reflowing the line won't work correctly if floaters are involved. We also don't call PropogateReflowDamage() after calling ReflowLine() which means if that line impacts the line that follows the next line won't get marked dirty And the check in Reflow() is for !block line which means that the original problem is still a potential problem in paginated mode when blocks can be split

agreed

fixed, along with 28084. fix was in nsBlockFrame.cpp handling of incremental reflows targeted at child inline frames.

verified in 2/23 build.