88453 2012-06-06 14:04:07 -0700 [GTK] [WebKit2] CanHandleRequest API test fails 2013-10-31 03:32:54 -0700 1 1 1 Unclassified WebKit WebKitGTK 528+ (Nightly build) Unspecified Unspecified RESOLVED FIXED P2 Normal --- 1 mrobinson obzhirov cgarcia commit-queue obzhirov oldest_to_newest 642788 0 mrobinson 2012-06-06 14:04:07 -0700 The CanHandleRequest API test fails with the following output on GTK+: [ RUN ] WebKit2.CanHandleRequest ../../Tools/TestWebKitAPI/Tests/WebKit2/CanHandleRequest.cpp:68: Failure Value of: canHandleRequest Actual: false Expected: true 943161 1 obzhirov 2013-10-24 09:24:45 -0700 After investigation: The issue is WebPage::platformCanHandleRequest(const ResourceRequest&) for GTK port always returns true. This doesn't look right since it should return false by default for all unknown schemes. For example, currently the test checks canHandleURL("about:blank") && canHandleURL("emptyscheme://") && !canHandleURL("notascheme://");. First two are handled by WebCore in SchemeRegistry::shouldLoadURLSchemeAsEmptyDocument since "about:blank" is default and "emptyscheme:" was registered. But "notascheme://" is not in the list of known schemes and the call should return false. 943164 2 215072 obzhirov 2013-10-24 09:29:05 -0700 Created attachment 215072 Patch 943465 3 215072 cgarcia 2013-10-25 00:49:56 -0700 Comment on attachment 215072 Patch Are you sure this doesn't break loading custom uri schemes? Please, check it before landing. 943466 4 215072 cgarcia 2013-10-25 00:52:42 -0700 Comment on attachment 215072 Patch In WebKit1 we have always returned true. 943487 5 obzhirov 2013-10-25 01:47:35 -0700 (In reply to comment #4) > (From update of attachment 215072 [details]) > In WebKit1 we have always returned true. Is not it unsafe (In reply to comment #3) > (From update of attachment 215072 [details]) > Are you sure this doesn't break loading custom uri schemes? Please, check it before landing. Are not custom schemes supposed to be registered before loading? 943488 6 obzhirov 2013-10-25 01:50:10 -0700 (In reply to comment #4) > (From update of attachment 215072 [details]) > In WebKit1 we have always returned true. Was it made to support the custom schemes? Please also see my question above. 943530 7 cgarcia 2013-10-25 04:30:18 -0700 (In reply to comment #5) > (In reply to comment #4) > > (From update of attachment 215072 [details] [details]) > > In WebKit1 we have always returned true. > Is not it unsafe > (In reply to comment #3) > > (From update of attachment 215072 [details] [details]) > > Are you sure this doesn't break loading custom uri schemes? Please, check it before landing. > Are not custom schemes supposed to be registered before loading? Ok, I was confused, because the policy checker calls canHandleRequest in the frame loader client, but that one in WebKit2 also returns always true. bool WebFrameLoaderClient::canHandleRequest(const ResourceRequest&) const { notImplemented(); return true; } The one in WebPage is not called by WebCore while loading resources, but only by the injected bundle API, so it shouldn't affect custom uri schemes nor any other thing, except tests using WKBundlePageCanHandleRequest. I wonder why this is handled differently, and also whether we should properly implement it in GTK by checking the schemes registered in the soup session, instead of returning false unconditionally. I think it's not yet possible to register custom uri schemes with the C API in GTK+, so it's probably safe to always return false for now to make the test pass. 943542 8 215072 commit-queue 2013-10-25 04:55:24 -0700 Comment on attachment 215072 Patch Clearing flags on attachment: 215072 Committed r158002: <http://trac.webkit.org/changeset/158002> 943543 9 commit-queue 2013-10-25 04:55:27 -0700 All reviewed patches have been landed. Closing bug. 943553 10 obzhirov 2013-10-25 05:52:01 -0700 (In reply to comment #7) > (In reply to comment #5) > > (In reply to comment #4) > > > (From update of attachment 215072 [details] [details] [details]) > > > In WebKit1 we have always returned true. > > Is not it unsafe > > (In reply to comment #3) > > > (From update of attachment 215072 [details] [details] [details]) > > > Are you sure this doesn't break loading custom uri schemes? Please, check it before landing. > > Are not custom schemes supposed to be registered before loading? > > Ok, I was confused, because the policy checker calls canHandleRequest in the frame loader client, but that one in WebKit2 also returns always true. > > bool WebFrameLoaderClient::canHandleRequest(const ResourceRequest&) const > { > notImplemented(); > return true; > } > > The one in WebPage is not called by WebCore while loading resources, but only by the injected bundle API, so it shouldn't affect custom uri schemes nor any other thing, except tests using WKBundlePageCanHandleRequest. I wonder why this is handled differently, and also whether we should properly implement it in GTK by checking the schemes registered in the soup session, instead of returning false unconditionally. I think it's not yet possible to register custom uri schemes with the C API in GTK+, so it's probably safe to always return false for now to make the test pass. Hm, good point about two version of canHandleRequest APIs. Is WebFrameLoaderClient created for each frame in the document? Regarding registering custom uri schemes for the page - are we planning to have such API in the future? For this and for checking lib soup session schemes I could create a new bug and start investigating options. 945473 11 cgarcia 2013-10-31 02:41:32 -0700 (In reply to comment #10) > (In reply to comment #7) > > (In reply to comment #5) > > > (In reply to comment #4) > > > > (From update of attachment 215072 [details] [details] [details] [details]) > > > > In WebKit1 we have always returned true. > > > Is not it unsafe > > > (In reply to comment #3) > > > > (From update of attachment 215072 [details] [details] [details] [details]) > > > > Are you sure this doesn't break loading custom uri schemes? Please, check it before landing. > > > Are not custom schemes supposed to be registered before loading? > > > > Ok, I was confused, because the policy checker calls canHandleRequest in the frame loader client, but that one in WebKit2 also returns always true. > > > > bool WebFrameLoaderClient::canHandleRequest(const ResourceRequest&) const > > { > > notImplemented(); > > return true; > > } > > > > The one in WebPage is not called by WebCore while loading resources, but only by the injected bundle API, so it shouldn't affect custom uri schemes nor any other thing, except tests using WKBundlePageCanHandleRequest. I wonder why this is handled differently, and also whether we should properly implement it in GTK by checking the schemes registered in the soup session, instead of returning false unconditionally. I think it's not yet possible to register custom uri schemes with the C API in GTK+, so it's probably safe to always return false for now to make the test pass. > > Hm, good point about two version of canHandleRequest APIs. Is WebFrameLoaderClient created for each frame in the document? > > Regarding registering custom uri schemes for the page - are we planning to have such API in the future? For this and for checking lib soup session schemes I could create a new bug and start investigating options. No, we don't plan to add any new C API unless it's required by the tests, since nobody except WTR and unit tests is using the C API of the gtk port. 945479 12 obzhirov 2013-10-31 03:13:48 -0700 (In reply to comment #11) > (In reply to comment #10) > > (In reply to comment #7) > > > (In reply to comment #5) > > > > (In reply to comment #4) > > > > > (From update of attachment 215072 [details] [details] [details] [details] [details]) > > > > > In WebKit1 we have always returned true. > > > > Is not it unsafe > > > > (In reply to comment #3) > > > > > (From update of attachment 215072 [details] [details] [details] [details] [details]) > > > > > Are you sure this doesn't break loading custom uri schemes? Please, check it before landing. > > > > Are not custom schemes supposed to be registered before loading? > > > > > > Ok, I was confused, because the policy checker calls canHandleRequest in the frame loader client, but that one in WebKit2 also returns always true. > > > > > > bool WebFrameLoaderClient::canHandleRequest(const ResourceRequest&) const > > > { > > > notImplemented(); > > > return true; > > > } > > > > > > The one in WebPage is not called by WebCore while loading resources, but only by the injected bundle API, so it shouldn't affect custom uri schemes nor any other thing, except tests using WKBundlePageCanHandleRequest. I wonder why this is handled differently, and also whether we should properly implement it in GTK by checking the schemes registered in the soup session, instead of returning false unconditionally. I think it's not yet possible to register custom uri schemes with the C API in GTK+, so it's probably safe to always return false for now to make the test pass. > > > > Hm, good point about two version of canHandleRequest APIs. Is WebFrameLoaderClient created for each frame in the document? > > > > Regarding registering custom uri schemes for the page - are we planning to have such API in the future? For this and for checking lib soup session schemes I could create a new bug and start investigating options. > > No, we don't plan to add any new C API unless it's required by the tests, since nobody except WTR and unit tests is using the C API of the gtk port. Should we check lib soup session schemes? 945481 13 cgarcia 2013-10-31 03:32:54 -0700 (In reply to comment #12) > (In reply to comment #11) > > (In reply to comment #10) > > > (In reply to comment #7) > > > > (In reply to comment #5) > > > > > (In reply to comment #4) > > > > > > (From update of attachment 215072 [details] [details] [details] [details] [details] [details]) > > > > > > In WebKit1 we have always returned true. > > > > > Is not it unsafe > > > > > (In reply to comment #3) > > > > > > (From update of attachment 215072 [details] [details] [details] [details] [details] [details]) > > > > > > Are you sure this doesn't break loading custom uri schemes? Please, check it before landing. > > > > > Are not custom schemes supposed to be registered before loading? > > > > > > > > Ok, I was confused, because the policy checker calls canHandleRequest in the frame loader client, but that one in WebKit2 also returns always true. > > > > > > > > bool WebFrameLoaderClient::canHandleRequest(const ResourceRequest&) const > > > > { > > > > notImplemented(); > > > > return true; > > > > } > > > > > > > > The one in WebPage is not called by WebCore while loading resources, but only by the injected bundle API, so it shouldn't affect custom uri schemes nor any other thing, except tests using WKBundlePageCanHandleRequest. I wonder why this is handled differently, and also whether we should properly implement it in GTK by checking the schemes registered in the soup session, instead of returning false unconditionally. I think it's not yet possible to register custom uri schemes with the C API in GTK+, so it's probably safe to always return false for now to make the test pass. > > > > > > Hm, good point about two version of canHandleRequest APIs. Is WebFrameLoaderClient created for each frame in the document? > > > > > > Regarding registering custom uri schemes for the page - are we planning to have such API in the future? For this and for checking lib soup session schemes I could create a new bug and start investigating options. > > > > No, we don't plan to add any new C API unless it's required by the tests, since nobody except WTR and unit tests is using the C API of the gtk port. > Should we check lib soup session schemes? Well, CanHandleRequest is only used by this test, and there's no other custom scheme registered in the test. 215072 2013-10-24 09:29:05 -0700 2013-10-25 04:55:24 -0700 Patch bug-88453-20131024172920.patch text/plain 3085 obzhirov U3VidmVyc2lvbiBSZXZpc2lvbjogMTU3OTI5CmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViS2l0Mi9D aGFuZ2VMb2cgYi9Tb3VyY2UvV2ViS2l0Mi9DaGFuZ2VMb2cKaW5kZXggZTIzNmY0N2M1NjQwYzI1 Yzc4NTBlZDc1NTYyZjZjYjQyMjVlOTU1NS4uYjg4M2UwMGJhODk2NGMxZWEzNmIyZjAyNGRjYTIz MTRkYjg5NzJiMyAxMDA2NDQKLS0tIGEvU291cmNlL1dlYktpdDIvQ2hhbmdlTG9nCisrKyBiL1Nv dXJjZS9XZWJLaXQyL0NoYW5nZUxvZwpAQCAtMSwzICsxLDE2IEBACisyMDEzLTEwLTI0ICBBbnRv biBPYnpoaXJvdiAgPGEub2J6aGlyb3ZAc2Ftc3VuZy5jb20+CisKKyAgICAgICAgW0dUS10gW1dl YktpdDJdIENhbkhhbmRsZVJlcXVlc3QgQVBJIHRlc3QgZmFpbHMKKyAgICAgICAgaHR0cHM6Ly9i dWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTg4NDUzCisKKyAgICAgICAgUmV2aWV3ZWQg YnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgTWFrZSBXZWJQYWdlOjpwbGF0Zm9ybUNhbkhh bmRsZVJlcXVlc3QgcmV0dXJuIGZhbHNlIGJ5IGRlZmF1bHQgCisgICAgICAgIGZvciB1bmtub3du IHNjaGVtZXMuCisKKyAgICAgICAgKiBXZWJQcm9jZXNzL1dlYlBhZ2UvZ3RrL1dlYlBhZ2VHdGsu Y3BwOgorICAgICAgICAoV2ViS2l0OjpXZWJQYWdlOjpwbGF0Zm9ybUNhbkhhbmRsZVJlcXVlc3Qp OgorCiAyMDEzLTEwLTIzICBDaGFuZ1Nlb2sgT2ggIDxjaGFuZ3Nlb2sub2hAY29sbGFib3JhLmNv bT4KIAogICAgICAgICBVbnJldmlld2VkIGJ1aWxkIGZpeCBzaW5jZSByMTU3ODIzLgpkaWZmIC0t Z2l0IGEvU291cmNlL1dlYktpdDIvV2ViUHJvY2Vzcy9XZWJQYWdlL2d0ay9XZWJQYWdlR3RrLmNw cCBiL1NvdXJjZS9XZWJLaXQyL1dlYlByb2Nlc3MvV2ViUGFnZS9ndGsvV2ViUGFnZUd0ay5jcHAK aW5kZXggMjc4NWEyNjNiZmM5M2FkZjk1MzYwZGQ2Zjg1NTFjMmM5NjZmYjIwMS4uYmYxMWY0MTVi ODJmMWE0MWM3NTAyNWViN2E3MGZlYzQ4NGZlZGE0NiAxMDA2NDQKLS0tIGEvU291cmNlL1dlYktp dDIvV2ViUHJvY2Vzcy9XZWJQYWdlL2d0ay9XZWJQYWdlR3RrLmNwcAorKysgYi9Tb3VyY2UvV2Vi S2l0Mi9XZWJQcm9jZXNzL1dlYlBhZ2UvZ3RrL1dlYlBhZ2VHdGsuY3BwCkBAIC0xNDEsNyArMTQx LDcgQEAgU3RyaW5nIFdlYlBhZ2U6OmNhY2hlZFJlc3BvbnNlTUlNRVR5cGVGb3JVUkwoY29uc3Qg VVJMJikKIGJvb2wgV2ViUGFnZTo6cGxhdGZvcm1DYW5IYW5kbGVSZXF1ZXN0KGNvbnN0IFJlc291 cmNlUmVxdWVzdCYpCiB7CiAgICAgbm90SW1wbGVtZW50ZWQoKTsKLSAgICByZXR1cm4gdHJ1ZTsK KyAgICByZXR1cm4gZmFsc2U7CiB9CiAKIFN0cmluZyBXZWJQYWdlOjpjYWNoZWRTdWdnZXN0ZWRG aWxlbmFtZUZvclVSTChjb25zdCBVUkwmKQpkaWZmIC0tZ2l0IGEvVG9vbHMvQ2hhbmdlTG9nIGIv VG9vbHMvQ2hhbmdlTG9nCmluZGV4IDBmYzYzY2UwZTMyYWU5NTQ0ZjhhNjJlMTRiYWY0M2NiZWMz YzYxNDkuLmE1MDc2ODBjMGZiOGRiZDQ0ZWM5MGEyOWRmYjczOTNlYThjNzg0ODMgMTAwNjQ0Ci0t LSBhL1Rvb2xzL0NoYW5nZUxvZworKysgYi9Ub29scy9DaGFuZ2VMb2cKQEAgLTEsMyArMSwxMyBA QAorMjAxMy0xMC0yNCAgQW50b24gT2J6aGlyb3YgIDxhLm9iemhpcm92QHNhbXN1bmcuY29tPgor CisgICAgICAgIFtHVEtdIFtXZWJLaXQyXSBDYW5IYW5kbGVSZXF1ZXN0IEFQSSB0ZXN0IGZhaWxz CisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD04ODQ1Mwor CisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAgICogU2NyaXB0 cy9ydW4tZ3RrLXRlc3RzOgorICAgICAgICAoVGVzdFJ1bm5lcik6CisKIDIwMTMtMTAtMjQgIEd5 dXlvdW5nIEtpbSAgPGd5dXlvdW5nLmtpbUBzYW1zdW5nLmNvbT4KIAogICAgICAgICBbR1RLXSBE aXNhYmxlIGNzcy1pbWFnZS1vcmllbnRhdGlvbgpkaWZmIC0tZ2l0IGEvVG9vbHMvU2NyaXB0cy9y dW4tZ3RrLXRlc3RzIGIvVG9vbHMvU2NyaXB0cy9ydW4tZ3RrLXRlc3RzCmluZGV4IDk2OTM3MzQ4 YjYwNmJiYjE5NTViZjNlNjcyMjI0ZDA2M2MwMzc5M2YuLmY3NmE4ZTUyNzFlYmZlOGNmZTQzMmQ3 YTlkOGJkOTQwODVlZjRhZjggMTAwNzU1Ci0tLSBhL1Rvb2xzL1NjcmlwdHMvcnVuLWd0ay10ZXN0 cworKysgYi9Ub29scy9TY3JpcHRzL3J1bi1ndGstdGVzdHMKQEAgLTY5LDcgKzY5LDYgQEAgY2xh c3MgVGVzdFJ1bm5lcjoKICAgICAgICAgU2tpcHBlZFRlc3QoIldlYktpdDJBUElUZXN0cy9UZXN0 UmVzb3VyY2VzIiwgIi93ZWJraXQyL1dlYktpdFdlYlZpZXcvcmVzb3VyY2VzIiwgIlRlc3QgaXMg Zmxha3kgaW4gR1RLIExpbnV4IDMyLWJpdCBSZWxlYXNlIGJvdCIsIDgyODY4KSwKICAgICAgICAg U2tpcHBlZFRlc3QoIldlYktpdDJBUElUZXN0cy9UZXN0V2ViS2l0V2ViVmlldyIsIFNraXBwZWRU ZXN0LkVOVElSRV9TVUlURSwgIlRlc3QgdGltZXMgb3V0IGFmdGVyIHIxNTA4OTAiLCAxMTc2ODkp LAogICAgICAgICBTa2lwcGVkVGVzdCgiV2ViS2l0MkFQSVRlc3RzL1Rlc3RDb250ZXh0TWVudSIs IFNraXBwZWRUZXN0LkVOVElSRV9TVUlURSwgIlRlc3QgdGltZXMgb3V0IGFmdGVyIHIxNTA4OTAi LCAxMTc2ODkpLAotICAgICAgICBTa2lwcGVkVGVzdCgiVGVzdFdlYktpdEFQSS9UZXN0V2ViS2l0 MiIsICJXZWJLaXQyLkNhbkhhbmRsZVJlcXVlc3QiLCAiVGVzdCBmYWlscyIsIDg4NDUzKSwKICAg ICAgICAgU2tpcHBlZFRlc3QoIlRlc3RXZWJLaXRBUEkvVGVzdFdlYktpdDIiLCAiV2ViS2l0Mi5N b3VzZU1vdmVBZnRlckNyYXNoIiwgIlRlc3QgaXMgZmxha3kiLCA4NTA2NiksCiAgICAgICAgIFNr aXBwZWRUZXN0KCJUZXN0V2ViS2l0QVBJL1Rlc3RXZWJLaXQyIiwgIldlYktpdDIuTmV3Rmlyc3RW aXN1YWxseU5vbkVtcHR5TGF5b3V0Rm9ySW1hZ2VzIiwgIlRlc3QgaXMgZmxha3kiLCA4NTA2Niks CiAgICAgICAgIFNraXBwZWRUZXN0KCJUZXN0V2ViS2l0QVBJL1Rlc3RXZWJLaXQyIiwgIldlYktp dDIuTmV3Rmlyc3RWaXN1YWxseU5vbkVtcHR5TGF5b3V0RnJhbWVzIiwgIlRlc3QgZmFpbHMiLCA4 NTAzNyksCg==