25510 - Can't type in Netscape Webmail's to: cc: or bcc: fields

Status: VERIFIED FIXED

(Core :: Layout, defect, P1)

Description

[scottputterman]

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.

Comment 1

[buster]

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.

Comment 2

[buster]

Attachment: small test case that shows the problem only if the window is narrow

Comment 3

[buster]

Attachment: better test case, doesn't involve nested tables or window width

Comment 4

[buster]

marking potential beta1 bugs

Comment 5

[leger]

PDT+

Comment 6

[buster]

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.

Comment 7

[troy]

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

Comment 8

[buster]

Attachment: same problem, no nbsp; added a submit button to show that the editor IS getting key events

Comment 9

[buster]

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.

Comment 10

[buster]

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.

Comment 11

[buster]

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

Comment 12

[buster]

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

Comment 13

[buster]

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

Comment 14

[buster]

when verifying, please verify both webmail and netaddress

Comment 15

[buster]

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.

Comment 16

[troy]

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

Comment 17

[buster]

agreed

Comment 18

[buster]

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

Comment 19

[sujay]

verified in 2/23 build.