Summary: | [EFL][WK2] Add API to deliver a Web Intent to a frame | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Chris Dumez <cdumez> | ||||||
Component: | WebKit2 | Assignee: | Chris Dumez <cdumez> | ||||||
Status: | RESOLVED FIXED | ||||||||
Severity: | Normal | CC: | dglazkov, gyuyoung.kim, kenneth, rakuco, tonikitoo, webkit.review.bot | ||||||
Priority: | P2 | ||||||||
Version: | 528+ (Nightly build) | ||||||||
Hardware: | Unspecified | ||||||||
OS: | Unspecified | ||||||||
Bug Depends on: | 89974 | ||||||||
Bug Blocks: | 90064 | ||||||||
Attachments: |
|
Description
Chris Dumez
2012-06-27 05:00:49 PDT
Created attachment 150394 [details]
Patch
Comment on attachment 150394 [details] Patch Attachment 150394 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/13124216 New failing tests: plugins/iframe-shims.html fast/loader/loadInProgress.html Created attachment 150436 [details]
Archive of layout-test-results from gce-cr-linux-06
The attached test failures were seen while running run-webkit-tests on the chromium-ews.
Bot: gce-cr-linux-06 Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'> Platform: Linux-2.6.39-gcg-201203291735-x86_64-with-Ubuntu-10.04-lucid
Comment on attachment 150394 [details]
Patch
Chromium ews issue is unrelated, setting cq flag again.
Comment on attachment 150394 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=150394&action=review > Source/WebKit2/UIProcess/API/efl/ewk_intent.cpp:199 > +WKIntentDataRef ewk_intent_WKIntentDataRef_get(const Ewk_Intent* intent) > +{ > + EINA_SAFETY_ON_NULL_RETURN_VAL(intent, 0); > + return intent->wkIntent.get(); > +} Does it really make sense to create this as a separate method? > Source/WebKit2/UIProcess/API/efl/ewk_view.h:201 > +EAPI Eina_Bool ewk_view_intent_deliver(Evas_Object *o, Ewk_Intent *intent); I was wondering whether _post would make more sense due to consistency Comment on attachment 150394 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=150394&action=review >> Source/WebKit2/UIProcess/API/efl/ewk_intent.cpp:199 >> +} > > Does it really make sense to create this as a separate method? This is consistent with existing classes, e.g. Ewk_Context: WKContextRef ewk_context_WKContext_get(const Ewk_Context*); I'm not sure how else you want to do it: it is not possible to access struct members from the outside without getter functions() since the structure is defined in the *.cpp. >> Source/WebKit2/UIProcess/API/efl/ewk_view.h:201 >> +EAPI Eina_Bool ewk_view_intent_deliver(Evas_Object *o, Ewk_Intent *intent); > > I was wondering whether _post would make more sense due to consistency Well, the other way around, _deliver() is consistent with what is in WebCore: DOMWindowIntents::deliver(), and according to the W3C spec which mentions several times "deliver the intent". The spec, however, uses _post() for posting the result of a Web Intent. One reason I could see for the distinction is that _post() seems to involve DOM events while intent delivery does not (it merely populates the window.intent attribute). OK, thanks for the explanation Comment on attachment 150394 [details] Patch Clearing flags on attachment: 150394 Committed r121733: <http://trac.webkit.org/changeset/121733> All reviewed patches have been landed. Closing bug. |