[webkit-reviews] review granted: [Bug 6862] Input's value doesn't get updated after typing in new text field : [Attachment 6008] patch

bugzilla-request-daemon at opendarwin.org bugzilla-request-daemon at opendarwin.org
Fri Jan 27 08:44:31 PST 2006


Darin Adler <darin at apple.com> has granted Adele Peterson <adele at apple.com>'s
request for review:
Bug 6862: Input's value doesn't get updated after typing in new text field
http://bugzilla.opendarwin.org/show_bug.cgi?id=6862

Attachment 6008: patch
http://bugzilla.opendarwin.org/attachment.cgi?id=6008&action=edit

------- Additional Comments from Darin Adler <darin at apple.com>
Dave and Maciej were talking about this last night on IRC. They're concerned
that since we have a special optimization for when there are no listeners to
DOM mutation events that adding handlers could cause a speed problem -- and if
this is on any page with a <input type=text> that could be a real problem.

They believe that we need to either:

    1) do measurements to prove that event listeners are OK, performance-wise,
and if so, plan to eventually remove the optimization for "no event listeners
for mutation events on this document"

or

    2) use an ad-hoc scheme other than a mutation listener to address this
requirement: Dave suggested a hook in RenderText I think for this case

Tiny code structure thing: If we end up going with (1), I'd suggest putting the
removeEventListener call in ~RenderTextField inside the same if that's used for
the detach call.

In RenderTextField::subtreeHasChanged, we probably want to use node() rather
than element(). In general, element() is just a slower node() that does
something special for anonymous cases.

Marking this review+, but please do not land until doing the performance tests
because of the DOM event issue. You should discuss this with Dave, Maciej, and
Justin (since Justin is working on a patch that uses mutation events for a
similar purpose).



More information about the webkit-reviews mailing list