Summary: | [EFL][DRT] Implement setValueForUser and setAutofilled | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Grzegorz Czajkowski <g.czajkowski> | ||||||
Component: | WebKit EFL | Assignee: | Nobody <webkit-unassigned> | ||||||
Status: | RESOLVED FIXED | ||||||||
Severity: | Normal | CC: | cgarcia, commit-queue, gyuyoung.kim, lucas.de.marchi, morrita, mrobinson, rakuco, webkit.review.bot | ||||||
Priority: | P2 | ||||||||
Version: | 528+ (Nightly build) | ||||||||
Hardware: | All | ||||||||
OS: | Linux | ||||||||
Attachments: |
|
Description
Grzegorz Czajkowski
2012-02-22 06:54:10 PST
Created attachment 128208 [details]
proposed patch
CC'ing developers involved in LayoutTests/DRT Comment on attachment 128208 [details]
proposed patch
Accessing JSValueRef smells wrong. When you notice you're doing it, it will indicate something wrong.
IMHO, what you need is WebKit level API to access WebCore::Element and its autofill methods.
For example, Mac port has DOMElement obj-c class and Chromium has WebElement as a wrapper of WebCore::Element.
I think you need similar for EFL. Just making bot green doesn't help in this case.
Please consult some expert in your team and discuss what is the good API for EFL port.
Point here is that you cannot implement auto-complete feature for your browser with EFL API. You'll need such an API and DRT should demonstrate it. (In reply to comment #4) > Point here is that you cannot implement auto-complete feature for your browser with EFL API. > You'll need such an API and DRT should demonstrate it. DumpRenderTreeSupport is actually a private part of the EFL API that predates WebCore.internals and fulfills much the same purpose. GTK+, Qt, and EFL use it to add private API for the DRT. Comment on attachment 128208 [details] proposed patch (In reply to comment #5) > (In reply to comment #4) > > Point here is that you cannot implement auto-complete feature for your browser with EFL API. > > You'll need such an API and DRT should demonstrate it. > > DumpRenderTreeSupport is actually a private part of the EFL API that predates WebCore.internals and fulfills much the same purpose. GTK+, Qt, and EFL use it to add private API for the DRT. Hmm interesting. In general I understand DumpRenderTree serves such purposes. But for this case, is it making sense to make the test pass even if the port doesn't support the feature? Clearing r- since I realized that I don't have enough understanding of the background context. Comment on attachment 128208 [details]
proposed patch
I added request for the review again.
Martin could you review it because you've already reviewed the similar patch for WebKit-GTK port?
Comment on attachment 128208 [details]
proposed patch
rs=me as this looks like pretty much exactly like the Gtk+ implementation of the same functionality.
Created attachment 128724 [details]
patch for landing
Rebased to head.
Comment on attachment 128724 [details] patch for landing Clearing flags on attachment: 128724 Committed r108806: <http://trac.webkit.org/changeset/108806> All reviewed patches have been landed. Closing bug. |