[Webkit-unassigned] [Bug 86557] Allow WebTextFieldDecoratorClient to see applied decorations.

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=86557





--- Comment #10 from Dimitri Glazkov (Google) <dglazkov at chromium.org>  2012-05-16 16:04:15 PST ---
(In reply to comment #9)
> 
> So the second and third point here suggest to me something where ChromeClientImpl asks Chromium if a particular element should be made visible (when the event handler fires). The last point implies that Chromium can change the visibility of the decorator whenever. I'm not sure what I'm missing, but I do think that the Chromium code needs to be able to change the visibility of a decorator at arbitrary times, since in my case the client is not going to know if a decorator should be visible until it gets some information back from the browser process. Assuming we change WebStyledElement -> WebTextFieldDecorator and fix the style propagation issue, the current WebTextFieldDecoratorClient works fine for me. Do you not approve of the interface change to WebTextFieldDecoratorClient, or was there something else you were hoping to get out of this new design?
>

Ah, I see. I've forgotten about the IPC thing. So you need to hold on to WebTextFieldDecorator until you get the data back from the browser process? When would you request this data? addTextFieldDecorationsTo is too early, right?

> > If we need to do something more complex, like reacting when an input element is added or removed from the document tree, you need an accurate signal of when that happens. You can't rely on Chrome::addTextFieldDecorationsTo, since this will be called way too many times (and for most of them, not when you need it). Perhaps a MutationObserver would be useful here.
> 
> I do not think that I need anything more complex. It's possible that eventually I would want this to be able to deal with dynamically generated forms, but first the password manager will need to deal with them.

Great! :)

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.