216123 2020-09-03 06:24:50 -0700 [GTK][WPE] WEBKIT_PLUGIN_ERROR_WILL_HANDLE_LOAD returned when plugins are disabled 2020-11-10 00:57:13 -0800 1 1 1 Unclassified WebKit WebKitGTK WebKit Nightly Build PC Linux RESOLVED FIXED P2 Normal --- 1 mcatanzaro webkit-unassigned aperez berto bugs-noreply cgarcia darin ews-watchlist gustavo mcatanzaro oldest_to_newest 1685244 0 mcatanzaro 2020-09-03 06:24:50 -0700 To reproduce, check out this Epiphany commit: https://gitlab.gnome.org/GNOME/epiphany/-/commit/868de06fca4018bb5eaf61bed8dd8c952e813ec2 Then try to play this video: https://gnome.modular.im/_matrix/media/r0/download/gnome.modular.im/c7fc680ae099cbd40063a50c81c944a9e26c4922/Peek Using WebKitGTK 2.29.91, the load will fail with WEBKIT_PLUGIN_ERROR_WILL_HANDLE_LOAD. But Epiphany unconditionally sets enable-plugins to FALSE, so this should be impossible. It fails the same way with WebKit trunk, where WebKitPluginError is deprecated and plugin support has been totally removed. 1686923 1 cgarcia 2020-09-09 01:31:10 -0700 So, the problem here is that pluginWillHandleLoadError has nothing to do with plugins, at least with NPAPI plugins. The error happens when the document is a media document, and the load will be handled by the media engine. 1686924 2 cgarcia 2020-09-09 01:45:36 -0700 I'm not sure how to fix this in a backwards compatibility way. Good thing is that error codes are unique even for different domains, so we could add a new error to the policy domain, for example, using the same error code as pluginWillHandleLoadError. Applications just checking the error code would still work, but not the ones also checking the domain. 1686925 3 cgarcia 2020-09-09 01:49:48 -0700 A quick search in debian shows that only cog and epiphany check the domain. Epiphany would still work as long as the new error is added to network or policy domains, and cog would break because it uses g_error_matches(). 1686926 4 cgarcia 2020-09-09 01:53:19 -0700 We can also un-deprecate the plugin error domain and only deprecate the individual error codes, except the WEBKIT_PLUGIN_ERROR_WILL_HANDLE_LOAD and document this is about media engine handle the load. It would still be confusing, but backwards compatible. 1686952 5 mcatanzaro 2020-09-09 06:25:37 -0700 Do we really need to return any error at all? It looks like what happens is: 1. We emit load-failed with WEBKIT_PLUGIN_ERROR_WILL_HANDLE_LOAD 2. Epiphany ignores the error. 3. WebKit loads the content properly. The error seems superfluous, right? Does it really need to be exposed to the browser? Why does load-failed happen at all? Seems like we could skip that step? 1686953 6 cgarcia 2020-09-09 06:31:33 -0700 (In reply to Michael Catanzaro from comment #5) > Do we really need to return any error at all? It looks like what happens is: > > 1. We emit load-failed with WEBKIT_PLUGIN_ERROR_WILL_HANDLE_LOAD > 2. Epiphany ignores the error. > 3. WebKit loads the content properly. > > The error seems superfluous, right? Does it really need to be exposed to the > browser? Why does load-failed happen at all? Seems like we could skip that > step? I also thought about that, I don't think any app really want to handle the error, but the same applies to WEBKIT_POLICY_ERROR_FRAME_LOAD_INTERRUPTED_BY_POLICY_CHANGE and WEBKIT_NETWORK_ERROR_CANCELLED, I guess, but ephy is handling WEBKIT_POLICY_ERROR_FRAME_LOAD_INTERRUPTED_BY_POLICY_CHANGE to close the tab when there's just a download, I think. The alternative is to not emit load-failed, but the load didn't really succeed either. 1686960 7 mcatanzaro 2020-09-09 07:14:38 -0700 I added debug. What happens with WebKit trunk is: ** (epiphany:26619): WARNING **: 08:54:24.839: LOAD STARTED: https://gnome.modular.im/_matrix/media/r0/download/gnome.modular.im/c7fc680ae099cbd40063a50c81c944a9e26c4922/Peek ** (epiphany:26619): WARNING **: 08:54:25.524: LOAD COMMITTED: https://gnome.modular.im/_matrix/media/r0/download/gnome.modular.im/c7fc680ae099cbd40063a50c81c944a9e26c4922/Peek ** (epiphany:26619): WARNING **: 08:54:26.577: LOAD FAILED: https://gnome.modular.im/_matrix/media/r0/download/gnome.modular.im/c7fc680ae099cbd40063a50c81c944a9e26c4922/Peek ** (epiphany:26619): WARNING **: 08:54:26.578: LOAD FINISHED: https://gnome.modular.im/_matrix/media/r0/download/gnome.modular.im/c7fc680ae099cbd40063a50c81c944a9e26c4922/Peek ** (epiphany:26619): WARNING **: 08:54:26.582: LOAD STARTED: https://gnome.modular.im/_matrix/media/r0/download/gnome.modular.im/c7fc680ae099cbd40063a50c81c944a9e26c4922/Peek ** (epiphany:26619): WARNING **: 08:54:26.591: LOAD COMMITTED: https://gnome.modular.im/_matrix/media/r0/download/gnome.modular.im/c7fc680ae099cbd40063a50c81c944a9e26c4922/Peek ** (epiphany:26619): WARNING **: 08:54:26.592: LOAD FINISHED: https://gnome.modular.im/_matrix/media/r0/download/gnome.modular.im/c7fc680ae099cbd40063a50c81c944a9e26c4922/Peek So: we start load, fail load, finish load, then do it all over. With WebKitGTK 2.29.92, WebKit displays the media controls, but the media controls are broken and unable to actually play the media due to bug #183259. That's the behavior we want to get back to. But with WebKitGTK trunk, Epiphany displays an error: "Plug-in handled load." That's a WebKit error page, though, not the fancy Epiphany error page. If I check out Epiphany commit https://gitlab.gnome.org/GNOME/epiphany/-/commit/868de06fca4018bb5eaf61bed8dd8c952e813ec2 then I get the same with a fancy Epiphany error page. So just changing the error domain will not be enough to fix this bug, because something else is wrong inside WebKit. I tried this: diff --git a/Source/WebKit/UIProcess/API/glib/WebKitWebView.cpp b/Source/WebKit/UIProcess/API/glib/WebKitWebView.cpp index 191007b6bb66..bb6c1618fbe5 100644 --- a/Source/WebKit/UIProcess/API/glib/WebKitWebView.cpp +++ b/Source/WebKit/UIProcess/API/glib/WebKitWebView.cpp @@ -470,7 +470,8 @@ void WebKitWebViewClient::didReceiveUserMessage(WKWPE::View&, UserMessage&& mess static gboolean webkitWebViewLoadFail(WebKitWebView* webView, WebKitLoadEvent, const char* failingURI, GError* error) { if (g_error_matches(error, WEBKIT_NETWORK_ERROR, WEBKIT_NETWORK_ERROR_CANCELLED) - || g_error_matches(error, WEBKIT_POLICY_ERROR, WEBKIT_POLICY_ERROR_FRAME_LOAD_INTERRUPTED_BY_POLICY_CHANGE)) + || g_error_matches(error, WEBKIT_POLICY_ERROR, WEBKIT_POLICY_ERROR_FRAME_LOAD_INTERRUPTED_BY_POLICY_CHANGE) + || g_error_matches(error, WEBKIT_POLICY_ERROR, WEBKIT_PLUGIN_ERROR_WILL_HANDLE_LOAD)) return FALSE; GUniquePtr<char> htmlString(g_strdup_printf("<html><body>%s</body></html>", error->message)); But that wasn't enough to make it work. I think desired behavior would be load started -> load committed -> load finished, once, without any errors. But on the other hand, I'm also aware that attempting to paper over internal WebKit loader behavior at the API level has caused very tricky bugs in the past, so it's probably risky to try changing that. 1686973 8 cgarcia 2020-09-09 08:27:21 -0700 (In reply to Michael Catanzaro from comment #7) > I added debug. What happens with WebKit trunk is: > > ** (epiphany:26619): WARNING **: 08:54:24.839: LOAD STARTED: > https://gnome.modular.im/_matrix/media/r0/download/gnome.modular.im/ > c7fc680ae099cbd40063a50c81c944a9e26c4922/Peek > > ** (epiphany:26619): WARNING **: 08:54:25.524: LOAD COMMITTED: > https://gnome.modular.im/_matrix/media/r0/download/gnome.modular.im/ > c7fc680ae099cbd40063a50c81c944a9e26c4922/Peek > > ** (epiphany:26619): WARNING **: 08:54:26.577: LOAD FAILED: > https://gnome.modular.im/_matrix/media/r0/download/gnome.modular.im/ > c7fc680ae099cbd40063a50c81c944a9e26c4922/Peek > > ** (epiphany:26619): WARNING **: 08:54:26.578: LOAD FINISHED: > https://gnome.modular.im/_matrix/media/r0/download/gnome.modular.im/ > c7fc680ae099cbd40063a50c81c944a9e26c4922/Peek > > ** (epiphany:26619): WARNING **: 08:54:26.582: LOAD STARTED: > https://gnome.modular.im/_matrix/media/r0/download/gnome.modular.im/ > c7fc680ae099cbd40063a50c81c944a9e26c4922/Peek > > ** (epiphany:26619): WARNING **: 08:54:26.591: LOAD COMMITTED: > https://gnome.modular.im/_matrix/media/r0/download/gnome.modular.im/ > c7fc680ae099cbd40063a50c81c944a9e26c4922/Peek > > ** (epiphany:26619): WARNING **: 08:54:26.592: LOAD FINISHED: > https://gnome.modular.im/_matrix/media/r0/download/gnome.modular.im/ > c7fc680ae099cbd40063a50c81c944a9e26c4922/Peek > > So: we start load, fail load, finish load, then do it all over. With > WebKitGTK 2.29.92, WebKit displays the media controls, but the media > controls are broken and unable to actually play the media due to bug > #183259. That's the behavior we want to get back to. But with WebKitGTK > trunk, Epiphany displays an error: "Plug-in handled load." Yes, because you stopped handling that error in ephy. > That's a WebKit > error page, though, not the fancy Epiphany error page. Yes, because you stopped handling that error in ephy, the default handler is called and it shows the default error page, because WebKit also stopped handling that error in the default handler. > If I check out > Epiphany commit > https://gitlab.gnome.org/GNOME/epiphany/-/commit/ > 868de06fca4018bb5eaf61bed8dd8c952e813ec2 then I get the same with a fancy > Epiphany error page. So just changing the error domain will not be enough to > fix this bug, because something else is wrong inside WebKit. I tried this: I meant adding a new error with the same code, but different domain, that needs to be handled by ephy. Ephy returns early if error domain is not network or policy, then it handles errors individually. If we add the new error to network or policy and ephy keeps current code just adding the new error it should just work. > diff --git a/Source/WebKit/UIProcess/API/glib/WebKitWebView.cpp > b/Source/WebKit/UIProcess/API/glib/WebKitWebView.cpp > index 191007b6bb66..bb6c1618fbe5 100644 > --- a/Source/WebKit/UIProcess/API/glib/WebKitWebView.cpp > +++ b/Source/WebKit/UIProcess/API/glib/WebKitWebView.cpp > @@ -470,7 +470,8 @@ void > WebKitWebViewClient::didReceiveUserMessage(WKWPE::View&, UserMessage&& mess > static gboolean webkitWebViewLoadFail(WebKitWebView* webView, > WebKitLoadEvent, const char* failingURI, GError* error) > { > if (g_error_matches(error, WEBKIT_NETWORK_ERROR, > WEBKIT_NETWORK_ERROR_CANCELLED) > - || g_error_matches(error, WEBKIT_POLICY_ERROR, > WEBKIT_POLICY_ERROR_FRAME_LOAD_INTERRUPTED_BY_POLICY_CHANGE)) > + || g_error_matches(error, WEBKIT_POLICY_ERROR, > WEBKIT_POLICY_ERROR_FRAME_LOAD_INTERRUPTED_BY_POLICY_CHANGE) > + || g_error_matches(error, WEBKIT_POLICY_ERROR, > WEBKIT_PLUGIN_ERROR_WILL_HANDLE_LOAD)) > return FALSE; > > GUniquePtr<char> > htmlString(g_strdup_printf("<html><body>%s</body></html>", error->message)); > > But that wasn't enough to make it work. Because the patch is wrong, you are using WEBKIT_POLICY_ERROR domains for the WEBKIT_PLUGIN_ERROR_WILL_HANDLE_LOAD error. > I think desired behavior would be load started -> load committed -> load > finished, once, without any errors. But on the other hand, I'm also aware > that attempting to paper over internal WebKit loader behavior at the API > level has caused very tricky bugs in the past, so it's probably risky to try > changing that. 1686991 9 mcatanzaro 2020-09-09 09:11:43 -0700 (In reply to Carlos Garcia Campos from comment #8) > I meant adding a new error with the same code, but different domain, that > needs to be handled by ephy. Ephy returns early if error domain is not > network or policy, then it handles errors individually. If we add the new > error to network or policy and ephy keeps current code just adding the new > error it should just work. It's not enough. I tested this with and without the Ephy patch and it was broken with WebKit trunk either way. (But 2.29.92 is fine, without the Ephy patch.) > Because the patch is wrong, you are using WEBKIT_POLICY_ERROR domains for > the WEBKIT_PLUGIN_ERROR_WILL_HANDLE_LOAD error. Ah, oops. :P That explains it. So with that portion of r265753 reverted *properly*, then it works again. (Well, it "works" ignoring bug #183259.) So we just need to remember to change that as well if we change the error type. 1686995 10 cgarcia 2020-09-09 09:20:31 -0700 (In reply to Michael Catanzaro from comment #9) > (In reply to Carlos Garcia Campos from comment #8) > > I meant adding a new error with the same code, but different domain, that > > needs to be handled by ephy. Ephy returns early if error domain is not > > network or policy, then it handles errors individually. If we add the new > > error to network or policy and ephy keeps current code just adding the new > > error it should just work. > > It's not enough. I tested this with and without the Ephy patch and it was > broken with WebKit trunk either way. (But 2.29.92 is fine, without the Ephy > patch.) Because we haven't added the new error that ephy should be handling instead. Anyway, we should handle the error in webkit default handler too, in that case, current ephy code should work, since it returns FALSE to let the default handler run. > > Because the patch is wrong, you are using WEBKIT_POLICY_ERROR domains for > > the WEBKIT_PLUGIN_ERROR_WILL_HANDLE_LOAD error. > > Ah, oops. :P That explains it. So with that portion of r265753 reverted > *properly*, then it works again. (Well, it "works" ignoring bug #183259.) So > we just need to remember to change that as well if we change the error type. Yes, it was a mistake to stop handling the error in the default handler, because I also assumed it was a NPAPI plugin error, so I'll bring it back. 1702053 11 mcatanzaro 2020-10-27 13:35:18 -0700 Hm, we still need to do something here: [132/276] Compiling C object embed/libephyembed.a.p/ephy-web-view.c.o ../../../../Projects/epiphany/embed/ephy-web-view.c: In function ‘load_failed_cb’: ../../../../Projects/epiphany/embed/ephy-web-view.c:2297:7: warning: ‘webkit_plugin_error_quark’ is deprecated [-Wdeprecated-declarations] 2297 | error->domain != WEBKIT_PLUGIN_ERROR) { | ^~~~~ In file included from /home/mcatanzaro/Projects/GNOME/install/include/webkitgtk-4.0/webkit2/webkit2.h:46, from ../../../../Projects/epiphany/embed/ephy-web-view.h:24, from ../../../../Projects/epiphany/embed/ephy-web-view.c:23: /home/mcatanzaro/Projects/GNOME/install/include/webkitgtk-4.0/webkit2/WebKitError.h:164:1: note: declared here 164 | webkit_plugin_error_quark (void); | ^~~~~~~~~~~~~~~~~~~~~~~~~ But we cannot remove this code due to this bug. Easiest solution is to un-deprecate the API. 1705153 12 413410 cgarcia 2020-11-06 00:46:47 -0800 Created attachment 413410 Patch 1705154 13 ews-watchlist 2020-11-06 00:47:46 -0800 Thanks for the patch. If this patch contains new public API please make sure it follows the guidelines for new WebKit2 GTK+ API. See https://trac.webkit.org/wiki/WebKitGTK/AddingNewWebKit2API 1705244 14 413410 mcatanzaro 2020-11-06 08:03:10 -0800 Comment on attachment 413410 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=413410&action=review LGTM > Source/WebKit/UIProcess/API/gtk/WebKitError.h:84 > + * @WEBKIT_PLUGIN_ERROR_WILL_HANDLE_LOAD: Load failure since media player handles the load. Perhaps: "Preliminary load failure for media content types. A new load will be started to perform the media load." Or something like that. It's pretty confusing that the initial load failure gets exposed at the API level, but papering over that seems dangerous, so oh well. 1706016 15 cgarcia 2020-11-10 00:57:13 -0800 Committed r269618: <https://trac.webkit.org/changeset/269618> 413410 2020-11-06 00:46:47 -0800 2020-11-06 07:05:28 -0800 Patch wk2-plugin-handles-load.diff text/plain 4195 cgarcia ZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJLaXQvQ2hhbmdlTG9nIGIvU291cmNlL1dlYktpdC9DaGFu Z2VMb2cKaW5kZXggNGQ1NWQzYmU0MTFkLi4yZTYwZGY4ZmM0OWEgMTAwNjQ0Ci0tLSBhL1NvdXJj ZS9XZWJLaXQvQ2hhbmdlTG9nCisrKyBiL1NvdXJjZS9XZWJLaXQvQ2hhbmdlTG9nCkBAIC0xLDMg KzEsMTcgQEAKKzIwMjAtMTEtMDYgIENhcmxvcyBHYXJjaWEgQ2FtcG9zICA8Y2dhcmNpYUBpZ2Fs aWEuY29tPgorCisgICAgICAgIFtHVEtdW1dQRV0gV0VCS0lUX1BMVUdJTl9FUlJPUl9XSUxMX0hB TkRMRV9MT0FEIHJldHVybmVkIHdoZW4gcGx1Z2lucyBhcmUgZGlzYWJsZWQKKyAgICAgICAgaHR0 cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTIxNjEyMworCisgICAgICAgIFJl dmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAgIFVuZGVwcmVjYXRlIHdlYmtpdF9w bHVnaW5fZXJyb3JfcXVhcmsgYW5kIFdFQktJVF9QTFVHSU5fRVJST1JfV0lMTF9IQU5ETEVfTE9B RCwgYW5kIHVwZGF0ZSBkb2N1bWVudGF0aW9uLgorCisgICAgICAgICogVUlQcm9jZXNzL0FQSS9n bGliL1dlYktpdFdlYlZpZXcuY3BwOgorICAgICAgICAod2Via2l0V2ViVmlld0xvYWRGYWlsKToK KyAgICAgICAgKiBVSVByb2Nlc3MvQVBJL2d0ay9XZWJLaXRFcnJvci5oOgorICAgICAgICAqIFVJ UHJvY2Vzcy9BUEkvd3BlL1dlYktpdEVycm9yLmg6CisKIDIwMjAtMTEtMDUgIEJyZW50IEZ1bGdo YW0gIDxiZnVsZ2hhbUBhcHBsZS5jb20+CiAKICAgICAgICAgW21hY09TXSBSZW1vdmUgbWRuc3Jl c3BvbmRlciBhY2Nlc3MgZnJvbSBXZWJLaXQgcHJvY2Vzc2VzCmRpZmYgLS1naXQgYS9Tb3VyY2Uv V2ViS2l0L1VJUHJvY2Vzcy9BUEkvZ2xpYi9XZWJLaXRXZWJWaWV3LmNwcCBiL1NvdXJjZS9XZWJL aXQvVUlQcm9jZXNzL0FQSS9nbGliL1dlYktpdFdlYlZpZXcuY3BwCmluZGV4IDU5ZmVhYWQ1NTk5 ZS4uYjNjN2MwODI3NzQ3IDEwMDY0NAotLS0gYS9Tb3VyY2UvV2ViS2l0L1VJUHJvY2Vzcy9BUEkv Z2xpYi9XZWJLaXRXZWJWaWV3LmNwcAorKysgYi9Tb3VyY2UvV2ViS2l0L1VJUHJvY2Vzcy9BUEkv Z2xpYi9XZWJLaXRXZWJWaWV3LmNwcApAQCAtNDcwLDYgKzQ3MCw3IEBAIHZvaWQgV2ViS2l0V2Vi Vmlld0NsaWVudDo6ZGlkUmVjZWl2ZVVzZXJNZXNzYWdlKFdLV1BFOjpWaWV3JiwgVXNlck1lc3Nh Z2UmJiBtZXNzCiBzdGF0aWMgZ2Jvb2xlYW4gd2Via2l0V2ViVmlld0xvYWRGYWlsKFdlYktpdFdl YlZpZXcqIHdlYlZpZXcsIFdlYktpdExvYWRFdmVudCwgY29uc3QgY2hhciogZmFpbGluZ1VSSSwg R0Vycm9yKiBlcnJvcikKIHsKICAgICBpZiAoZ19lcnJvcl9tYXRjaGVzKGVycm9yLCBXRUJLSVRf TkVUV09SS19FUlJPUiwgV0VCS0lUX05FVFdPUktfRVJST1JfQ0FOQ0VMTEVEKQorICAgICAgICB8 fCBnX2Vycm9yX21hdGNoZXMoZXJyb3IsIFdFQktJVF9QTFVHSU5fRVJST1IsIFdFQktJVF9QTFVH SU5fRVJST1JfV0lMTF9IQU5ETEVfTE9BRCkKICAgICAgICAgfHwgZ19lcnJvcl9tYXRjaGVzKGVy cm9yLCBXRUJLSVRfUE9MSUNZX0VSUk9SLCBXRUJLSVRfUE9MSUNZX0VSUk9SX0ZSQU1FX0xPQURf SU5URVJSVVBURURfQllfUE9MSUNZX0NIQU5HRSkpCiAgICAgICAgIHJldHVybiBGQUxTRTsKIApk aWZmIC0tZ2l0IGEvU291cmNlL1dlYktpdC9VSVByb2Nlc3MvQVBJL2d0ay9XZWJLaXRFcnJvci5o IGIvU291cmNlL1dlYktpdC9VSVByb2Nlc3MvQVBJL2d0ay9XZWJLaXRFcnJvci5oCmluZGV4IDc5 OTk0NmRjODY2My4uMzMxM2QyZjdlNDk3IDEwMDY0NAotLS0gYS9Tb3VyY2UvV2ViS2l0L1VJUHJv Y2Vzcy9BUEkvZ3RrL1dlYktpdEVycm9yLmgKKysrIGIvU291cmNlL1dlYktpdC9VSVByb2Nlc3Mv QVBJL2d0ay9XZWJLaXRFcnJvci5oCkBAIC04MSw5ICs4MSw5IEBAIHR5cGVkZWYgZW51bSB7CiAg KiBAV0VCS0lUX1BMVUdJTl9FUlJPUl9DQU5OT1RfTE9BRF9QTFVHSU46IExvYWQgZmFpbHVyZSBk dWUgdG8gaW5hYmlsaXR5IHRvIGxvYWQgcGx1Z2luLiBEZXByZWNhdGVkIDIuMzIKICAqIEBXRUJL SVRfUExVR0lOX0VSUk9SX0pBVkFfVU5BVkFJTEFCTEU6IExvYWQgZmFpbHVyZSBkdWUgdG8gbWlz c2luZyBKYXZhIHN1cHBvcnQgdGhhdCBpcyByZXF1aXJlZCB0byBsb2FkIHBsdWdpbi4gRGVwcmVj YXRlZCAyLjMyCiAgKiBAV0VCS0lUX1BMVUdJTl9FUlJPUl9DT05ORUNUSU9OX0NBTkNFTExFRDog TG9hZCBmYWlsdXJlIGR1ZSB0byBjb25uZWN0aW9uIGNhbmNlbGxhdGlvbi4gRGVwcmVjYXRlZCAy LjMyCi0gKiBAV0VCS0lUX1BMVUdJTl9FUlJPUl9XSUxMX0hBTkRMRV9MT0FEOiBMb2FkIGZhaWx1 cmUgc2luY2UgcGx1Z2luIGhhbmRsZXMgdGhlIGxvYWQuIERlcHJlY2F0ZWQgMi4zMgorICogQFdF QktJVF9QTFVHSU5fRVJST1JfV0lMTF9IQU5ETEVfTE9BRDogTG9hZCBmYWlsdXJlIHNpbmNlIG1l ZGlhIHBsYXllciBoYW5kbGVzIHRoZSBsb2FkLgogICoKLSAqIEVudW0gdmFsdWVzIHVzZWQgdG8g ZGVub3RlIHRoZSB2YXJpb3VzIHBsdWdpbiBlcnJvcnMuCisgKiBFbnVtIHZhbHVlcyB1c2VkIHRv IGRlbm90ZSB0aGUgdmFyaW91cyBwbHVnaW4gYW5kIG11bHRpbWVkaWEgZXJyb3JzLgogICoqLwog dHlwZWRlZiBlbnVtIHsKICAgICBXRUJLSVRfUExVR0lOX0VSUk9SX0ZBSUxFRCA9IDI5OSwKQEAg LTE2MCw3ICsxNjAsNyBAQCB3ZWJraXRfbmV0d29ya19lcnJvcl9xdWFyayAgICAgICAgICAgICAo dm9pZCk7CiBXRUJLSVRfQVBJIEdRdWFyawogd2Via2l0X3BvbGljeV9lcnJvcl9xdWFyayAgICAg ICAgICAgICAgKHZvaWQpOwogCi1XRUJLSVRfREVQUkVDQVRFRCBHUXVhcmsKK1dFQktJVF9BUEkg R1F1YXJrCiB3ZWJraXRfcGx1Z2luX2Vycm9yX3F1YXJrICAgICAgICAgICAgICAodm9pZCk7CiAK IFdFQktJVF9BUEkgR1F1YXJrCmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViS2l0L1VJUHJvY2Vzcy9B UEkvd3BlL1dlYktpdEVycm9yLmggYi9Tb3VyY2UvV2ViS2l0L1VJUHJvY2Vzcy9BUEkvd3BlL1dl YktpdEVycm9yLmgKaW5kZXggMGE5OTJjMzIwOTA0Li5kMjA3MGQ2ODRjNjYgMTAwNjQ0Ci0tLSBh L1NvdXJjZS9XZWJLaXQvVUlQcm9jZXNzL0FQSS93cGUvV2ViS2l0RXJyb3IuaAorKysgYi9Tb3Vy Y2UvV2ViS2l0L1VJUHJvY2Vzcy9BUEkvd3BlL1dlYktpdEVycm9yLmgKQEAgLTgwLDkgKzgwLDkg QEAgdHlwZWRlZiBlbnVtIHsKICAqIEBXRUJLSVRfUExVR0lOX0VSUk9SX0NBTk5PVF9MT0FEX1BM VUdJTjogTG9hZCBmYWlsdXJlIGR1ZSB0byBpbmFiaWxpdHkgdG8gbG9hZCBwbHVnaW4uIERlcHJl Y2F0ZWQgMi4zMgogICogQFdFQktJVF9QTFVHSU5fRVJST1JfSkFWQV9VTkFWQUlMQUJMRTogTG9h ZCBmYWlsdXJlIGR1ZSB0byBtaXNzaW5nIEphdmEgc3VwcG9ydCB0aGF0IGlzIHJlcXVpcmVkIHRv IGxvYWQgcGx1Z2luLiBEZXByZWNhdGVkIDIuMzIKICAqIEBXRUJLSVRfUExVR0lOX0VSUk9SX0NP Tk5FQ1RJT05fQ0FOQ0VMTEVEOiBMb2FkIGZhaWx1cmUgZHVlIHRvIGNvbm5lY3Rpb24gY2FuY2Vs bGF0aW9uLiBEZXByZWNhdGVkIDIuMzIKLSAqIEBXRUJLSVRfUExVR0lOX0VSUk9SX1dJTExfSEFO RExFX0xPQUQ6IExvYWQgZmFpbHVyZSBzaW5jZSBwbHVnaW4gaGFuZGxlcyB0aGUgbG9hZC4gRGVw cmVjYXRlZCAyLjMyCisgKiBAV0VCS0lUX1BMVUdJTl9FUlJPUl9XSUxMX0hBTkRMRV9MT0FEOiBM b2FkIGZhaWx1cmUgc2luY2UgbWVkaWEgcGxheWVyIGhhbmRsZXMgdGhlIGxvYWQuCiAgKgotICog RW51bSB2YWx1ZXMgdXNlZCB0byBkZW5vdGUgdGhlIHZhcmlvdXMgcGx1Z2luIGVycm9ycy4KKyAq IEVudW0gdmFsdWVzIHVzZWQgdG8gZGVub3RlIHRoZSB2YXJpb3VzIHBsdWdpbiBhbmQgbWVkaWEg ZXJyb3JzLgogICoqLwogdHlwZWRlZiBlbnVtIHsKICAgICBXRUJLSVRfUExVR0lOX0VSUk9SX0ZB SUxFRCA9IDI5OSwKQEAgLTE0NSw3ICsxNDUsNyBAQCB3ZWJraXRfbmV0d29ya19lcnJvcl9xdWFy ayAgICAgICAgICAgICAodm9pZCk7CiBXRUJLSVRfQVBJIEdRdWFyawogd2Via2l0X3BvbGljeV9l cnJvcl9xdWFyayAgICAgICAgICAgICAgKHZvaWQpOwogCi1XRUJLSVRfREVQUkVDQVRFRCBHUXVh cmsKK1dFQktJVF9BUEkgR1F1YXJrCiB3ZWJraXRfcGx1Z2luX2Vycm9yX3F1YXJrICAgICAgICAg ICAgICAodm9pZCk7CiAKIFdFQktJVF9BUEkgR1F1YXJrCg==