241833 - Simplify how to detect a textframe inside a form control in nsLineLayout

Status: RESOLVED FIXED

(Core :: Layout: Form Controls, defect)

Description

[rbs]

nsLineLayout has a block of code entitled:

  // SEC: added this next block for bug 45152
  ...big loop here...

This code can be greatly simplify. I will attach a patch.

Comment 1

[rbs]

Attachment: patch

Text input control frames are the only frames with an independent selection
controller for their textarea/text <input>. The NS_FRAME_INDEPENDENT_SELECTION
bit is set in nsTextControlFrame::CreateAnonymousContent, and this gets
propagated to children in nsFrame::Init(). So testing this bit (together with
textFrame == frameType) provides a fast and reliable detection.

Comment 2

[rbs]

s|// SEC: added this next block for bug 45152|bug 45152, 241833|

Comment 3

[Boris Zbarsky [:bzbarsky]]

So... parents are supposed to invalidate kids on size changes, right?  It sounds
like nsLineLayout isn't doing that, based on comments in bug 45152?

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

When the size of a child changes, either the parent or the child is supposed to
invalidate the difference between the new area and the old area of the child.
It's embarrassing, but I actually can't remember whether it's the parent or child.

Hey, I thought you were off duty :-)

Comment 5

[rbs]

bug 45152 comment 24 gives a very good explanation. I actually think that fix
wasn't a hack. It was just implemented sub-optimally.

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

But IsIncrementalDamageConstrained doesn't exist anymore -- text frames are now
reflow roots -- so in the cases when they are reflowed from their parents, we
shouldn't ignore the invalidates, right?

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: remove these ugly hacks

I can't reproduce either bug 45152 or bug 50758 with this patch.  I think this
is just leftover from the old solution that was removed in bug 135146.

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Any chance somebody could test this on Windows?

Comment 9

[rbs]

Re: comment #6

Let me test out on Win2K. I indeed considered such a surgical removal in view of
the fact that text control are not reflow roots, but didn't have enough data to
make a case.

Comment 10

[rbs]

s/text control are not reflow roots/text controls are now reflow roots/
[ignore such typos...]                                  ^

Comment 11

[rbs]

Comment on attachment 147659 [details] [diff] [review]
remove these ugly hacks

I tried this surgical patch on Win2K. As far as I could test, it didn't regress
the earlier bugs.

Comment 12

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Fixed (by removal of overly-complicated code :-), 2004-05-04 16:56 -0700.

Comment 13

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

This seems to have been a measurable pageload time gain (~0.5%).

Comment 14

[rbs]

...meaning it is worthy of 1.7f.