Bug 140429

Summary: [GTK] Fix build after r178385
Product: WebKit Reporter: Hunseop Jeong <hs85.jeong>
Component: WebKitGTKAssignee: Hunseop Jeong <hs85.jeong>
Status: RESOLVED FIXED    
Severity: Normal CC: berto, cdumez, cgarcia, clopez, commit-queue, gustavo, mitz, mrobinson, ossy, sam, yoon
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on:    
Bug Blocks: 140414    
Attachments:
Description Flags
Patch
none
Patch
none
Patch commit-queue: commit-queue-

Description Hunseop Jeong 2015-01-13 22:31:16 PST
../../Source/WebKit2/UIProcess/API/gtk/WebKitLoaderClient.cpp:44:10: error: ‘void LoaderClient::didStartProvisionalLoadForFrame(WebKit::WebPageProxy&, WebKit::WebFrameProxy&, uint64_t, API::Object*)’ marked override, but does not override
     void didStartProvisionalLoadForFrame(WebPageProxy&, WebFrameProxy& frame, uint64_t /* navigationID */, API::Object* /* userData */) override
          ^
../../Source/WebKit2/UIProcess/API/gtk/WebKitLoaderClient.cpp:51:10: error: ‘void LoaderClient::didReceiveServerRedirectForProvisionalLoadForFrame(WebKit::WebPageProxy&, WebKit::WebFrameProxy&, uint64_t, API::Object*)’ marked override, but does not override
     void didReceiveServerRedirectForProvisionalLoadForFrame(WebPageProxy&, WebFrameProxy& frame, uint64_t /* navigationID */, API::Object* /* userData */) override
          ^
../../Source/WebKit2/UIProcess/API/gtk/WebKitLoaderClient.cpp:58:10: error: ‘void LoaderClient::didFailProvisionalLoadWithErrorForFrame(WebKit::WebPageProxy&, WebKit::WebFrameProxy&, uint64_t, const WebCore::ResourceError&, API::Object*)’ marked override, but does not override
     void didFailProvisionalLoadWithErrorForFrame(WebPageProxy&, WebFrameProxy& frame, uint64_t /* navigationID */, const ResourceError& resourceError, API::Object* /* userData */) override
          ^
../../Source/WebKit2/UIProcess/API/gtk/WebKitLoaderClient.cpp:71:10: error: ‘void LoaderClient::didCommitLoadForFrame(WebKit::WebPageProxy&, WebKit::WebFrameProxy&, uint64_t, API::Object*)’ marked override, but does not override
     void didCommitLoadForFrame(WebPageProxy&, WebFrameProxy& frame, uint64_t /* navigationID */, API::Object* /* userData */) override
          ^
../../Source/WebKit2/UIProcess/API/gtk/WebKitLoaderClient.cpp:78:10: error: ‘void LoaderClient::didFinishLoadForFrame(WebKit::WebPageProxy&, WebKit::WebFrameProxy&, uint64_t, API::Object*)’ marked override, but does not override
     void didFinishLoadForFrame(WebPageProxy&, WebFrameProxy& frame, uint64_t /* navigationID */, API::Object* /* userData */) override
          ^
../../Source/WebKit2/UIProcess/API/gtk/WebKitLoaderClient.cpp:85:10: error: ‘void LoaderClient::didFailLoadWithErrorForFrame(WebKit::WebPageProxy&, WebKit::WebFrameProxy&, uint64_t, const WebCore::ResourceError&, API::Object*)’ marked override, but does not override
     void didFailLoadWithErrorForFrame(WebPageProxy&, WebFrameProxy& frame, uint64_t /* navigationID */, const ResourceError& resourceError, API::Object* /* userData */) override
          ^
Comment 1 Hunseop Jeong 2015-01-13 22:33:56 PST
Created attachment 244582 [details]
Patch
Comment 2 WebKit Commit Bot 2015-01-13 22:35:15 PST
Thanks for the patch. If this patch contains new public API please make sure it follows the guidelines for new WebKit2 GTK+ API. See http://trac.webkit.org/wiki/WebKitGTK/AddingNewWebKit2API
Comment 3 Hunseop Jeong 2015-01-13 22:40:23 PST
It is a wrong patch,, I have to look more,,
Comment 4 Chris Dumez 2015-01-13 22:50:36 PST
I have just landed a speculative fix for this one.
Comment 5 Chris Dumez 2015-01-13 22:59:44 PST
I haven't fixed this one though:
Source/WebKit2/CMakeFiles/WebKit2.dir/UIProcess/API/gtk/WebKitUserContentManager.cpp.o -c ../../Source/WebKit2/UIProcess/API/gtk/WebKitUserContentManager.cpp
../../Source/WebKit2/UIProcess/API/gtk/WebKitUserContentManager.cpp: In constructor ‘_WebKitUserContentManagerPrivate::_WebKitUserContentManagerPrivate()’:
../../Source/WebKit2/UIProcess/API/gtk/WebKitUserContentManager.cpp:37:33: error: ‘create’ is not a member of ‘WebKit::WebUserContentControllerProxy’
         : userContentController(WebUserContentControllerProxy::create())
                                 ^
This was broken by https://bugs.webkit.org/show_bug.cgi?id=140414. I'll let you take a look at it as I don't have a GTK build.
Comment 6 Chris Dumez 2015-01-13 23:02:15 PST
For reference, here are my speculative GTK build fixes:
https://trac.webkit.org/r178395
https://trac.webkit.org/r178408
https://trac.webkit.org/r178409
Comment 7 Hunseop Jeong 2015-01-13 23:43:52 PST
Created attachment 244585 [details]
Patch
Comment 8 Csaba Osztrogonác 2015-01-14 00:03:10 PST
Comment on attachment 244585 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=244585&action=review

> Source/WebKit2/ChangeLog:3
> +        [GTK] Fix build after r178375  

do you mean r178385?
Comment 9 Csaba Osztrogonác 2015-01-14 00:06:10 PST
Comment on attachment 244585 [details]
Patch

rs=me with fixing the changelog
Comment 10 Hunseop Jeong 2015-01-14 00:09:31 PST
(In reply to comment #8)
> Comment on attachment 244585 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=244585&action=review
> 
> > Source/WebKit2/ChangeLog:3
> > +        [GTK] Fix build after r178375  
> 
> do you mean r178385?

Oops,, Yes , I mean r178385. Thanks,
Comment 11 Hunseop Jeong 2015-01-14 00:19:51 PST
Created attachment 244587 [details]
Patch
Comment 12 Csaba Osztrogonác 2015-01-14 00:48:06 PST
Somebody else fixed by http://trac.webkit.org/changeset/178412
Comment 13 Csaba Osztrogonác 2015-01-14 00:51:25 PST
Could you coordinate in the future to avoid parallel working?
The simplest way is to add the new bug url to the original bug.
Comment 14 Gwang Yoon Hwang 2015-01-14 00:56:29 PST
Sorry for duplicated work. I didn't know that build fix was in progress.
Comment 15 Carlos Garcia Campos 2015-01-14 00:59:23 PST
Thank you all for the build fixes.
Comment 16 Gwang Yoon Hwang 2015-01-14 01:29:35 PST
(In reply to comment #11)
> Created attachment 244587 [details]
> Patch

Could you re-apply this patch to the trunk?
I mis-readed the code. APIObject is refcounted, so it is correct to use adoptRef for WebUserContentManager.
Comment 17 Carlos Garcia Campos 2015-01-14 01:48:51 PST
(In reply to comment #16)
> (In reply to comment #11)
> > Created attachment 244587 [details]
> > Patch
> 
> Could you re-apply this patch to the trunk?
> I mis-readed the code. APIObject is refcounted, so it is correct to use
> adoptRef for WebUserContentManager.

Shouldn't we add the create method again instead? I think it was removed only because mac no uses a different way to allocate the object but we still need it
Comment 18 Carlos Garcia Campos 2015-01-14 02:15:51 PST
Reopening to land the right fix
Comment 19 WebKit Commit Bot 2015-01-14 02:18:39 PST
Comment on attachment 244587 [details]
Patch

Rejecting attachment 244587 [details] from commit-queue.

Failed to run "['/Volumes/Data/EWS/WebKit/Tools/Scripts/webkit-patch', '--status-host=webkit-queues.appspot.com', '--bot-id=webkit-cq-02', 'apply-attachment', '--no-update', '--non-interactive', 244587, '--port=mac']" exit_code: 2 cwd: /Volumes/Data/EWS/WebKit

Last 500 characters of output:
orce']" exit_code: 1 cwd: /Volumes/Data/EWS/WebKit

Parsed 2 diffs from patch file(s).
patching file Source/WebKit2/ChangeLog
Hunk #1 succeeded at 1 with fuzz 3.
patching file Source/WebKit2/UIProcess/API/gtk/WebKitUserContentManager.cpp
Hunk #1 FAILED at 34.
1 out of 1 hunk FAILED -- saving rejects to file Source/WebKit2/UIProcess/API/gtk/WebKitUserContentManager.cpp.rej

Failed to run "[u'/Volumes/Data/EWS/WebKit/Tools/Scripts/svn-apply', '--force']" exit_code: 1 cwd: /Volumes/Data/EWS/WebKit

Full output: http://webkit-queues.appspot.com/results/4847328368263168
Comment 20 Carlos Garcia Campos 2015-01-14 02:22:06 PST
Committed r178417: <http://trac.webkit.org/changeset/178417>