201033 2019-08-22 06:28:16 -0700 [GTK][WPE] WebKitWebPage ID doesn't match 2019-10-11 05:10:20 -0700 1 1 1 Unclassified WebKit WebKitGTK Other Unspecified Unspecified RESOLVED FIXED https://bugs.webkit.org/show_bug.cgi?id=202847 P2 Normal --- 1 mcrha csaavedra achristensen beidson berto bugs-noreply cdumez cgarcia csaavedra ggaren mcatanzaro oldest_to_newest 1564026 0 mcrha 2019-08-22 06:28:16 -0700 This had been reported upstream here: https://gitlab.gnome.org/GNOME/evolution/issues/587 Using Fedora rawhide with webkit2gtk3 2.25.x (from .2 to .4), when one tries to open two composer windows in Evolution the second composer lost track of the WebKitWebPage and claims that the WebKitWebProcess cannot find page with certain ID (interestingly, three independent runs and it's always number 22). It's not only about the composer, I see the same when I run evolution in the Mail view, and switch to Contacts. 1564027 1 mcrha 2019-08-22 06:35:20 -0700 Looking more closely to this, it seems that each WebKitWebView instance runs its own WebKitWebProcess. This wasn't the case, it used to run one WebKitWebProcess per each WebKitWebContext. Evolution uses two WebKitWebContext-s, one for all previews and one for all the composers. Each of these two WebKitWebProcess-es load different set of web-extension-s and evolution talks to those through these extensions over D-Bus. The value used in the call of webkit_web_context_set_web_extensions_initialization_user_data() when the corresponding WebKitWebContext is used to distinguish between these two WebKitWebProcess-es, just as it had been intended. Evolution relies on this behavior heavily. What did change in WebKit in this regard, please? 1564028 2 mcrha 2019-08-22 06:52:54 -0700 Maybe the default for webkit_web_context_set_web_process_count_limit() should be changed from 0 to 1, to keep backward compatibility? The properties of WebKitWebContext added in 2.26 do not seem related, thus it can be some fix around this count limit, I guess, which introduced the changed behaviour. 1564036 3 csaavedra 2019-08-22 07:41:34 -0700 This might have gone under the radar, but the process limit has been made a no-op internally, which means that the API should be deprecated. See https://bugs.webkit.org/show_bug.cgi?id=193725 Instead there is a new API that might exposing, to set whether the process pool should use a single web process. 1564038 4 csaavedra 2019-08-22 07:45:26 -0700 > Looking more closely to this, it seems that each WebKitWebView instance runs its own WebKitWebProcess. This is something I need to investigate, as I think the default value of the internal SPI is FALSE so there shouldn't be only one web process per pool. I will check that. 1564049 5 mcrha 2019-08-22 08:10:58 -0700 (In reply to Claudio Saavedra from comment #3) > This might have gone under the radar, but the process limit has been made a > no-op internally I see, I can confirm it, I changed the value to '1' with no effect. (In reply to Claudio Saavedra from comment #4) > ..., as I think the default value of the internal SPI is FALSE so there > shouldn't be only one web process per pool. Looking into the patch attached in the bug you referenced it's correct. There is one 'YES' value, but I do not know what that is for. I do not see from the patch how I can change it. If the MiniBrowser/Safari can (according to the ChangeLog there), then I should be able to do it too, right? Still, the previous behaviour was to have one process per WebKitWebContext. Keeping this the default would help for applications which do not recompile on every WebKitGTK+ update. 1564050 6 csaavedra 2019-08-22 08:22:07 -0700 You cannot change it because we haven't exposed yet this SPI to a public API in the GTK and WPE ports. 1564056 7 mcrha 2019-08-22 08:37:59 -0700 Hrm. I know this had been discovered/reported too late in the release cycle, but is there any chance (and hope) to have a fix in 2.26.0, please? I'd prefer to change the default (at least for the ports where it cannot be changed by the API user), but if new API will be added then I'm fine with it too, at least partly (my concern here is that, at least in Fedora, the webkit2gtk3 is updated down in three stable releases, while this particular change will break all the older application versions which won't be rebuilt with required fix). 1564059 8 377009 csaavedra 2019-08-22 08:44:13 -0700 Created attachment 377009 Patch 1564060 9 csaavedra 2019-08-22 08:45:03 -0700 This is still a preliminary patch as I still need to add deprecation guards for the limit API and update the API tests as well, but feel free to give this a try for now. I will see if I can finish it tomorrow. 1564063 10 csaavedra 2019-08-22 08:47:54 -0700 Also, I think the default in the now-to-be-deprecated API is 0, meaning no limit. So I think a default value for this should be True unless I am misunderstanding something. My patch is inconsistent in that but I'll fix it tomorrow. 1564072 11 mcatanzaro 2019-08-22 09:05:09 -0700 See also: bug #193749 1564073 12 377009 mcatanzaro 2019-08-22 09:08:27 -0700 Comment on attachment 377009 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=377009&action=review > Source/WebKit/UIProcess/API/glib/WebKitWebContext.cpp:1626 > +void webkit_web_context_set_uses_single_web_process(WebKitWebContext* context, gboolean usesSingleWebProcess) Problem is as I mentioned in the other bug, you can't call this function until after the WebKitWebContext has been constructed, by which time it's too late to change the process limit. It doesn't actually work, does it? 1564150 13 csaavedra 2019-08-22 11:51:38 -0700 Then I'll make it a construct-only property, that should work. But I need to check the other bug tomorrow. 1564386 14 mcrha 2019-08-22 23:14:39 -0700 (In reply to Claudio Saavedra from comment #10) > Also, I think the default in the now-to-be-deprecated API is 0, meaning no > limit. Right, that's what the documentation says, though looking into bug #193725 comment #2, if I read it correctly, then this: - if (m_processes.size() < maximumNumberOfProcesses()) - return createNewWebProcess(websiteDataStore); was always false for the default '0' returned by maximumNumberOfProcesses(), thus there had been "always" (+/- other conditions about page count) reused the old process, if existed. That is, the default behaviour was similar as if the maximumNumberOfProcesses() was 1. The actual behaviour of the code confirms it. To have 0 as an unlimited count of processes it should look like: if (!maximumNumberOfProcesses() || m_processes.size() < maximumNumberOfProcesses()) return createNewWebProcess(websiteDataStore); I'll give a try to your patch, it'll only take some time, till webkit is built here. 1564395 15 csaavedra 2019-08-23 00:56:21 -0700 If your observation is correct, then we had a serious bug there. Since for security reasons a single web process per context is not a good idea, I'm afraid you'll have to patch your application to go back to the behavior desired. My patch won't work for the reasons Michael explained earlier; this is set too late to work. 1564397 16 377109 csaavedra 2019-08-23 01:00:42 -0700 Created attachment 377109 Patch 1564398 17 csaavedra 2019-08-23 01:01:07 -0700 This is still preliminary but feel free to try. 1564410 18 mcrha 2019-08-23 02:29:17 -0700 (In reply to Milan Crha from comment #14) > I'll give a try to your patch, it'll only take some time, till webkit is > built here. With only a quick test the previous patch (comment #8) fixed evolution. I'll try the new (comment #16) too. 1564411 19 mcrha 2019-08-23 02:54:30 -0700 (In reply to Milan Crha from comment #18) > I'll try the new (comment #16) too. The second patch doesn't work, I get the same behaviour as without it. 1564416 20 csaavedra 2019-08-23 03:30:32 -0700 (In reply to Milan Crha from comment #19) > (In reply to Milan Crha from comment #18) > > I'll try the new (comment #16) too. > > The second patch doesn't work, I get the same behaviour as without it. Did you change the value of the "single-web-process" in the WebKitWebContext? You need to. It's a construct-only property so you have to set it during creation, ie.: WebKitWebContext *context = g_object_new (WEBKIT_TYPE_WEB_CONTEXT, ...some non-default properties..., "single-web-process", TRUE, NULL); 1564418 21 mcrha 2019-08-23 03:48:52 -0700 > Did you change the value of the "single-web-process" in the WebKitWebContext? Nope, I didn't. The first patch worked without any change on the client side, with which I kind of counted. This is good for backward compatibility too. 1564420 22 mcrha 2019-08-23 03:53:33 -0700 > It's a construct-only property It means I cannot use webkit_web_context_get_default() any more. Not a big deal, neither ideal, just another obstacle. 1564423 23 mcrha 2019-08-23 03:57:30 -0700 (In reply to Milan Crha from comment #21) > > Did you change the value of the "single-web-process" in the WebKitWebContext? > > Nope, I didn't. The first patch worked without any change on the client > side, with which I kind of counted. This is good for backward compatibility > too. Right, with that added it works. What would be your suggestions with respect of dealing with these spontaneous page ID changes and (more importantly) new WebKitWebProcess-es with respect of reliable web-extension connection over D-Bus? A very silly workaround would be to use one WebKitWebContext for each WebKitWebView (because I can pass the initial arguments to the web extension, thus tell it what service name it should use), but it won't fix it everywhere, right? 1564769 24 mcatanzaro 2019-08-23 22:19:09 -0700 (In reply to Milan Crha from comment #14) > Right, that's what the documentation says, though looking into bug #193725 > comment #2, if I read it correctly, then this: > > - if (m_processes.size() < maximumNumberOfProcesses()) > - return createNewWebProcess(websiteDataStore); > > was always false for the default '0' returned by maximumNumberOfProcesses(), > thus there had been "always" (+/- other conditions about page count) reused > the old process, if existed. That is, the default behaviour was similar as > if the maximumNumberOfProcesses() was 1. The actual behaviour of the code > confirms it. Huh, this really needs to be investigated. I'm confident such a bug does not exist, but it certainly looks like there is a problem with this code. 1564770 25 mcatanzaro 2019-08-23 22:23:19 -0700 (In reply to Milan Crha from comment #23) > Right, with that added it works. > > What would be your suggestions with respect of dealing with these > spontaneous page ID changes and (more importantly) new WebKitWebProcess-es > with respect of reliable web-extension connection over D-Bus? A very silly > workaround would be to use one WebKitWebContext for each WebKitWebView > (because I can pass the initial arguments to the web extension, thus tell it > what service name it should use), but it won't fix it everywhere, right? Just include the page ID in any IPC messages and discard the message if it doesn't correspond to a currently-valid page ID? This is what Epiphany does and it doesn't cause any problems. It should be very rare for a page ID to become invalid during an IPC call. 1564771 26 377109 mcatanzaro 2019-08-23 22:27:13 -0700 Comment on attachment 377109 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=377109&action=review > Source/WebKit/UIProcess/API/glib/WebKitWebContext.cpp:467 > + g_param_spec_boolean( I think I would expose WebKitProcessModel here instead (you'll need to make sure whatever header that's declared in is added to the mkenums generation), then we can deprecate webkit_web_context_set_process_model() but don't have to deprecate WebKitProcessModel. Or maybe that's a bad idea. I'd wait for Carlos Garcia before spending time on this, in case he wants something different. I'd certainly recommend solving bug #193749 at the same time, to ensure a coherent solution. 1565321 27 377109 cgarcia 2019-08-27 04:33:02 -0700 Comment on attachment 377109 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=377109&action=review > Source/WebKit/UIProcess/API/glib/WebKitWebContext.cpp:357 > + configuration.setUsesSingleWebProcess(priv->usesSingleWebProcess); I think this is a temporary setting, to be used only internally, that will be removed eventually, so we shouldn't expose it. Chris, could you confirm it? I think I asked you about this, but I'm not sure it was this setting... 1565322 28 cgarcia 2019-08-27 04:35:04 -0700 I wonder if we could make an exception for custom protocols to not swap process on navigation between them, since the contents are provided by the application in the end. 1565689 29 cgarcia 2019-08-28 05:24:57 -0700 (In reply to Carlos Garcia Campos from comment #27) > Comment on attachment 377109 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=377109&action=review > > > Source/WebKit/UIProcess/API/glib/WebKitWebContext.cpp:357 > > + configuration.setUsesSingleWebProcess(priv->usesSingleWebProcess); > > I think this is a temporary setting, to be used only internally, that will > be removed eventually, so we shouldn't expose it. Chris, could you confirm > it? I think I asked you about this, but I'm not sure it was this setting... Chris? ^ 1565710 30 cdumez 2019-08-28 08:21:38 -0700 (In reply to Carlos Garcia Campos from comment #29) > (In reply to Carlos Garcia Campos from comment #27) > > Comment on attachment 377109 [details] > > Patch > > > > View in context: > > https://bugs.webkit.org/attachment.cgi?id=377109&action=review > > > > > Source/WebKit/UIProcess/API/glib/WebKitWebContext.cpp:357 > > > + configuration.setUsesSingleWebProcess(priv->usesSingleWebProcess); > > > > I think this is a temporary setting, to be used only internally, that will > > be removed eventually, so we shouldn't expose it. Chris, could you confirm > > it? I think I asked you about this, but I'm not sure it was this setting... > > Chris? ^ Unless you have a specific need for it, I would discourage you from exposing it in the API. This setting is indeed private and defeats the work we're doing to put different origins in separate processes. 1566124 31 cgarcia 2019-08-28 23:57:55 -0700 (In reply to Chris Dumez from comment #30) > (In reply to Carlos Garcia Campos from comment #29) > > (In reply to Carlos Garcia Campos from comment #27) > > > Comment on attachment 377109 [details] > > > Patch > > > > > > View in context: > > > https://bugs.webkit.org/attachment.cgi?id=377109&action=review > > > > > > > Source/WebKit/UIProcess/API/glib/WebKitWebContext.cpp:357 > > > > + configuration.setUsesSingleWebProcess(priv->usesSingleWebProcess); > > > > > > I think this is a temporary setting, to be used only internally, that will > > > be removed eventually, so we shouldn't expose it. Chris, could you confirm > > > it? I think I asked you about this, but I'm not sure it was this setting... > > > > Chris? ^ > > Unless you have a specific need for it, I would discourage you from exposing > it in the API. This setting is indeed private and defeats the work we're > doing to put different origins in separate processes. And what do you think about making custom protocols an exception and not swap processes when navigating between them? 1566149 32 mcrha 2019-08-29 01:20:08 -0700 I'm still afraid of backward compatibility. This changes a lot for applications which have their own web extensions. You should bump the soname version or something like that, because such change deserves it ( https://gitlab.gnome.org/GNOME/evolution/issues/587#note_587156 ). You have custom protocols and trusted origins. In case of Evolution every origin is trusted. All the extra work the changes bring in is unnecessary in case of Evolution and similar applications. I do not understand one thing, quite important thing from my point of view. When the WebKitWebView has loaded a page with iframe-s from different origins and you spawn a new WebKitWebProcess for each iframe, and when the application wants to modify DOM in any of these iframe-s, for which it uses D-Bus, where the web extension spawns a service on expected name, does this new behaviour mean that: a) each new WebKitWebProcess will load all web-extensions b) each iframe will have its own WebKitWebPage ID c) the extension tight to the main WebKitWebView's page (which provides the only page ID the application can know of) will not be able to read/write DOM changes in the iframe-s , right ? In other words, should one keep a list of web extensions for a single WebKitWebView and decide to which of them the request should be sent based on some fuzzy logic ('fuzzy logic' in a meaning 'who knows how to decide which one in the list is the right one')? Not talking that this list can change dynamically, as the WeBkiWebView reloads its content? I'm really confused by this, not talking about the complexity it adds to the WebKitGTK+ users. By the way, evolution-data-server supports so called backend-per-process, which can spawn factory subprocesses for each backend (calendar/addressbook/...) if needed. That was the default. It was also for similar reasons as for which you do this (the initial idea behind the change was: 'if one backend causes crash, the rest will continue running), but it was requested to change the default behaviour and to not run the subprocesses, due to increased memory (and other resources) requirements. That to be able to run this on hardware with limited resources. Thus even the backend-per-process was a good idea, it was abandoned later. More can be seen here, if you are interested: https://bugzilla.gnome.org/show_bug.cgi?id=793031 1566230 33 cdumez 2019-08-29 08:21:21 -0700 (In reply to Carlos Garcia Campos from comment #31) > (In reply to Chris Dumez from comment #30) > > (In reply to Carlos Garcia Campos from comment #29) > > > (In reply to Carlos Garcia Campos from comment #27) > > > > Comment on attachment 377109 [details] > > > > Patch > > > > > > > > View in context: > > > > https://bugs.webkit.org/attachment.cgi?id=377109&action=review > > > > > > > > > Source/WebKit/UIProcess/API/glib/WebKitWebContext.cpp:357 > > > > > + configuration.setUsesSingleWebProcess(priv->usesSingleWebProcess); > > > > > > > > I think this is a temporary setting, to be used only internally, that will > > > > be removed eventually, so we shouldn't expose it. Chris, could you confirm > > > > it? I think I asked you about this, but I'm not sure it was this setting... > > > > > > Chris? ^ > > > > Unless you have a specific need for it, I would discourage you from exposing > > it in the API. This setting is indeed private and defeats the work we're > > doing to put different origins in separate processes. > > And what do you think about making custom protocols an exception and not > swap processes when navigating between them? Process Swapping has nothing to do with protocols at the moment, it is merely based on domain names. I would not expect process-swapping to occur between custom protocols, assuming they either use the same domain name (or do not have a domain name). Adding Brady and Alex in cc in case they have input. 1566232 34 cdumez 2019-08-29 08:23:33 -0700 (In reply to Milan Crha from comment #32) > I'm still afraid of backward compatibility. This changes a lot for > applications which have their own web extensions. You should bump the soname > version or something like that, because such change deserves it ( > https://gitlab.gnome.org/GNOME/evolution/issues/587#note_587156 ). > > You have custom protocols and trusted origins. In case of Evolution every > origin is trusted. All the extra work the changes bring in is unnecessary in > case of Evolution and similar applications. > > I do not understand one thing, quite important thing from my point of view. > When the WebKitWebView has loaded a page with iframe-s from different > origins and you spawn a new WebKitWebProcess for each iframe, and when the > application wants to modify DOM in any of these iframe-s, for which it uses > D-Bus, where the web extension spawns a service on expected name, does this > new behaviour mean that: > a) each new WebKitWebProcess will load all web-extensions > b) each iframe will have its own WebKitWebPage ID > c) the extension tight to the main WebKitWebView's page (which provides > the only page ID the application can know of) will not be able to > read/write DOM changes in the iframe-s > , right ? In other words, should one keep a list of web extensions for a > single WebKitWebView and decide to which of them the request should be sent > based on some fuzzy logic ('fuzzy logic' in a meaning 'who knows how to > decide which one in the list is the right one')? Not talking that this list > can change dynamically, as the WeBkiWebView reloads its content? > > I'm really confused by this, not talking about the complexity it adds to the > WebKitGTK+ users. > > By the way, evolution-data-server supports so called backend-per-process, > which can spawn factory subprocesses for each backend > (calendar/addressbook/...) if needed. That was the default. It was also for > similar reasons as for which you do this (the initial idea behind the change > was: 'if one backend causes crash, the rest will continue running), but it > was requested to change the default behaviour and to not run the > subprocesses, due to increased memory (and other resources) requirements. > That to be able to run this on hardware with limited resources. Thus even > the backend-per-process was a good idea, it was abandoned later. More can be > seen here, if you are interested: > https://bugzilla.gnome.org/show_bug.cgi?id=793031 No, process swapping on navigation is not for stability, it is for security and it has become increasingly important because of things like Spectre. Note that we've had process-per-tab for a long time and that this matches more closely the backend-per-process model you're talking about. 1566258 35 mcrha 2019-08-29 09:02:10 -0700 Looking into the WebKitGTK+ debugger, the Resources tab, I see there are opened: mail:​/​/accountname/path/to/message/id?​mode=0&​arguments mail:​/​/accountname/path/to/message/id?​part_id=.message..... mail:​/​/accountname/path/to/message/id?​part_id=.message..... where the first is the main view's URL, the second and third are iframe src attributes, for two different parts of the viewed mail message. The other resources referenced in this message are: evo-file:///usr/share/evolution/theme/webview.css gtk-stock://pan-down-symbolic?size=4 gtk-stock://go-next?size=4 gtk-stock://x-evolution-arrow-down?size=4 The gtk-stock:// URL changes the "host" part according to the image it wants to receive. There can be also used evo-http:// and evo-https:// URLs, which consist of the external URLs provided by the message sender (like external images, CSS files and so on). Those download can be enabled/disabled in Preferences, or they can be loaded on demand by the user, but they are downloaded by Evolution itself, not by WebKitGTK+. If I understand it properly, then the other resources are not a problem, they are not web pages, thus they do not cause WebKitWebProcess/Page change. That the all HTML pages are from mail:​/​/accountname/path/... means that that won't change the Page/ID too, at least until user moves to other account (the URL can be mail://imap1/Inbox/123 in one IMAP account and mail://imap2/test/321 in another account). Is that correct? I'm asking that, because if I'm going to add some workaround in Evolution for this (pity it had been discovered such late in the release cycle (I know you have it there for a long time)), then I'd like to reproduce this and test that my code will work as expected. 1566269 36 cdumez 2019-08-29 09:30:29 -0700 (In reply to Milan Crha from comment #35) > Looking into the WebKitGTK+ debugger, the Resources tab, I see there are > opened: > > mail:​/​/accountname/path/to/message/id?​mode=0&​arguments > mail:​/​/accountname/path/to/message/id?​part_id=.message..... > mail:​/​/accountname/path/to/message/id?​part_id=.message..... > > where the first is the main view's URL, the second and third are iframe src > attributes, for two different parts of the viewed mail message. The other > resources referenced in this message are: > > evo-file:///usr/share/evolution/theme/webview.css > gtk-stock://pan-down-symbolic?size=4 > gtk-stock://go-next?size=4 > gtk-stock://x-evolution-arrow-down?size=4 > > > The gtk-stock:// URL changes the "host" part according to the image it wants > to receive. There can be also used evo-http:// and evo-https:// URLs, which > consist of the external URLs provided by the message sender (like external > images, CSS files and so on). Those download can be enabled/disabled in > Preferences, or they can be loaded on demand by the user, but they are > downloaded by Evolution itself, not by WebKitGTK+. > > If I understand it properly, then the other resources are not a problem, > they are not web pages, thus they do not cause WebKitWebProcess/Page change. > That the all HTML pages are from mail:​/​/accountname/path/... means that > that won't change the Page/ID too, at least until user moves to other > account (the URL can be mail://imap1/Inbox/123 in one IMAP account and > mail://imap2/test/321 in another account). Is that correct? I'm asking that, > because if I'm going to add some workaround in Evolution for this (pity it > had been discovered such late in the release cycle (I know you have it there > for a long time)), then I'd like to reproduce this and test that my code > will work as expected. For the workaround on your side, why don't you simply disable process-swap-on-navigation? 1566565 37 mcrha 2019-08-29 23:03:31 -0700 (In reply to Chris Dumez from comment #36) > For the workaround on your side, why don't you simply disable > process-swap-on-navigation? I'd like to give it a try, but how is that accessed in the WebKitGTK+ world, please? Simple `git grep process-swap-on-navigation` in the root checkout of WebKit sources on the master branch gives several hits in multiple ChangeLog file and only one hit in a code, and that in the comment: > Source/WebCore/loader/FrameLoader.cpp: // If the request came from a previous process due to process-swap-on-navigation then we should not modify the request. The developer documentation for WebKitWebContext [1] doesn't give me anything of that name either. I'm sorry, but I do not develop WebKit, thus if it's any internal name for some feature, then I'm not aware of its meaning in the outside world. [1] https://webkitgtk.org/reference/webkit2gtk/stable/WebKitWebContext.html 1566571 38 377109 cgarcia 2019-08-29 23:36:30 -0700 Comment on attachment 377109 Patch r- because we don't really want to expose this setting. 1566573 39 cgarcia 2019-08-29 23:40:39 -0700 (In reply to Chris Dumez from comment #36) > (In reply to Milan Crha from comment #35) > > Looking into the WebKitGTK+ debugger, the Resources tab, I see there are > > opened: > > > > mail:​/​/accountname/path/to/message/id?​mode=0&​arguments > > mail:​/​/accountname/path/to/message/id?​part_id=.message..... > > mail:​/​/accountname/path/to/message/id?​part_id=.message..... > > > > where the first is the main view's URL, the second and third are iframe src > > attributes, for two different parts of the viewed mail message. The other > > resources referenced in this message are: > > > > evo-file:///usr/share/evolution/theme/webview.css > > gtk-stock://pan-down-symbolic?size=4 > > gtk-stock://go-next?size=4 > > gtk-stock://x-evolution-arrow-down?size=4 > > > > > > The gtk-stock:// URL changes the "host" part according to the image it wants > > to receive. There can be also used evo-http:// and evo-https:// URLs, which > > consist of the external URLs provided by the message sender (like external > > images, CSS files and so on). Those download can be enabled/disabled in > > Preferences, or they can be loaded on demand by the user, but they are > > downloaded by Evolution itself, not by WebKitGTK+. > > > > If I understand it properly, then the other resources are not a problem, > > they are not web pages, thus they do not cause WebKitWebProcess/Page change. > > That the all HTML pages are from mail:​/​/accountname/path/... means that > > that won't change the Page/ID too, at least until user moves to other > > account (the URL can be mail://imap1/Inbox/123 in one IMAP account and > > mail://imap2/test/321 in another account). Is that correct? I'm asking that, > > because if I'm going to add some workaround in Evolution for this (pity it > > had been discovered such late in the release cycle (I know you have it there > > for a long time)), then I'd like to reproduce this and test that my code > > will work as expected. > > For the workaround on your side, why don't you simply disable > process-swap-on-navigation? We haven't exposed that option in the API because PSON was supposed to be mandatory for security reasons, and the internal setting was supposed to be private for testing. If that's not the case, and the setting won't be removed in the future I'll add an option to disable it in the API, there might be apps that don't really need it like evolution. Otherwise, what we can do for now, is adding an env var (yes, I also hate env vars) to disable it (only in 2.26 branch), so that apps can disable it while we figure out the issues during the next release cycle. 1566593 40 mcrha 2019-08-30 00:59:51 -0700 Okay, anything would be better than this situation, even env var. Still without backward compatibility, if I understand it correctly. I gave this a try, I mean a try on the evolution side. My idea was: if I cannot influence the number of WebProcess-es being run, then I'll create a WebContext for each WebView on which I'll set user data for the WebExtension, thus my extension will open on expected name. That should work, as long as I won't reuse the same WebContext on multiple WebView-s. The result is kind of funny (I'm on git master at commit dbcee3d87d966240becdba723dc38f12208dd256, aka git-svn-id: http://svn.webkit.org/repository/webkit/trunk@249275 268f45cc-cd09-0410-ab3c-d52691b4dbfc according to git log). I do not cache webkit_web_view_get_page_id(), I use it directly when issuing D-Bus requests towards my extension. I see the created WebExtension has been notified about created WebPage with ID 6 and that's the only one about which the WebExtension had been notified so far. Then the client side issues D-Bus calls with WebPage ID 5 (not 6). Those are initial requests on the WebPage, you can get an idea what they do from their names: EWebViewEnsureBodyClass, AddCSSRuleIntoStyleSheet and so on. These are run asynchronously, after the WebExtension registers itself on the D-Bus. These are important calls, thus I need them to happen, not to ignore their failure (for nonexistent page ID). The WebKitWebView documentation doesn't have "page-id" property (in which case I could theoretically listen for "notify::page-id" GObject signal for changes), neither there's a (GObject) signal for page-id changes, thus I've basically no idea when the page ID for the WebView changed. Being able to detect it, I can re-run my commands on the new page ID (even it would be awful from the coding and performance point of view). I do not know that the page ID changed on the WebExtension side, there was not created any WebPage with ID 5, only with ID 6 (otherwise I could add my own D-Bus signal on my WebExtension). This WebPage had been created before D-Bus name had been acquired, if it matters. The biggest problem, the webkit_web_view_get_page_id() still returns number 5, even after such long time, after I wrote this comment. 1566597 41 377687 mcrha 2019-08-30 01:39:34 -0700 Created attachment 377687 test-wk2.c - reproducer client side The first line contains a comment with a command to build & run it. Press Reload button at the top to begin the fun. There's also printed on the console what page ID the WebView uses every 3 seconds. It doesn't change at all. One thing I do not understand, but maybe it's intentional: when I press the Reload button 5 times, there are left running 4 WebKitWebProcess processes. They do not close as soon as they are useless. Is that intentional, like if they could be reused, or it's another overlook? 1566598 42 377688 mcrha 2019-08-30 01:41:24 -0700 Created attachment 377688 test-wk2-extension.c - a WebExtension The first line contains a command line to build it. It's a complementary WebExtension for the test-wk2.c above, which shows what is happening on the WebKitWebProcess(-es) side. 1566627 43 cgarcia 2019-08-30 04:04:52 -0700 Milan, could you try simply disabling PSON in you wk build? You need to edit Source/WebKit/Shared/WebPreferencesDefaultValues.h and remove PLATFORM(GTK) from: #if PLATFORM(MAC) || PLATFORM(IOS) || PLATFORM(GTK) || PLATFORM(WPE) #define DEFAULT_PROCESS_SWAP_ON_CROSS_SITE_NAVIGATION_ENABLED true #else #define DEFAULT_PROCESS_SWAP_ON_CROSS_SITE_NAVIGATION_ENABLED false #endif 1566726 44 mcatanzaro 2019-08-30 10:51:39 -0700 Milan, you really need to use a private D-Bus connection, like I suggested in your GitLab issue, regardless. There's no reason you need to be using the session bus to implement a private Evolution feature, right? If you use private connections to each web extension, then you no longer need to use page IDs to identify web processes and your entire problem goes away (I think). Really, it seems like a silly problem to have. Nevertheless, I'm very sympathetic to your concerns about this API break, and it's possible other applications might break too. A soname bump would be insufficient, because old Evolution compiled against new WebKit would not work. PSON really requires an API version bump, but an API version bump could imperil WebKit's fragile relationship with Debian security. We can be almost certain that a WebKit update that requires even a minor change in Evolution, like setting an environment variable or disabling a hypothetical public API PSON setting, would cause Debian to reject future WebKit updates. So I don't see any good solutions here. Perhaps we should disable PSON at build time for 2.26 to buy time, but we don't want to keep doing that indefinitely. (In reply to Milan Crha from comment #35) > Looking into the WebKitGTK+ debugger, the Resources tab, I see there are > opened: > > mail:​/​/accountname/path/to/message/id?​mode=0&​arguments > mail:​/​/accountname/path/to/message/id?​part_id=.message..... > mail:​/​/accountname/path/to/message/id?​part_id=.message..... > > where the first is the main view's URL, the second and third are iframe src > attributes, for two different parts of the viewed mail message. The other > resources referenced in this message are: > > evo-file:///usr/share/evolution/theme/webview.css > gtk-stock://pan-down-symbolic?size=4 > gtk-stock://go-next?size=4 > gtk-stock://x-evolution-arrow-down?size=4 > > > The gtk-stock:// URL changes the "host" part according to the image it wants > to receive. Well Alex is the expert on URI parsing. I'm not sure whether these URIs have different hosts, or no host at all. Certainly the mail:// and evo-file:// URIs look like URIs with paths and no hosts. I guess PSON should consider URIs without hosts to be the same origin. 1566786 45 achristensen 2019-08-30 13:31:42 -0700 <script>alert(new URL("gtk-stock://pan-down-symbolic?size=4").hostname)</script> The host is "pan-down-symbolic". Use three slashes if you want there to be an empty host. 1566825 46 mcatanzaro 2019-08-30 14:50:45 -0700 (In reply to Alex Christensen from comment #45) > Use three slashes if you want there to be an empty host. Milan, can you try this? It should probably suffice. 1566826 47 mcatanzaro 2019-08-30 14:55:03 -0700 (In reply to Michael Catanzaro from comment #44) > We can be > almost certain that a WebKit update that requires even a minor change in > Evolution, like setting an environment variable or disabling a hypothetical > public API PSON setting, would cause Debian to reject future WebKit updates. > So I don't see any good solutions here. Maybe if we work with a friendly Debian maintainer to ensure Evolution gets patched before 2.26.0, then we can cross our fingers and hope no other apps are affected. Let's be extra careful and give the transition to 2.26 in Debian more time than usual, so we can smoke out any other affected apps in Fedora first. 1566968 48 mcatanzaro 2019-08-31 02:22:04 -0700 (In reply to Carlos Garcia Campos from comment #28) > I wonder if we could make an exception for custom protocols to not swap > process on navigation between them, since the contents are provided by the > application in the end. I thought it was a great idea, but it's not because the content could ultimately come from the untrusted source even though it's directly provided by the application. E.g. loading ephy-reader://example.com and ephy-reader://malicious.com in the same view without a process swap would be vulnerable even though it's a custom protocol. 1567135 49 mcrha 2019-09-02 00:03:13 -0700 (In reply to Carlos Garcia Campos from comment #43) > Milan, could you try simply disabling PSON in you wk build? No, it did not help. I still get "Invalid page ID: 5". I only changed webkit sources and reverted my test changes on the evolution side; I did not fetch latest changes, thus I'm at the same state as comment #40 (I'll do it now). Though I think the test doesn't prove anything, because page IDs simply do not match, which I consider a regression, because it wasn't the case before (in time of comment #18). (In reply to Michael Catanzaro from comment #44) > Milan, you really need to use a private D-Bus connection, like I suggested > in your GitLab issue, regardless. I'm not sure what that would change. There is still the same problem, one WebKitWebView on the client side, and multiple WebKitWebProcess-es on the other side, some of them stale, while the WebView needs to talk to its counterpart on the WebProcess side, at least one of them. Giving unique D-Bus name for each WebProcess is odd, because I need to know on the WebView side to which proxy I should talk (and expect responses). Having it on a private D-Bus bus would help to what? To be able to "introspect" all the existing connections on it and "pick randomly" one of them, eventually send the message (and listen for responses) on all of them? I'm sorry, but that feels like a hit&miss game, not a deterministic programming. And having opened as many private D-Bus connections as many WebKitWebView instances are opened also doesn't feel the best approach. 1567136 50 mcrha 2019-09-02 00:16:37 -0700 (In reply to Michael Catanzaro from comment #48) > E.g. loading ephy-reader://example.com and ephy-reader://malicious.com in the > same view without a process swap would be vulnerable even though it's a custom > protocol. Like if the web page author would like to address only epiphany browser with added URL of scheme he/she knows epiphany is using for trusted content? Hih, that would be interesting. Thinking of it this way, the data being downloaded, even downloaded by Evolution itself, is trusted only in a way of a user setting, that can not download external content by default, even users can let Evolution do it and to pass it to WebKitWebView. It's for evo-http:// and evo-https:// schemes. The mail:// scheme is semi-trusted. It modifies text/html parts to not reference external data directly; in creates HTML content from text/plain and other parts as needed. All the other custom schemes Evolution uses can be considered trusted. I mean, even I said Evolution uses trusted content only, it was not accurate. 1567145 51 cgarcia 2019-09-02 01:28:37 -0700 It's so late in the release cycle that I think the best approach is to disable PSON in 2.26 and work in all these issues (see also bug #200967) in trunk for 2.28. What do you think? 1567147 52 mcrha 2019-09-02 01:34:10 -0700 Works for me, but I'm not sure whether it's a question for me :) 1567153 53 mcrha 2019-09-02 01:57:42 -0700 (In reply to Milan Crha from comment #49) > ... I still get "Invalid page ID: 5". I only changed webkit > sources and reverted my test changes on the evolution side; I did not fetch > latest changes, thus I'm at the same state as comment #40 (I'll do it now). Still the same problem with git checkout at commit aec39837fb5478153424253f0a1871c5f2b2d7aa, aka git-svn-id: http://svn.webkit.org/repository/webkit/trunk@249376 268f45cc-cd09-0410-ab3c-d52691b4dbfc. The extension page ID is 6, while the WebView's page ID is 5. It's with the change from comment #43. This off-by-one should be fixed as well. I believe both sides should use the same page ID, no? It was the case till recently, at least. 1567155 54 cgarcia 2019-09-02 02:05:40 -0700 (In reply to Milan Crha from comment #53) > (In reply to Milan Crha from comment #49) > > ... I still get "Invalid page ID: 5". I only changed webkit > > sources and reverted my test changes on the evolution side; I did not fetch > > latest changes, thus I'm at the same state as comment #40 (I'll do it now). > > Still the same problem with git checkout at commit > aec39837fb5478153424253f0a1871c5f2b2d7aa, aka git-svn-id: > http://svn.webkit.org/repository/webkit/trunk@249376 > 268f45cc-cd09-0410-ab3c-d52691b4dbfc. The extension page ID is 6, while the > WebView's page ID is 5. > > It's with the change from comment #43. This off-by-one should be fixed as > well. I believe both sides should use the same page ID, no? It was the case > till recently, at least. I thought this was caused by process swapping... 1567156 55 cgarcia 2019-09-02 02:07:35 -0700 So, your problem doesn't come from PSON directly, but from the fact that we removed the single process model because of PSON? 1567158 56 mcrha 2019-09-02 02:15:46 -0700 (In reply to Carlos Garcia Campos from comment #55) > So, your problem doesn't come from PSON directly, but from the fact that we > removed the single process model because of PSON? I'd say both. As I wrote in comment #49, in time of comment #18 the page IDs matched on both sides until I had more than one WebKitWebView instance opened for one WebKitWebContext (which ran multiple WebProcess-es and my D-Bus connection to the loaded extension didn't know about the other WebProcess). Right now page IDs do not match on both sides at all - that's why I call it a regression. If you've a pointer where to look in the sources, I can give it a try. 1567160 57 cgarcia 2019-09-02 02:21:48 -0700 That's more complicated to revert then, because process limit is gone, and single process model would be now a construct only property of the context (we want a temporary solution, so new API is not an option). So, an env var to enable single process model would work for now, at least for evo. Then we need to review how evo is using the web extensions to understand what the problem is, what needs to be fixed/added in wk, and what to fix in evo too. I also think you shouldn't use the session bus for private communications between the same application. A private p2p connection like ephy does seems more appropriate for evo. 1567177 58 mcrha 2019-09-02 03:23:10 -0700 Evolution currently distinguishes between previews and editors. Editors use their own WebKitWebContext, one for all of them, while previews use the default WebKitWebContext. My test changes I tried to do above stopped using the default WebContext. The way this works for editors (I'm willing to change it for previews as well due to this bug), is that the GUI process creates the WebContext on demand and reuses it, while it sets also user data for the WebExtension, containing expected D-Bus service name, where the GUI process listens and sends its requests. These requests contain page ID-s, thus the WebExtension side knows to which WebKitWebPage the request belongs. Once the WebKitWebProcess runs, the WebExtension reads the D-Bus name and registers itself on the session bus. (Problem number 1: when there are multiple WebProcess-es, each tries to register the same D-Bus service name, which results in failure for second and other WebProcess-es.) All of this worked fine until now, because the WebKit behaviour was that only one WebProcess was created for one WebContext (regardless the process-limit value, which evolution code doesn't touch and lefts it to default '0'; it's unrelated, only if it worked, then the issue with multiple WebProcess-es would be found earlier). When the WebExtension wants to send a D-Bus signal to the GUI part, it also includes the web page ID, as returned by WebKitWebPage, thus the GUI editor can distinguish whether the signal was meant for its WebKitWebView or for another WebKitWebView. (Problem number 2: web page IDs do not match now, which breaks all the logic in the code.) That describes roughly how it works in Evolution. There are expectations, which can break the code when they are not satisfied. It worked, because the behaviour of Webkit was as expected by the code. I'm fine to change things on the Evolution side, I hope it's obvious, it's only not ideal for backward compatibility, as we agreed above. I do not see how private D-Bus connection could help with the current situation, but I'll check what Epiphany does, then maybe I'll understand. 1567180 59 cgarcia 2019-09-02 03:58:55 -0700 single process model was implemented as multiple process model with limit of 1. Removing the process limit, made the single process model no-op. There's still an internal option to use a single process model, but it's different, that's why it requires to be a construct-only property. 1567185 60 mcrha 2019-09-02 05:01:36 -0700 Just for the record, WebKitWebPage::id != WebKitWebView::page-id (aka page ID mismatch introduced semi-recently) is causing problems to Epiphany too. I could not test 3.33.92, because it needs too new glib, thus I tried 3.33.1, but the body of embed/ephy-web-view.c:page_created_cb() looks the same, also depending on the proper page ID provided, the callbacks and view->web_process_extension are never assigned, due to this mismatch. I added at the very top this debug print: printf ("%s: view:%p: expects:%" G_GUINT64_FORMAT " received:%" G_GUINT64_FORMAT "\n", __FUNCTION__, view, webkit_web_view_get_page_id (WEBKIT_WEB_VIEW (view)), page_id); and I see on the console: page_created_cb: view:0x15a6b50: expects:7 received:8 page_created_cb: view:0x15a6b50: expects:7 received:114 page_created_cb: view:0x1644940: expects:113 received:114 The 113/114 is for the second tab I opend there. As the signal callbacks are not connected I cannot open an https:// page, whose server uses self-signed or otherwise "invalid" certificate. I can click "Technical info->Accept Risk and Proceed" red button, but it only makes a spinner at the tab spinning and nothing changes. Clicking "Go Back" blue button on this "Security violation" page works. 1567186 61 mcatanzaro 2019-09-02 05:14:45 -0700 Well it seems you're right. A private connection wouldn't fix this because it's inherently racy. So now we know what's causing https://gitlab.gnome.org/GNOME/epiphany/issues/871. This seems really hard to solve, and there's no time. 1567187 62 mcatanzaro 2019-09-02 05:23:58 -0700 Actually this might be good, because it looks like a more straightforward bug. WebKitWebProcess::page-created should be emitted for every process swap. The latest ID visible to the web process (via webkit_web_page_get_id()) should match the ID visible to the UI process (via webkit_web_view_get_page_id()) unless a process swap has just occurred. It's OK for that page_created_cb() function to fail and return early if a process swap has just occurred, but if so, it should be called again imminently and succeed because another page created message should be incoming from the web process. For them to get completely desynced, as you show, there must be some bug, not an inherent problem with the new process model. 1567188 63 mcatanzaro 2019-09-02 05:32:29 -0700 (In reply to Michael Catanzaro from comment #62) > Actually this might be good, because it looks like a more straightforward > bug. Well probably it's not good, just a race. The page ID coming from the web process is probably the new ID, and the UI process just hasn't noticed yet. If I guess right, the UI process's page ID will be updated momentarily, but when that happens it's already too late. The web process message has already been discarded due to the mismatch. 1567189 64 mcrha 2019-09-02 05:48:26 -0700 (In reply to Michael Catanzaro from comment #61) > Well it seems you're right. A private connection wouldn't fix this because > it's inherently racy. So now we know what's causing > https://gitlab.gnome.org/GNOME/epiphany/issues/871. Is it with 3 weeks old WebKit master/trunk? The issue had been filled 3 weeks ago, according to gitlab. (In reply to Michael Catanzaro from comment #63) > If I guess right, the UI process's page ID will be updated momentarily, but > when that happens it's already too late. No, it's not updated at all. Try comment #41 + comment #42. 1567190 65 mcrha 2019-09-02 05:55:05 -0700 (In reply to Milan Crha from comment #64) > Is it with 3 weeks old WebKit master/trunk? The issue had been filled 3 > weeks ago, according to gitlab. Nevermind. Gitlab says August 5, but if I try WebKitGTK+ with git checkout at commit ca8dc42af2fbce678b44fa83e61c4cb3ebbe23a0, aka from Aug 23 07:25:00 2019, then there is no page ID mismatch, thus it's not it. 1567191 66 mcatanzaro 2019-09-02 06:00:41 -0700 Well I added some debug. When the page changes due to a process swap, the new page has the same ID as the old page. So that's really nice. It means this should work, in theory. (In reply to Milan Crha from comment #60) > page_created_cb: view:0x15a6b50: expects:7 received:8 > page_created_cb: view:0x15a6b50: expects:7 received:114 > page_created_cb: view:0x1644940: expects:113 received:114 Expected result would actually be something like: > page_created_cb: view:0x15a6b50: expects:7 received:7 > page_created_cb: view:0x15a6b50: expects:7 received:113 > page_created_cb: view:0x1644940: expects:113 received:113 because each view receives the page created message for every page, and just discards messages that aren't intended for it. So I see there is a race here, because 8 and 114 are being received and the associated functionality is all broken. I just can't reproduce. It might be a timing issue. But in theory, because the page ID stays the same even when the page is swapped out for another, it should be fixable. 1567193 67 mcatanzaro 2019-09-02 06:02:25 -0700 Could you use SVN revision numbers when talking about specific WebKit commits, please? That makes it easier to see what commit you are talking about. 1567196 68 mcrha 2019-09-02 06:26:58 -0700 (In reply to Michael Catanzaro from comment #67) > Could you use SVN revision numbers when talking about specific WebKit > commits, please? Yes, of course. That's the: git-svn-id: http://svn.webkit.org/repository/webkit/trunk@249042 268f45cc-cd09-0410-ab3c-d52691b4dbfc from the end of the `git log`, right? It's for: (In reply to Milan Crha from comment #65) > ... at commit ca8dc42af2fbce678b44fa83e61c4cb3ebbe23a0 ... 1567197 69 mcatanzaro 2019-09-02 06:28:14 -0700 (In reply to Milan Crha from comment #53) > Still the same problem with git checkout at commit > aec39837fb5478153424253f0a1871c5f2b2d7aa, aka git-svn-id: > http://svn.webkit.org/repository/webkit/trunk@249376 > 268f45cc-cd09-0410-ab3c-d52691b4dbfc. The extension page ID is 6, while the > WebView's page ID is 5. > > It's with the change from comment #43. This off-by-one should be fixed as > well. I believe both sides should use the same page ID, no? It was the case > till recently, at least. I'm trying your test case with 2.25.4 (r248153) but I see 5 on both sides. It's possible this is a timing issue that just happens on your computer but not mine? 1567201 70 mcrha 2019-09-02 07:04:42 -0700 (In reply to Michael Catanzaro from comment #69) > It's possible this is a timing issue that just happens on your computer but > not mine? I do not think so. I see correct page IDs on both sides with r249042 too, even with r249174. The page ID thing regressed only (semi-)recently. 1567206 71 cdumez 2019-09-02 08:34:25 -0700 As of very recently (last week), the WebPageProxy ids and the WebPage ids are now completely unrelated. The WebPage id now also changes on every process swap. Note that Cocoa has code to support communication between the UIProcess and the injected bundle. The way I made it work is that the UIProcess side listens for IPC using the WebPageProxy id as IPC id. Because this id is constant throughout the lifetime of the view, this allows the UIProcess side object to receive IPC from all injected bundles (previous and new process when process swapping). On the WebProcess side, the object listens for IPC using the WebPage id as identifier, so we know which exact object to route it to. On the UIProcess side, we always send messages to the process currently associated with the WebPageProxy and use the WebPage id that is currently associated to the WebPageProxy. This allows multiple to 1 communication. The WebPage proxy always only talks to the committed process’ bundle, but can receive IPC from all injected bundles associated with the WebView. 1567207 72 cgarcia 2019-09-02 08:48:55 -0700 (In reply to Chris Dumez from comment #71) > As of very recently (last week), the WebPageProxy ids and the WebPage ids > are now completely unrelated. I haven't merged those commits in our stable branch, FWIW. > The WebPage id now also changes on every > process swap. Note that Cocoa has code to support communication between the > UIProcess and the injected bundle. The way I made it work is that the > UIProcess side listens for IPC using the WebPageProxy id as IPC id. Because > this id is constant throughout the lifetime of the view, this allows the > UIProcess side object to receive IPC from all injected bundles (previous and > new process when process swapping). On the WebProcess side, the object > listens for IPC using the WebPage id as identifier, so we know which exact > object to route it to. On the UIProcess side, we always send messages to the > process currently associated with the WebPageProxy and use the WebPage id > that is currently associated to the WebPageProxy. This allows multiple to 1 > communication. The WebPage proxy always only talks to the committed process’ > bundle, but can receive IPC from all injected bundles associated with the > WebView. Thanks for your help Chris. 1567208 73 mcrha 2019-09-02 08:53:30 -0700 I see, that might be r249275, aka bug #201233. I'm going to switch to webkit-2.16 branch to see whether it's unaffected. 1567209 74 mcrha 2019-09-02 08:55:07 -0700 Err, I meant webkit-2.26 branch, of course. 1567218 75 mcatanzaro 2019-09-02 11:19:23 -0700 (In reply to Chris Dumez from comment #71) > As of very recently (last week), the WebPageProxy ids and the WebPage ids > are now completely unrelated. OK, that will break the world. :( 1567219 76 mcatanzaro 2019-09-02 11:22:36 -0700 So webkit_web_page_get_id() will need to be reimplemented in some way that gets its ID from the WebPageProxy in the UI process, rather than its WebPage. Ideally this would happen without sync IPC, but that might be hard. :/ 1567238 77 cdumez 2019-09-02 15:15:16 -0700 (In reply to Michael Catanzaro from comment #76) > So webkit_web_page_get_id() will need to be reimplemented in some way that > gets its ID from the WebPageProxy in the UI process, rather than its WebPage. > > Ideally this would happen without sync IPC, but that might be hard. :/ That’s easy, the WebPage already has a getter to gets the id of its WebPageProxy identifier. No IPC needed. 1567239 78 cdumez 2019-09-02 15:17:39 -0700 (In reply to Michael Catanzaro from comment #75) > (In reply to Chris Dumez from comment #71) > > As of very recently (last week), the WebPageProxy ids and the WebPage ids > > are now completely unrelated. > > OK, that will break the world. :( I think I will need details to understand why. So far I have not heard of any breakage on the Cocoa side (admittedly it is still early) but we have very intrusive clients using injected bundles. 1567248 79 mcatanzaro 2019-09-02 17:08:09 -0700 (In reply to Chris Dumez from comment #77) > That’s easy, the WebPage already has a getter to gets the id of its > WebPageProxy identifier. No IPC needed. OK, then it should be no problem to fix. (In reply to Chris Dumez from comment #78) > I think I will need details to understand why. So far I have not heard of > any breakage on the Cocoa side (admittedly it is still early) but we have > very intrusive clients using injected bundles. API users expect the WebKitWebPage's page ID to correspond to the WebKitWebView's page ID. It's the only way to associate a WebKitWebPage with its corresponding WebKitWebView, since they exist in separate processes. This entire bug report is about problems caused when the page ID doesn't match like it's expected to. Evolution uses the ID to direct messages to the right web process. If it doesn't match, the message gets sent to nowhere. Or, the Epiphany example above shows that Epiphany uses it to filter out web process messages intended for other web views, so the web view only processes the messages intended for it. 1567249 80 cdumez 2019-09-02 17:16:27 -0700 (In reply to Michael Catanzaro from comment #79) > (In reply to Chris Dumez from comment #77) > > That’s easy, the WebPage already has a getter to gets the id of its > > WebPageProxy identifier. No IPC needed. > > OK, then it should be no problem to fix. > > (In reply to Chris Dumez from comment #78) > > I think I will need details to understand why. So far I have not heard of > > any breakage on the Cocoa side (admittedly it is still early) but we have > > very intrusive clients using injected bundles. > > API users expect the WebKitWebPage's page ID to correspond to the > WebKitWebView's page ID. It's the only way to associate a WebKitWebPage with > its corresponding WebKitWebView, since they exist in separate processes. > > This entire bug report is about problems caused when the page ID doesn't > match like it's expected to. Evolution uses the ID to direct messages to the > right web process. If it doesn't match, the message gets sent to nowhere. > Or, the Epiphany example above shows that Epiphany uses it to filter out web > process messages intended for other web views, so the web view only > processes the messages intended for it. The bug title says PSON but looking at the very initial report, it looks like the issue is that there was code that expected a single WebProcess for all WebViews. This does not really seem PSON related. I guess it is because we dropped the process limit api. That said, we still support single process mode, so I am not sure why evolution cannot use that. 1567251 81 mcatanzaro 2019-09-02 17:18:05 -0700 Right, this isn't about PSON after all. I'll edit the title. (In reply to Chris Dumez from comment #77) > That’s easy, the WebPage already has a getter to gets the id of its > WebPageProxy identifier. No IPC needed. Hm, problem is the WebPageProxyIdentifer returned by WebPage::webPageProxyIdentifier is not going to match the Identifier returned by WebPageProxy::identifier, is it? That's what we need to match. 1567253 82 cdumez 2019-09-02 17:24:00 -0700 (In reply to Michael Catanzaro from comment #81) > Right, this isn't about PSON after all. I'll edit the title. > > (In reply to Chris Dumez from comment #77) > > That’s easy, the WebPage already has a getter to gets the id of its > > WebPageProxy identifier. No IPC needed. > > Hm, problem is the WebPageProxyIdentifer returned by > WebPage::webPageProxyIdentifier is not going to match the Identifier > returned by WebPageProxy::identifier, is it? That's what we need to match. Sure they will match. Why wouldn’t they? 1567254 83 cdumez 2019-09-02 17:25:13 -0700 (In reply to Chris Dumez from comment #82) > (In reply to Michael Catanzaro from comment #81) > > Right, this isn't about PSON after all. I'll edit the title. > > > > (In reply to Chris Dumez from comment #77) > > > That’s easy, the WebPage already has a getter to gets the id of its > > > WebPageProxy identifier. No IPC needed. > > > > Hm, problem is the WebPageProxyIdentifer returned by > > WebPage::webPageProxyIdentifier is not going to match the Identifier > > returned by WebPageProxy::identifier, is it? That's what we need to match. > > Sure they will match. Why wouldn’t they? A WebPageProxy can be associated with several WebPages throughout its lifetime but a given WebPage is always associated with a single WebPageProxy / view. 1567255 84 mcatanzaro 2019-09-02 17:34:44 -0700 (In reply to Chris Dumez from comment #82) > Sure they will match. Why wouldn’t they? In that case, I think we can change webkit_web_page_get_id() to return the WebPageProxyIdentifier instead of the PageIdentifier, and then we should be good. I see webkit_web_view_get_page_id() is already returning the WebPageProxyIdentifier, not the PageIdentifier, so that explains why the view doesn't return different page IDs after a process swap, like I was expecting it would. Nice. 1567261 85 mcatanzaro 2019-09-02 18:15:55 -0700 (In reply to Michael Catanzaro from comment #84) > In that case, I think we can change webkit_web_page_get_id() to return the > WebPageProxyIdentifier instead of the PageIdentifier, and then we should be > good. Yeah this works. Milan, please test: diff --git a/Source/WebKit/WebProcess/InjectedBundle/API/glib/WebKitWebPage.cpp b/Source/WebKit/WebProcess/InjectedBundle/API/glib/WebKitWebPage.cpp index c9204b23981..385dada2fc9 100644 --- a/Source/WebKit/WebProcess/InjectedBundle/API/glib/WebKitWebPage.cpp +++ b/Source/WebKit/WebProcess/InjectedBundle/API/glib/WebKitWebPage.cpp @@ -764,7 +764,7 @@ guint64 webkit_web_page_get_id(WebKitWebPage* webPage) { g_return_val_if_fail(WEBKIT_IS_WEB_PAGE(webPage), 0); - return webPage->priv->webPage->pageID().toUInt64(); + return webPage->priv->webPage->webPageProxyIdentifier().toUInt64(); } /** That's not going to fully fix your problem, because you filed this bug before this page ID trouble was introduced. But it's step one. 1567262 86 mcatanzaro 2019-09-02 18:17:48 -0700 (In reply to Chris Dumez from comment #80) > The bug title says PSON but looking at the very initial report, it looks > like the issue is that there was code that expected a single WebProcess for > all WebViews. This does not really seem PSON related. I guess it is because > we dropped the process limit api. That said, we still support single process > mode, so I am not sure why evolution cannot use that. P.S. The existing single process API is broken (see comment #12) and you told us not to add a non-broken version (in comment #30). 1567287 87 mcrha 2019-09-02 23:02:29 -0700 (In reply to Michael Catanzaro from comment #85) > Yeah this works. Milan, please test: I cannot test it at the moment, I switched to the webkit-2.26 branch, where Chris' changes are not included. Compiling webkitgtk+ is kind of nightmare here, thus I will test it some time later. You can give it a try with Epiphany, when it comes to it, or with the provided test programs above. > That's not going to fully fix your problem, because you filed this bug > before this page ID trouble was introduced. But it's step one. Right, it's not. Carlos gave me another patch to force single process behaviour with an environment variable, which fixes the initial problem for me. diff --git a/Source/WebKit/UIProcess/API/glib/WebKitWebContext.cpp b/Source/WebKit/UIProcess/API/glib/WebKitWebContext.cpp index 22a864591df..bf301edfe0b 100644 --- a/Source/WebKit/UIProcess/API/glib/WebKitWebContext.cpp +++ b/Source/WebKit/UIProcess/API/glib/WebKitWebContext.cpp @@ -348,6 +348,9 @@ ALLOW_DEPRECATED_DECLARATIONS_END } else if (!priv->localStorageDirectory.isNull()) configuration.setLocalStorageDirectory(FileSystem::stringFromFileSystemRepresentation(priv->localStorageDirectory.data())); + const char* useSingleWebProcess = getenv("WEBKIT_USE_SINGLE_WEB_PROCESS"); + if (useSingleWebProcess && strcmp(useSingleWebProcess, "0")) + configuration.setUsesSingleWebProcess(true); priv->processPool = WebProcessPool::create(configuration); if (!priv->websiteDataManager) 1567318 88 mcrha 2019-09-03 03:13:12 -0700 (In reply to Milan Crha from comment #87) > (In reply to Michael Catanzaro from comment #85) > > Yeah this works. Milan, please test: > > I cannot test it at the moment, I switched to the webkit-2.26 branch, where > Chris' changes are not included. Compiling webkitgtk+ is kind of nightmare > here, thus I will test it some time later. Unless I made any error, it looks like with your patch from comment #85 the webkit_web_page_get_id() returns the same ID as webkit_web_view_get_page_id(), but webkit_web_extension_get_page() returns NULL for this ID. 1567326 89 mcatanzaro 2019-09-03 03:34:34 -0700 (In reply to Milan Crha from comment #87) > I cannot test it at the moment, I switched to the webkit-2.26 branch, where > Chris' changes are not included. Compiling webkitgtk+ is kind of nightmare > here, thus I will test it some time later. You can give it a try with > Epiphany, when it comes to it, or with the provided test programs above. I checked Epiphany before posting the patch. It works. (Epiphany does not use webkit_web_extension_get_page().) But Evolution has additional problems, right? (In reply to Milan Crha from comment #88) > Unless I made any error, it looks like with your patch from comment #85 the > webkit_web_page_get_id() returns the same ID as > webkit_web_view_get_page_id(), but webkit_web_extension_get_page() returns > NULL for this ID. Oops, but fortunately that's also easy to fix: diff --git a/Source/WebKit/WebProcess/InjectedBundle/API/glib/WebKitWebExtension.cpp b/Source/WebKit/WebProcess/InjectedBundle/API/glib/WebKitWebExtension.cpp index e306e3fef26..a614d654f64 100644 --- a/Source/WebKit/WebProcess/InjectedBundle/API/glib/WebKitWebExtension.cpp +++ b/Source/WebKit/WebProcess/InjectedBundle/API/glib/WebKitWebExtension.cpp @@ -224,7 +224,7 @@ WebKitWebPage* webkit_web_extension_get_page(WebKitWebExtension* extension, guin WebKitWebExtensionPrivate* priv = extension->priv; WebPageMap::const_iterator end = priv->pages.end(); for (WebPageMap::const_iterator it = priv->pages.begin(); it != end; ++it) - if (it->key->pageID().toUInt64() == pageID) + if (it->key->webPageProxyIdentifier().toUInt64() == pageID) return it->value.get(); return 0; 1567362 90 mcrha 2019-09-03 05:54:42 -0700 (In reply to Michael Catanzaro from comment #89) > But Evolution has additional problems, right? Evolution has two problems: 1) it expects to have one WebKitWebProcess per one WebKitWebContext; 2) it relies on WebKitWebView::page-id match WebKitWebPage::id. The first is this bug, the second is a regression after bug #201233. As it's too late in the release cycle an r249421 adds a workaround for 2.26 for the 1), giving more time to solve this in a better way - if on WebKitGTK+ side, Evolution side or both sides is to be figured out. > Oops, but fortunately that's also easy to fix: Okay, that fixes evolution for the master branch as well (the 2) is not part of the webkit-2.26 branch). Looking into the changes: > - if (it->key->pageID().toUInt64() == pageID) > + if (it->key->webPageProxyIdentifier().toUInt64() == pageID) basically replacing pageID() with webPageProxyIdentifier() when checking against 'pageID', would it not make more sense to flip the two in the original change, thus keep consistency in the arguments and underlying code? I'm pretty sure that somebody will consider this a bug when webPageProxyIdentifier() is compared with pageID, when there exists pageID() member, some time in the future. Maybe we should move the discussion to the original bug #201233 about this. 1567369 91 mcatanzaro 2019-09-03 06:57:09 -0700 (In reply to Milan Crha from comment #90) > Evolution has two problems: > 1) it expects to have one WebKitWebProcess per one WebKitWebContext; > 2) it relies on WebKitWebView::page-id match WebKitWebPage::id. > > The first is this bug Right but (1) is not actually a bug, it's just the new intended behavior since 2.25.1 and Evolution will need to change somehow. > 2) it relies on WebKitWebView::page-id match WebKitWebPage::id. Hopefully my two patches fix this. (In reply to Milan Crha from comment #90) > Looking into the changes: > > > - if (it->key->pageID().toUInt64() == pageID) > > + if (it->key->webPageProxyIdentifier().toUInt64() == pageID) > > basically replacing pageID() with webPageProxyIdentifier() when checking > against 'pageID', would it not make more sense to flip the two in the > original change, thus keep consistency in the arguments and underlying code? > I'm pretty sure that somebody will consider this a bug when > webPageProxyIdentifier() is compared with pageID, when there exists pageID() > member, some time in the future. Maybe we should move the discussion to the > original bug #201233 about this. Good point. I don't know. If we use the pageID members instead of WebPageProxyIdentifier, then the same WebKitWebView will change page IDs, which could occur at unexpected times and break applications. If we use WebPageProxyIdentifier instead of pageID, the WebKitWebView will only ever expose a single ID, which is nice, but multiple WebKitWebPages will have the same ID, which might also break applications. I don't know which is least-risky or less-likely to cause problems in practice. 1567379 92 mcrha 2019-09-03 07:58:34 -0700 (In reply to Michael Catanzaro from comment #91) > If we use the pageID members instead of WebPageProxyIdentifier, then the > same WebKitWebView will change page IDs, which could occur at unexpected > times and break applications. > > If we use WebPageProxyIdentifier instead of pageID, the WebKitWebView will > only ever expose a single ID, which is nice, but multiple WebKitWebPages > will have the same ID, which might also break applications. From what I saw (see comment #41) there are up to four WebKitWebProcess-es running with the same page ID at the same time (with the svn trunk, not with webkit-2.26 branch). 1567382 93 mcatanzaro 2019-09-03 07:59:52 -0700 Yeah.... I guess multiple WebKitWebPages with the same ID is almost certain to cause problems (e.g. imagine storing them in a map keyed by page ID), so I suppose we should do the opposite of what my patches propose, and change WebKitWebView to return pageID instead of its Identifier, rather than changing WebKitWebPage and WebKitWebExtension. 1567681 94 mcrha 2019-09-04 01:16:28 -0700 (In reply to Milan Crha from comment #87) > + const char* useSingleWebProcess = > getenv("WEBKIT_USE_SINGLE_WEB_PROCESS"); > + if (useSingleWebProcess && strcmp(useSingleWebProcess, "0")) > + configuration.setUsesSingleWebProcess(true); With Michaels concerns about backward compatibility, and the above change already landed (r249421), what about flipping the above test, thus the default will be to use the SingleWebProcess, thus no old application will need any change, but new applications will be able to enable the multi-web processes using the same variable? Something like this: - if (useSingleWebProcess && strcmp(useSingleWebProcess, "0")) - configuration.setUsesSingleWebProcess(true); + configuration.setUsesSingleWebProcess(!useSingleWebProcess || strcmp(useSingleWebProcess, "0")) 1567683 95 cgarcia 2019-09-04 01:20:52 -0700 (In reply to Milan Crha from comment #94) > (In reply to Milan Crha from comment #87) > > + const char* useSingleWebProcess = > > getenv("WEBKIT_USE_SINGLE_WEB_PROCESS"); > > + if (useSingleWebProcess && strcmp(useSingleWebProcess, "0")) > > + configuration.setUsesSingleWebProcess(true); > > With Michaels concerns about backward compatibility, and the above change > already landed (r249421), what about flipping the above test, thus the > default will be to use the SingleWebProcess, thus no old application will > need any change, but new applications will be able to enable the multi-web > processes using the same variable? Something like this: > > - if (useSingleWebProcess && strcmp(useSingleWebProcess, "0")) > - configuration.setUsesSingleWebProcess(true); > + configuration.setUsesSingleWebProcess(!useSingleWebProcess || > strcmp(useSingleWebProcess, "0")) That would break applications setting multi-process model, we want to encourage apps using single process model to adapt to multiprocess. 1567700 96 cgarcia 2019-09-04 03:12:58 -0700 (In reply to Michael Catanzaro from comment #84) > (In reply to Chris Dumez from comment #82) > > Sure they will match. Why wouldn’t they? > > In that case, I think we can change webkit_web_page_get_id() to return the > WebPageProxyIdentifier instead of the PageIdentifier, and then we should be > good. > > I see webkit_web_view_get_page_id() is already returning the > WebPageProxyIdentifier, not the PageIdentifier, so that explains why the > view doesn't return different page IDs after a process swap, like I was > expecting it would. Nice. That's a bug introduced in r249275. webkit_web_view_get_page_id() is expected to return the webPageID() not the identifier(), that would be webkit_web_view_get_id() that we don't really want to expose. 1567709 97 cgarcia 2019-09-04 04:55:13 -0700 (In reply to Michael Catanzaro from comment #89) > (In reply to Milan Crha from comment #87) > > I cannot test it at the moment, I switched to the webkit-2.26 branch, where > > Chris' changes are not included. Compiling webkitgtk+ is kind of nightmare > > here, thus I will test it some time later. You can give it a try with > > Epiphany, when it comes to it, or with the provided test programs above. > > I checked Epiphany before posting the patch. It works. (Epiphany does not > use webkit_web_extension_get_page().) But Evolution has additional problems, > right? > > (In reply to Milan Crha from comment #88) > > Unless I made any error, it looks like with your patch from comment #85 the > > webkit_web_page_get_id() returns the same ID as > > webkit_web_view_get_page_id(), but webkit_web_extension_get_page() returns > > NULL for this ID. > > Oops, but fortunately that's also easy to fix: > > diff --git > a/Source/WebKit/WebProcess/InjectedBundle/API/glib/WebKitWebExtension.cpp > b/Source/WebKit/WebProcess/InjectedBundle/API/glib/WebKitWebExtension.cpp > index e306e3fef26..a614d654f64 100644 > --- a/Source/WebKit/WebProcess/InjectedBundle/API/glib/WebKitWebExtension.cpp > +++ b/Source/WebKit/WebProcess/InjectedBundle/API/glib/WebKitWebExtension.cpp > @@ -224,7 +224,7 @@ WebKitWebPage* > webkit_web_extension_get_page(WebKitWebExtension* extension, guin > WebKitWebExtensionPrivate* priv = extension->priv; > WebPageMap::const_iterator end = priv->pages.end(); > for (WebPageMap::const_iterator it = priv->pages.begin(); it != end; > ++it) > - if (it->key->pageID().toUInt64() == pageID) > + if (it->key->webPageProxyIdentifier().toUInt64() == pageID) > return it->value.get(); > > return 0; I don't think this is correct, here we want the page identifier, which is what webkit_web_view_get_page_id() should return. 1567712 98 mcrha 2019-09-04 05:18:41 -0700 (In reply to Carlos Garcia Campos from comment #95) > That would break applications setting multi-process model, we want to > encourage apps using single process model to adapt to multiprocess. I understood there is no such setting, that's why the env variable had been added (otherwise I'd use it and turn it off using WebKitGTK+ API). While I can understand your concern for new applications, Michaels concern about backward compatibility is also strong. Yes, it'll postpone the problem only one major release forward, but it's better than breaking the world now, when things are too new. Not talking that multiprocess never worked out-of-the-box anyway (comment #14). Eventually, make the deprecation less cruel (r249419), though old applications would still need to use the deprecated API to get the old behaviour (mine concern, an ideal state, is to not need to change anything in legacy applications, no matter what WebKitGTK+ they'll run (not compile) against). I do not know how this works in Debian, but for Fedora the major release (2.26) would usually go only to Fedora 31, but webkit2gtk3 maintainers update it also for Fedora 30 and Fedora 29. It's fine as long as the update doesn't change soname versions and doesn't break existing applications. You cannot expect all the applications in Fedora 30 and 29 to be updated due to changes in WebKitGTK+, neither with soname version, nor with core functionality. That's even not allowed, when it comes to it. Michael wants to be able to do the updates in all three Fedoras and in Debian - without custom patches, I believe. 1567716 99 cgarcia 2019-09-04 05:32:21 -0700 (In reply to Milan Crha from comment #98) > (In reply to Carlos Garcia Campos from comment #95) > > That would break applications setting multi-process model, we want to > > encourage apps using single process model to adapt to multiprocess. > > I understood there is no such setting, that's why the env variable had been > added (otherwise I'd use it and turn it off using WebKitGTK+ API). While I > can understand your concern for new applications, Michaels concern about > backward compatibility is also strong. Yes, it'll postpone the problem only > one major release forward, but it's better than breaking the world now, when > things are too new. Not talking that multiprocess never worked > out-of-the-box anyway (comment #14). Eventually, make the deprecation less > cruel (r249419), though old applications would still need to use the > deprecated API to get the old behaviour (mine concern, an ideal state, is to > not need to change anything in legacy applications, no matter what > WebKitGTK+ they'll run (not compile) against). There's webkit_web_context_set_process_model() that receives a WebKitProcessModel. WEBKIT_PROCESS_MODEL_SHARED_SECONDARY_PROCESS was the default, that's why you didn't have to set it explicitly, but it's now deprecated. Normally, in case of deprecation, the old behavior is preserved, but in this case the feature has been removed for security reasons. I know this can be considered an API break, though. So, let's figure out if there are more apps that depend on the single process model to see what to do. If it's only evo, it's already fixed and we only need to ensure that for the next release cycle evo can work in multiprocess model. > I do not know how this works in Debian, but for Fedora the major release > (2.26) would usually go only to Fedora 31, but webkit2gtk3 maintainers > update it also for Fedora 30 and Fedora 29. It's fine as long as the update > doesn't change soname versions and doesn't break existing applications. You > cannot expect all the applications in Fedora 30 and 29 to be updated due to > changes in WebKitGTK+, neither with soname version, nor with core > functionality. That's even not allowed, when it comes to it. Michael wants > to be able to do the updates in all three Fedoras and in Debian - without > custom patches, I believe. Right, that's why we first need to figure out what other apps are broken. 1567717 100 cgarcia 2019-09-04 05:34:41 -0700 btw, I think we should move the discussion about single process model deprecation somewhere else, and keep this bug for the page id mismatch in current trunk. Bug #200967 already covers the page-created issue when loading history items from the page cache. 1568009 101 mcrha 2019-09-04 22:50:08 -0700 For the record, I just reopened the Evolution bug (comment #0), which I'll use for changes on the Evolution side to work properly with multiple WebKitWebProcess-es being spawn for a single WebKitWebView. 1575480 102 cgarcia 2019-10-01 03:22:55 -0700 I think we can close this. Bug #201642 handles the new API to monitor page id changes and bug #200967 will make PSON optional and disabled by default to keep backwards compatibility. Feel free to reopen if there are still problems with the ids. 377009 2019-08-22 08:44:13 -0700 2019-08-23 01:00:38 -0700 Patch bug-201033-20190822184412.patch text/plain 7971 csaavedra U3VidmVyc2lvbiBSZXZpc2lvbjogMjQ5MDAwCmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViS2l0L0No YW5nZUxvZyBiL1NvdXJjZS9XZWJLaXQvQ2hhbmdlTG9nCmluZGV4IGI1OGZhNDMxNjQyZTdmNjMx ZDkyZWJhOTAyODA2ZjFkODZhMzZmOTkuLjA3YWI1MzU5YTJlYTc3MjJlODQyMzRmMGZlZWE5ZjUw NTlkMGZlNWEgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XZWJLaXQvQ2hhbmdlTG9nCisrKyBiL1NvdXJj ZS9XZWJLaXQvQ2hhbmdlTG9nCkBAIC0xLDMgKzEsMjUgQEAKKzIwMTktMDgtMjIgIENsYXVkaW8g U2FhdmVkcmEgIDxjc2FhdmVkcmFAaWdhbGlhLmNvbT4KKworICAgICAgICBbV1BFXVtHVEtdIERl cHJlY2F0ZSB3ZWIgcHJvY2VzcyBjb3VudCBsaW1pdCBhbmQgZXhwb3NlIHVzZXNTaW5nbGVXZWJQ cm9jZXNzKCkKKyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lk PTIwMTAzMworCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAg IFRoZSB3ZWIgcHJvY2VzcyBjb3VudCBsaW1pdCBnb3QgZGVwcmVjYXRlZCBhbmQgbWFkZSBpbnRv IGEgbm8tb3AKKyAgICAgICAgaW4gcjI0MDM2Mywgc28gd2Ugc2hvdWxkIGRlcHJlY2F0ZSBpdCB0 b28uIEV4cG9zZSBpbnN0ZWFkIHRoZQorICAgICAgICBuZXdseSBhZGRlZCB1c2VzU2luZ2xlV2Vi UHJvY2VzcyBTUEkuCisKKyAgICAgICAgKiBVSVByb2Nlc3MvQVBJL2dsaWIvV2ViS2l0V2ViQ29u dGV4dC5jcHA6CisgICAgICAgICh3ZWJraXRXZWJDb250ZXh0Q29uc3RydWN0ZWQpOgorICAgICAg ICAod2Via2l0X3dlYl9jb250ZXh0X3NldF93ZWJfcHJvY2Vzc19jb3VudF9saW1pdCk6CisgICAg ICAgICh3ZWJraXRfd2ViX2NvbnRleHRfZ2V0X3dlYl9wcm9jZXNzX2NvdW50X2xpbWl0KToKKyAg ICAgICAgKHdlYmtpdF93ZWJfY29udGV4dF9zZXRfdXNlc19zaW5nbGVfd2ViX3Byb2Nlc3MpOgor ICAgICAgICAod2Via2l0X3dlYl9jb250ZXh0X2dldF91c2VzX3NpbmdsZV93ZWJfcHJvY2Vzcyk6 CisgICAgICAgICogVUlQcm9jZXNzL0FQSS9ndGsvV2ViS2l0V2ViQ29udGV4dC5oOgorICAgICAg ICAqIFVJUHJvY2Vzcy9BUEkvZ3RrL2RvY3Mvd2Via2l0Mmd0ay00LjAtc2VjdGlvbnMudHh0Ogor ICAgICAgICAqIFVJUHJvY2Vzcy9BUEkvd3BlL1dlYktpdFdlYkNvbnRleHQuaDoKKyAgICAgICAg KiBVSVByb2Nlc3MvQVBJL3dwZS9kb2NzL3dwZS0xLjAtc2VjdGlvbnMudHh0OgorCiAyMDE5LTA4 LTIyICBDbGF1ZGlvIFNhYXZlZHJhICA8Y3NhYXZlZHJhQGlnYWxpYS5jb20+CiAKICAgICAgICAg W1NPVVBdIE5ldHdvcmtQcm9jZXNzU291cCBkb2VzIG5vdCBpbml0aWFsaXplIENhY2hlT3B0aW9u cyBjb3JyZWN0bHkKZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJLaXQvVUlQcm9jZXNzL0FQSS9nbGli L1dlYktpdFdlYkNvbnRleHQuY3BwIGIvU291cmNlL1dlYktpdC9VSVByb2Nlc3MvQVBJL2dsaWIv V2ViS2l0V2ViQ29udGV4dC5jcHAKaW5kZXggOGM2ODk4Mjk1MzlmNDIyMzhiMzA3ZjU1NTYwOGE1 YzUwMDJkY2Y0My4uODE3NzZhODdiMDdiZjg1ODBjNGJmMTcxMzdkZTgxNTIwMDAwOWRjNSAxMDA2 NDQKLS0tIGEvU291cmNlL1dlYktpdC9VSVByb2Nlc3MvQVBJL2dsaWIvV2ViS2l0V2ViQ29udGV4 dC5jcHAKKysrIGIvU291cmNlL1dlYktpdC9VSVByb2Nlc3MvQVBJL2dsaWIvV2ViS2l0V2ViQ29u dGV4dC5jcHAKQEAgLTE3Niw3ICsxNzYsNyBAQCBzdHJ1Y3QgX1dlYktpdFdlYkNvbnRleHRQcml2 YXRlIHsKICAgICBDU3RyaW5nIGZhdmljb25EYXRhYmFzZURpcmVjdG9yeTsKICAgICBXZWJLaXRU TFNFcnJvcnNQb2xpY3kgdGxzRXJyb3JzUG9saWN5OwogICAgIFdlYktpdFByb2Nlc3NNb2RlbCBw cm9jZXNzTW9kZWw7Ci0gICAgdW5zaWduZWQgcHJvY2Vzc0NvdW50TGltaXQ7CisgICAgYm9vbCB1 c2VzU2luZ2xlV2ViUHJvY2VzczsKIAogICAgIEhhc2hNYXA8dWludDY0X3QsIFdlYktpdFdlYlZp ZXcqPiB3ZWJWaWV3czsKICAgICB1bnNpZ25lZCBlcGhlbWVyYWxQYWdlQ291bnQ7CkBAIC0zNDcs NiArMzQ3LDkgQEAgQUxMT1dfREVQUkVDQVRFRF9ERUNMQVJBVElPTlNfRU5ECiAgICAgfSBlbHNl IGlmICghcHJpdi0+bG9jYWxTdG9yYWdlRGlyZWN0b3J5LmlzTnVsbCgpKQogICAgICAgICBjb25m aWd1cmF0aW9uLnNldExvY2FsU3RvcmFnZURpcmVjdG9yeShGaWxlU3lzdGVtOjpzdHJpbmdGcm9t RmlsZVN5c3RlbVJlcHJlc2VudGF0aW9uKHByaXYtPmxvY2FsU3RvcmFnZURpcmVjdG9yeS5kYXRh KCkpKTsKIAorICAgIHByaXYtPnVzZXNTaW5nbGVXZWJQcm9jZXNzID0gdHJ1ZTsKKyAgICBjb25m aWd1cmF0aW9uLnNldFVzZXNTaW5nbGVXZWJQcm9jZXNzKHByaXYtPnVzZXNTaW5nbGVXZWJQcm9j ZXNzKTsKKwogICAgIHByaXYtPnByb2Nlc3NQb29sID0gV2ViUHJvY2Vzc1Bvb2w6OmNyZWF0ZShj b25maWd1cmF0aW9uKTsKIAogICAgIGlmICghcHJpdi0+d2Vic2l0ZURhdGFNYW5hZ2VyKQpAQCAt MTU5MSwxMSArMTU5NCw2IEBAIFdlYktpdFByb2Nlc3NNb2RlbCB3ZWJraXRfd2ViX2NvbnRleHRf Z2V0X3Byb2Nlc3NfbW9kZWwoV2ViS2l0V2ViQ29udGV4dCogY29udGV4CiB2b2lkIHdlYmtpdF93 ZWJfY29udGV4dF9zZXRfd2ViX3Byb2Nlc3NfY291bnRfbGltaXQoV2ViS2l0V2ViQ29udGV4dCog Y29udGV4dCwgZ3VpbnQgbGltaXQpCiB7CiAgICAgZ19yZXR1cm5faWZfZmFpbChXRUJLSVRfSVNf V0VCX0NPTlRFWFQoY29udGV4dCkpOwotCi0gICAgaWYgKGNvbnRleHQtPnByaXYtPnByb2Nlc3ND b3VudExpbWl0ID09IGxpbWl0KQotICAgICAgICByZXR1cm47Ci0KLSAgICBjb250ZXh0LT5wcml2 LT5wcm9jZXNzQ291bnRMaW1pdCA9IGxpbWl0OwogfQogCiAvKioKQEAgLTE2MTIsNyArMTYxMCw0 NSBAQCBndWludCB3ZWJraXRfd2ViX2NvbnRleHRfZ2V0X3dlYl9wcm9jZXNzX2NvdW50X2xpbWl0 KFdlYktpdFdlYkNvbnRleHQqIGNvbnRleHQpCiB7CiAgICAgZ19yZXR1cm5fdmFsX2lmX2ZhaWwo V0VCS0lUX0lTX1dFQl9DT05URVhUKGNvbnRleHQpLCAwKTsKIAotICAgIHJldHVybiBjb250ZXh0 LT5wcml2LT5wcm9jZXNzQ291bnRMaW1pdDsKKyAgICByZXR1cm4gMDsKK30KKworLyoqCisgKiB3 ZWJraXRfd2ViX2NvbnRleHRfc2V0X3VzZXNfc2luZ2xlX3dlYl9wcm9jZXNzOgorICogQGNvbnRl eHQ6IHRoZSAjV2ViS2l0V2ViQ29udGV4dAorICogQHVzZXNTaW5nbGVXZWJQcm9jZXNzOiBXaGV0 aGVyIHRvIHVzZSBhIHNpbmdsZSB3ZWIgcHJvY2VzcyBwZXIgY29udGV4dAorICoKKyAqIFNldHMg d2hldGhlciBAY29udGV4dCBzaG91bGQgdXNlIGEgc2luZ2xlIHdlYiBwcm9jZXNzIHBlciBjb250 ZXh0LiBUaGUgZGVmYXVsdCBpcyAjRkFMU0UgdG8gYWxsb3cKKyAqIGEgY29udGV4dCB0byBoYXZl IG11bHRpcGxlIHdlYiBwcm9jZXNzZXMuCisgKgorICogU2luY2U6IDIuMjYKKyAqKi8KK3ZvaWQg d2Via2l0X3dlYl9jb250ZXh0X3NldF91c2VzX3NpbmdsZV93ZWJfcHJvY2VzcyhXZWJLaXRXZWJD b250ZXh0KiBjb250ZXh0LCBnYm9vbGVhbiB1c2VzU2luZ2xlV2ViUHJvY2VzcykKK3sKKyAgICBn X3JldHVybl9pZl9mYWlsKFdFQktJVF9JU19XRUJfQ09OVEVYVChjb250ZXh0KSk7CisKKyAgICBp ZiAoY29udGV4dC0+cHJpdi0+dXNlc1NpbmdsZVdlYlByb2Nlc3MgPT0gdXNlc1NpbmdsZVdlYlBy b2Nlc3MpCisgICAgICAgIHJldHVybjsKKworICAgIGNvbnRleHQtPnByaXYtPnVzZXNTaW5nbGVX ZWJQcm9jZXNzID0gdXNlc1NpbmdsZVdlYlByb2Nlc3M7CisgICAgY29udGV4dC0+cHJpdi0+cHJv Y2Vzc1Bvb2wtPmNvbmZpZ3VyYXRpb24oKS5zZXRVc2VzU2luZ2xlV2ViUHJvY2Vzcyh1c2VzU2lu Z2xlV2ViUHJvY2Vzcyk7Cit9CisKKy8qKgorICogd2Via2l0X3dlYl9jb250ZXh0X2dldF91c2Vz X3NpbmdsZV93ZWJfcHJvY2VzczoKKyAqIEBjb250ZXh0OiB0aGUgI1dlYktpdFdlYkNvbnRleHQK KyAqCisgKiBXaGV0aGVyIEBjb250ZXh0IGlzIGxpbWl0ZWQgdG8gYSBzaW5nbGUgd2ViIHByb2Nl c3MuCisgKgorICogUmV0dXJuczogI1RSVUUgaWYgQGNvbnRleHQgaXMgbGltaXRlZCB0byBhIHNp bmdsZSB3ZWIgcHJvY2VzcywgI0ZBTFNFIG90aGVyd2lzZS4KKyAqCisgKiBTaW5jZTogMi4yNgor ICoqLworZ2Jvb2xlYW4gd2Via2l0X3dlYl9jb250ZXh0X2dldF91c2VzX3NpbmdsZV93ZWJfcHJv Y2VzcyhXZWJLaXRXZWJDb250ZXh0KiBjb250ZXh0KQoreworICAgIGdfcmV0dXJuX3ZhbF9pZl9m YWlsKFdFQktJVF9JU19XRUJfQ09OVEVYVChjb250ZXh0KSwgRkFMU0UpOworCisgICAgcmV0dXJu IGNvbnRleHQtPnByaXYtPnVzZXNTaW5nbGVXZWJQcm9jZXNzOwogfQogCiBzdGF0aWMgdm9pZCBh ZGRPcmlnaW5Ub01hcChXZWJLaXRTZWN1cml0eU9yaWdpbiogb3JpZ2luLCBIYXNoTWFwPFN0cmlu ZywgYm9vbD4qIG1hcCwgYm9vbCBhbGxvd2VkKQpkaWZmIC0tZ2l0IGEvU291cmNlL1dlYktpdC9V SVByb2Nlc3MvQVBJL2d0ay9XZWJLaXRXZWJDb250ZXh0LmggYi9Tb3VyY2UvV2ViS2l0L1VJUHJv Y2Vzcy9BUEkvZ3RrL1dlYktpdFdlYkNvbnRleHQuaAppbmRleCA4MmE4ZDgyOGRmYTE3MTI0MzJh ZDMzMmRiOGIwNmEzZjUzMjc3ZTkzLi44NWY1OTRiNmUzMzdmZmY1YzRjYTA4MTM4YjkzOTJmNzc1 Mzk1NGE5IDEwMDY0NAotLS0gYS9Tb3VyY2UvV2ViS2l0L1VJUHJvY2Vzcy9BUEkvZ3RrL1dlYktp dFdlYkNvbnRleHQuaAorKysgYi9Tb3VyY2UvV2ViS2l0L1VJUHJvY2Vzcy9BUEkvZ3RrL1dlYktp dFdlYkNvbnRleHQuaApAQCAtMjAwLDYgKzIwMCwxMyBAQCB3ZWJraXRfd2ViX2NvbnRleHRfc2V0 X3dlYl9wcm9jZXNzX2NvdW50X2xpbWl0ICAgICAgKFdlYktpdFdlYkNvbnRleHQKIFdFQktJVF9B UEkgZ3VpbnQKIHdlYmtpdF93ZWJfY29udGV4dF9nZXRfd2ViX3Byb2Nlc3NfY291bnRfbGltaXQg ICAgICAoV2ViS2l0V2ViQ29udGV4dCAgICAgICAgICAgICAgKmNvbnRleHQpOwogCitXRUJLSVRf QVBJIHZvaWQKK3dlYmtpdF93ZWJfY29udGV4dF9zZXRfdXNlc19zaW5nbGVfd2ViX3Byb2Nlc3Mg ICAgICAoV2ViS2l0V2ViQ29udGV4dCAgICAgICAgICAgICAgKmNvbnRleHQsCisgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGdib29sZWFuICAgICAg ICAgICAgICAgICAgICAgICB1c2VzU2luZ2xlV2ViUHJvY2Vzcyk7CisKK1dFQktJVF9BUEkgZ2Jv b2xlYW4KK3dlYmtpdF93ZWJfY29udGV4dF9nZXRfdXNlc19zaW5nbGVfd2ViX3Byb2Nlc3MgICAg ICAoV2ViS2l0V2ViQ29udGV4dCAgICAgICAgICAgICAgKmNvbnRleHQpOworCiBXRUJLSVRfQVBJ IHZvaWQKIHdlYmtpdF93ZWJfY29udGV4dF9jbGVhcl9jYWNoZSAgICAgICAgICAgICAgICAgICAg ICAoV2ViS2l0V2ViQ29udGV4dCAgICAgICAgICAgICAgKmNvbnRleHQpOwogCmRpZmYgLS1naXQg YS9Tb3VyY2UvV2ViS2l0L1VJUHJvY2Vzcy9BUEkvZ3RrL2RvY3Mvd2Via2l0Mmd0ay00LjAtc2Vj dGlvbnMudHh0IGIvU291cmNlL1dlYktpdC9VSVByb2Nlc3MvQVBJL2d0ay9kb2NzL3dlYmtpdDJn dGstNC4wLXNlY3Rpb25zLnR4dAppbmRleCBkZjU4NWEyZTZkZWVhMzg5NGFjZjk0MzA5M2NlM2Ex N2IwNzM1MjcyLi45NDQ2OWIxYzgxNzM2NzE4N2VlMTgxNTc1NmQyZTExOWU1OGU0MjI0IDEwMDY0 NAotLS0gYS9Tb3VyY2UvV2ViS2l0L1VJUHJvY2Vzcy9BUEkvZ3RrL2RvY3Mvd2Via2l0Mmd0ay00 LjAtc2VjdGlvbnMudHh0CisrKyBiL1NvdXJjZS9XZWJLaXQvVUlQcm9jZXNzL0FQSS9ndGsvZG9j cy93ZWJraXQyZ3RrLTQuMC1zZWN0aW9ucy50eHQKQEAgLTQwLDYgKzQwLDggQEAgd2Via2l0X3dl Yl9jb250ZXh0X2dldF9jYWNoZV9tb2RlbAogd2Via2l0X3dlYl9jb250ZXh0X3NldF9jYWNoZV9t b2RlbAogd2Via2l0X3dlYl9jb250ZXh0X2dldF93ZWJfcHJvY2Vzc19jb3VudF9saW1pdAogd2Vi a2l0X3dlYl9jb250ZXh0X3NldF93ZWJfcHJvY2Vzc19jb3VudF9saW1pdAord2Via2l0X3dlYl9j b250ZXh0X2dldF91c2VzX3NpbmdsZV93ZWJfcHJvY2Vzcword2Via2l0X3dlYl9jb250ZXh0X3Nl dF91c2VzX3NpbmdsZV93ZWJfcHJvY2Vzcwogd2Via2l0X3dlYl9jb250ZXh0X2NsZWFyX2NhY2hl CiB3ZWJraXRfd2ViX2NvbnRleHRfc2V0X25ldHdvcmtfcHJveHlfc2V0dGluZ3MKIHdlYmtpdF93 ZWJfY29udGV4dF9kb3dubG9hZF91cmkKZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJLaXQvVUlQcm9j ZXNzL0FQSS93cGUvV2ViS2l0V2ViQ29udGV4dC5oIGIvU291cmNlL1dlYktpdC9VSVByb2Nlc3Mv QVBJL3dwZS9XZWJLaXRXZWJDb250ZXh0LmgKaW5kZXggYTMyNjgwZmE4MzA1MDBiZmI1MzAzMjY5 MTcxMDQzMmY4Mjg3NGU3ZC4uMWI5M2ZlZjM0MGE4MzEyODc0MGY4MjgxZmZiNGIzOTRjNmRlNDE3 YyAxMDA2NDQKLS0tIGEvU291cmNlL1dlYktpdC9VSVByb2Nlc3MvQVBJL3dwZS9XZWJLaXRXZWJD b250ZXh0LmgKKysrIGIvU291cmNlL1dlYktpdC9VSVByb2Nlc3MvQVBJL3dwZS9XZWJLaXRXZWJD b250ZXh0LmgKQEAgLTIwMCw2ICsyMDAsMTMgQEAgd2Via2l0X3dlYl9jb250ZXh0X3NldF93ZWJf cHJvY2Vzc19jb3VudF9saW1pdCAgICAgIChXZWJLaXRXZWJDb250ZXh0CiBXRUJLSVRfQVBJIGd1 aW50CiB3ZWJraXRfd2ViX2NvbnRleHRfZ2V0X3dlYl9wcm9jZXNzX2NvdW50X2xpbWl0ICAgICAg KFdlYktpdFdlYkNvbnRleHQgICAgICAgICAgICAgICpjb250ZXh0KTsKIAorV0VCS0lUX0FQSSB2 b2lkCit3ZWJraXRfd2ViX2NvbnRleHRfc2V0X3VzZXNfc2luZ2xlX3dlYl9wcm9jZXNzICAgICAg KFdlYktpdFdlYkNvbnRleHQgICAgICAgICAgICAgICpjb250ZXh0LAorICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBnYm9vbGVhbiAgICAgICAgICAg ICAgICAgICAgICAgdXNlc1NpbmdsZVdlYlByb2Nlc3MpOworCitXRUJLSVRfQVBJIGdib29sZWFu Cit3ZWJraXRfd2ViX2NvbnRleHRfZ2V0X3VzZXNfc2luZ2xlX3dlYl9wcm9jZXNzICAgICAgKFdl YktpdFdlYkNvbnRleHQgICAgICAgICAgICAgICpjb250ZXh0KTsKKwogV0VCS0lUX0FQSSB2b2lk CiB3ZWJraXRfd2ViX2NvbnRleHRfY2xlYXJfY2FjaGUgICAgICAgICAgICAgICAgICAgICAgKFdl YktpdFdlYkNvbnRleHQgICAgICAgICAgICAgICpjb250ZXh0KTsKIApkaWZmIC0tZ2l0IGEvU291 cmNlL1dlYktpdC9VSVByb2Nlc3MvQVBJL3dwZS9kb2NzL3dwZS0xLjAtc2VjdGlvbnMudHh0IGIv U291cmNlL1dlYktpdC9VSVByb2Nlc3MvQVBJL3dwZS9kb2NzL3dwZS0xLjAtc2VjdGlvbnMudHh0 CmluZGV4IDY0ZWEzMGU5M2NkNGU5ZGQyNGMzNjNmNzk3M2MwZWYwY2RjMGNhZWEuLjMwYjE1YzQ2 OWYwMTQ5Njg4ODljMTVjOWMyZjEyMTVlNjgwMjg5MzMgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XZWJL aXQvVUlQcm9jZXNzL0FQSS93cGUvZG9jcy93cGUtMS4wLXNlY3Rpb25zLnR4dAorKysgYi9Tb3Vy Y2UvV2ViS2l0L1VJUHJvY2Vzcy9BUEkvd3BlL2RvY3Mvd3BlLTEuMC1zZWN0aW9ucy50eHQKQEAg LTE4LDYgKzE4LDggQEAgd2Via2l0X3dlYl9jb250ZXh0X2dldF9jYWNoZV9tb2RlbAogd2Via2l0 X3dlYl9jb250ZXh0X3NldF9jYWNoZV9tb2RlbAogd2Via2l0X3dlYl9jb250ZXh0X2dldF93ZWJf cHJvY2Vzc19jb3VudF9saW1pdAogd2Via2l0X3dlYl9jb250ZXh0X3NldF93ZWJfcHJvY2Vzc19j b3VudF9saW1pdAord2Via2l0X3dlYl9jb250ZXh0X2dldF91c2VzX3NpbmdsZV93ZWJfcHJvY2Vz cword2Via2l0X3dlYl9jb250ZXh0X3NldF91c2VzX3NpbmdsZV93ZWJfcHJvY2Vzcwogd2Via2l0 X3dlYl9jb250ZXh0X2NsZWFyX2NhY2hlCiB3ZWJraXRfd2ViX2NvbnRleHRfc2V0X25ldHdvcmtf cHJveHlfc2V0dGluZ3MKIHdlYmtpdF93ZWJfY29udGV4dF9kb3dubG9hZF91cmkK 377109 2019-08-23 01:00:42 -0700 2019-08-29 23:36:30 -0700 Patch bug-201033-20190823110041.patch text/plain 9337 csaavedra U3VidmVyc2lvbiBSZXZpc2lvbjogMjQ5MDAwCmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViS2l0L0No YW5nZUxvZyBiL1NvdXJjZS9XZWJLaXQvQ2hhbmdlTG9nCmluZGV4IGI1OGZhNDMxNjQyZTdmNjMx ZDkyZWJhOTAyODA2ZjFkODZhMzZmOTkuLjRkYzk3ZWZlZmQ0YzM3OWViY2FjYWI1MDY4ZjNmMDgy MzQ2NTkzYWIgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XZWJLaXQvQ2hhbmdlTG9nCisrKyBiL1NvdXJj ZS9XZWJLaXQvQ2hhbmdlTG9nCkBAIC0xLDMgKzEsMzMgQEAKKzIwMTktMDgtMjIgIENsYXVkaW8g U2FhdmVkcmEgIDxjc2FhdmVkcmFAaWdhbGlhLmNvbT4KKworICAgICAgICBbV1BFXVtHVEtdIERl cHJlY2F0ZSB3ZWIgcHJvY2VzcyBjb3VudCBsaW1pdCBhbmQgZXhwb3NlIHVzZXNTaW5nbGVXZWJQ cm9jZXNzKCkKKyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lk PTIwMTAzMworCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAg IFRoZSB3ZWIgcHJvY2VzcyBjb3VudCBsaW1pdCBnb3QgZGVwcmVjYXRlZCBhbmQgbWFkZSBpbnRv IGEgbm8tb3AKKyAgICAgICAgaW4gcjI0MDM2Mywgc28gd2Ugc2hvdWxkIGRlcHJlY2F0ZSBpdCB0 b28uIEV4cG9zZSBpbnN0ZWFkIHRoZQorICAgICAgICBuZXdseSBhZGRlZCB1c2VzU2luZ2xlV2Vi UHJvY2VzcyBTUEkuCisKKyAgICAgICAgQmVjYXVzZSBvZiBob3cgZWFybHkgdGhlIHNpbmdsZSB3 ZWIgcHJvY2VzcyBTUEkgaXMgdXNlZAorICAgICAgICBpbnRlcm5hbGx5LCB3ZSBjYW4gb25seSBl eHBvc2UgaXQgYXMgYSBjb25zdHJ1Y3Qtb25seSBwcm9wZXJ0eSBpbgorICAgICAgICBXZWJLaXRX ZWJDb250ZXh0IHRoYXQgY2Fubm90IGJlIG1vZGlmaWVkIGxhdGVyLiBIb3dldmVyLCBzaW5jZSBm b3IKKyAgICAgICAgc2VjdXJpdHkgcmVhc29ucyB0aGUgZGVmYXVsdCB2YWx1ZSBvZiBGYWxzZSBp cyB0aGUgcmVjb21tZW5kZWQgZm9yCisgICAgICAgIHdlYiBicm93c2VycywgdGhpcyBsaW1pdGF0 aW9uIHNob3VsZG4ndCBiZSBpbXBvcnRhbnQuCisKKyAgICAgICAgKiBVSVByb2Nlc3MvQVBJL2ds aWIvV2ViS2l0V2ViQ29udGV4dC5jcHA6CisgICAgICAgICh3ZWJraXRXZWJDb250ZXh0R2V0UHJv cGVydHkpOgorICAgICAgICAod2Via2l0V2ViQ29udGV4dFNldFByb3BlcnR5KToKKyAgICAgICAg KHdlYmtpdFdlYkNvbnRleHRDb25zdHJ1Y3RlZCk6CisgICAgICAgICh3ZWJraXRfd2ViX2NvbnRl eHRfY2xhc3NfaW5pdCk6CisgICAgICAgICh3ZWJraXRfd2ViX2NvbnRleHRfc2V0X3dlYl9wcm9j ZXNzX2NvdW50X2xpbWl0KToKKyAgICAgICAgKHdlYmtpdF93ZWJfY29udGV4dF9nZXRfd2ViX3By b2Nlc3NfY291bnRfbGltaXQpOgorICAgICAgICAod2Via2l0X3dlYl9jb250ZXh0X2dldF9zaW5n bGVfd2ViX3Byb2Nlc3MpOgorICAgICAgICAqIFVJUHJvY2Vzcy9BUEkvZ3RrL1dlYktpdFdlYkNv bnRleHQuaDoKKyAgICAgICAgKiBVSVByb2Nlc3MvQVBJL2d0ay9kb2NzL3dlYmtpdDJndGstNC4w LXNlY3Rpb25zLnR4dDoKKyAgICAgICAgKiBVSVByb2Nlc3MvQVBJL3dwZS9XZWJLaXRXZWJDb250 ZXh0Lmg6CisgICAgICAgICogVUlQcm9jZXNzL0FQSS93cGUvZG9jcy93cGUtMS4wLXNlY3Rpb25z LnR4dDoKKwogMjAxOS0wOC0yMiAgQ2xhdWRpbyBTYWF2ZWRyYSAgPGNzYWF2ZWRyYUBpZ2FsaWEu Y29tPgogCiAgICAgICAgIFtTT1VQXSBOZXR3b3JrUHJvY2Vzc1NvdXAgZG9lcyBub3QgaW5pdGlh bGl6ZSBDYWNoZU9wdGlvbnMgY29ycmVjdGx5CmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViS2l0L1VJ UHJvY2Vzcy9BUEkvZ2xpYi9XZWJLaXRXZWJDb250ZXh0LmNwcCBiL1NvdXJjZS9XZWJLaXQvVUlQ cm9jZXNzL0FQSS9nbGliL1dlYktpdFdlYkNvbnRleHQuY3BwCmluZGV4IDhjNjg5ODI5NTM5ZjQy MjM4YjMwN2Y1NTU2MDhhNWM1MDAyZGNmNDMuLjUwMWZhZjAzYTAxYjdlZmNiNTM3ZjkzOWE5ODgy NGRlNzRiNjI5ZTcgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XZWJLaXQvVUlQcm9jZXNzL0FQSS9nbGli L1dlYktpdFdlYkNvbnRleHQuY3BwCisrKyBiL1NvdXJjZS9XZWJLaXQvVUlQcm9jZXNzL0FQSS9n bGliL1dlYktpdFdlYkNvbnRleHQuY3BwCkBAIC0xMTEsNyArMTExLDggQEAgZW51bSB7CiAjaWYg UExBVEZPUk0oR1RLKQogICAgIFBST1BfTE9DQUxfU1RPUkFHRV9ESVJFQ1RPUlksCiAjZW5kaWYK LSAgICBQUk9QX1dFQlNJVEVfREFUQV9NQU5BR0VSCisgICAgUFJPUF9XRUJTSVRFX0RBVEFfTUFO QUdFUiwKKyAgICBQUk9QX1NJTkdMRV9XRUJfUFJPQ0VTUywKIH07CiAKIGVudW0gewpAQCAtMTc2 LDcgKzE3Nyw3IEBAIHN0cnVjdCBfV2ViS2l0V2ViQ29udGV4dFByaXZhdGUgewogICAgIENTdHJp bmcgZmF2aWNvbkRhdGFiYXNlRGlyZWN0b3J5OwogICAgIFdlYktpdFRMU0Vycm9yc1BvbGljeSB0 bHNFcnJvcnNQb2xpY3k7CiAgICAgV2ViS2l0UHJvY2Vzc01vZGVsIHByb2Nlc3NNb2RlbDsKLSAg ICB1bnNpZ25lZCBwcm9jZXNzQ291bnRMaW1pdDsKKyAgICBib29sIHVzZXNTaW5nbGVXZWJQcm9j ZXNzOwogCiAgICAgSGFzaE1hcDx1aW50NjRfdCwgV2ViS2l0V2ViVmlldyo+IHdlYlZpZXdzOwog ICAgIHVuc2lnbmVkIGVwaGVtZXJhbFBhZ2VDb3VudDsKQEAgLTI4Nyw2ICsyODgsOSBAQCBzdGF0 aWMgdm9pZCB3ZWJraXRXZWJDb250ZXh0R2V0UHJvcGVydHkoR09iamVjdCogb2JqZWN0LCBndWlu dCBwcm9wSUQsIEdWYWx1ZSogdgogICAgIGNhc2UgUFJPUF9XRUJTSVRFX0RBVEFfTUFOQUdFUjoK ICAgICAgICAgZ192YWx1ZV9zZXRfb2JqZWN0KHZhbHVlLCB3ZWJraXRfd2ViX2NvbnRleHRfZ2V0 X3dlYnNpdGVfZGF0YV9tYW5hZ2VyKGNvbnRleHQpKTsKICAgICAgICAgYnJlYWs7CisgICAgY2Fz ZSBQUk9QX1NJTkdMRV9XRUJfUFJPQ0VTUzoKKyAgICAgICAgZ192YWx1ZV9zZXRfYm9vbGVhbih2 YWx1ZSwgY29udGV4dC0+cHJpdi0+dXNlc1NpbmdsZVdlYlByb2Nlc3MpOworICAgICAgICBicmVh azsKICAgICBkZWZhdWx0OgogICAgICAgICBHX09CSkVDVF9XQVJOX0lOVkFMSURfUFJPUEVSVFlf SUQob2JqZWN0LCBwcm9wSUQsIHBhcmFtU3BlYyk7CiAgICAgfQpAQCAtMzA3LDYgKzMxMSw5IEBA IHN0YXRpYyB2b2lkIHdlYmtpdFdlYkNvbnRleHRTZXRQcm9wZXJ0eShHT2JqZWN0KiBvYmplY3Qs IGd1aW50IHByb3BJRCwgY29uc3QgR1ZhCiAgICAgICAgIGNvbnRleHQtPnByaXYtPndlYnNpdGVE YXRhTWFuYWdlciA9IG1hbmFnZXIgPyBXRUJLSVRfV0VCU0lURV9EQVRBX01BTkFHRVIobWFuYWdl cikgOiBudWxscHRyOwogICAgICAgICBicmVhazsKICAgICB9CisgICAgY2FzZSBQUk9QX1NJTkdM RV9XRUJfUFJPQ0VTUzoKKyAgICAgICAgY29udGV4dC0+cHJpdi0+dXNlc1NpbmdsZVdlYlByb2Nl c3MgPSBnX3ZhbHVlX2dldF9ib29sZWFuKHZhbHVlKTsKKyAgICAgICAgYnJlYWs7CiAgICAgZGVm YXVsdDoKICAgICAgICAgR19PQkpFQ1RfV0FSTl9JTlZBTElEX1BST1BFUlRZX0lEKG9iamVjdCwg cHJvcElELCBwYXJhbVNwZWMpOwogICAgIH0KQEAgLTM0Nyw2ICszNTQsNyBAQCBBTExPV19ERVBS RUNBVEVEX0RFQ0xBUkFUSU9OU19FTkQKICAgICB9IGVsc2UgaWYgKCFwcml2LT5sb2NhbFN0b3Jh Z2VEaXJlY3RvcnkuaXNOdWxsKCkpCiAgICAgICAgIGNvbmZpZ3VyYXRpb24uc2V0TG9jYWxTdG9y YWdlRGlyZWN0b3J5KEZpbGVTeXN0ZW06OnN0cmluZ0Zyb21GaWxlU3lzdGVtUmVwcmVzZW50YXRp b24ocHJpdi0+bG9jYWxTdG9yYWdlRGlyZWN0b3J5LmRhdGEoKSkpOwogCisgICAgY29uZmlndXJh dGlvbi5zZXRVc2VzU2luZ2xlV2ViUHJvY2Vzcyhwcml2LT51c2VzU2luZ2xlV2ViUHJvY2Vzcyk7 CiAgICAgcHJpdi0+cHJvY2Vzc1Bvb2wgPSBXZWJQcm9jZXNzUG9vbDo6Y3JlYXRlKGNvbmZpZ3Vy YXRpb24pOwogCiAgICAgaWYgKCFwcml2LT53ZWJzaXRlRGF0YU1hbmFnZXIpCkBAIC00NDIsNiAr NDUwLDI3IEBAIHN0YXRpYyB2b2lkIHdlYmtpdF93ZWJfY29udGV4dF9jbGFzc19pbml0KFdlYktp dFdlYkNvbnRleHRDbGFzcyogd2ViQ29udGV4dENsYXNzCiAgICAgICAgICAgICBXRUJLSVRfVFlQ RV9XRUJTSVRFX0RBVEFfTUFOQUdFUiwKICAgICAgICAgICAgIHN0YXRpY19jYXN0PEdQYXJhbUZs YWdzPihXRUJLSVRfUEFSQU1fUkVBRFdSSVRFIHwgR19QQVJBTV9DT05TVFJVQ1RfT05MWSkpKTsK IAorICAgIC8qKgorICAgICAqIFdlYktpdFdlYkNvbnRleHQ6c2luZ2xlLXdlYi1wcm9jZXNzOgor ICAgICAqCisgICAgICogV2hldGhlciB0aGlzIGNvbnRleHQgaXMgbGltaXRlZCB0byBhIHNpbmds ZSB3ZWIgcHJvY2VzcyBmb3IgYWxsCisgICAgICogaXRzICNXZWJLaXRXZWJWaWV3J3MuIFRoZSBk ZWZhdWx0IGFuZCBwcmVmZXJyZWQgc2V0dGluZyBmb3IKKyAgICAgKiBicm93c2VycyBkaXNwbGF5 aW5nIHVudHJ1c3RlZCBjb250ZW50IGlzICVGQUxTRSwgaG93ZXZlciAlVFJVRQorICAgICAqIGNh biBiZSB1c2VmdWwgZm9yIGRlYnVnZ2luZyBhbmQvb3IgYXBwbGljYXRpb25zIGRpc3BsYXlpbmcg c2FmZQorICAgICAqIGNvbnRlbnQuCisgICAgICoKKyAgICAgKiBTaW5jZTogMi4yNgorICAgICAq LworICAgIGdfb2JqZWN0X2NsYXNzX2luc3RhbGxfcHJvcGVydHkoCisgICAgICAgIGdPYmplY3RD bGFzcywKKyAgICAgICAgUFJPUF9TSU5HTEVfV0VCX1BST0NFU1MsCisgICAgICAgIGdfcGFyYW1f c3BlY19ib29sZWFuKAorICAgICAgICAgICAgInNpbmdsZS13ZWItcHJvY2VzcyIsCisgICAgICAg ICAgICBfKCJTaW5nbGUgV2ViIFByb2Nlc3MiKSwKKyAgICAgICAgICAgIF8oIldoZXRoZXIgdGhp cyBjb250ZXh0IHVzZXMgYSBzaW5nbGUgd2ViIHByb2Nlc3MgZm9yIGFsbCBpdHMgd2ViIHZpZXdz IiksCisgICAgICAgICAgICBGQUxTRSwKKyAgICAgICAgICAgIHN0YXRpY19jYXN0PEdQYXJhbUZs YWdzPihXRUJLSVRfUEFSQU1fUkVBRFdSSVRFIHwgR19QQVJBTV9DT05TVFJVQ1RfT05MWSkpKTsK KwogICAgIC8qKgogICAgICAqIFdlYktpdFdlYkNvbnRleHQ6OmRvd25sb2FkLXN0YXJ0ZWQ6CiAg ICAgICogQGNvbnRleHQ6IHRoZSAjV2ViS2l0V2ViQ29udGV4dApAQCAtMTU5MSwxMSArMTYyMCw2 IEBAIFdlYktpdFByb2Nlc3NNb2RlbCB3ZWJraXRfd2ViX2NvbnRleHRfZ2V0X3Byb2Nlc3NfbW9k ZWwoV2ViS2l0V2ViQ29udGV4dCogY29udGV4CiB2b2lkIHdlYmtpdF93ZWJfY29udGV4dF9zZXRf d2ViX3Byb2Nlc3NfY291bnRfbGltaXQoV2ViS2l0V2ViQ29udGV4dCogY29udGV4dCwgZ3VpbnQg bGltaXQpCiB7CiAgICAgZ19yZXR1cm5faWZfZmFpbChXRUJLSVRfSVNfV0VCX0NPTlRFWFQoY29u dGV4dCkpOwotCi0gICAgaWYgKGNvbnRleHQtPnByaXYtPnByb2Nlc3NDb3VudExpbWl0ID09IGxp bWl0KQotICAgICAgICByZXR1cm47Ci0KLSAgICBjb250ZXh0LT5wcml2LT5wcm9jZXNzQ291bnRM aW1pdCA9IGxpbWl0OwogfQogCiAvKioKQEAgLTE2MTIsNyArMTYzNiwyNSBAQCBndWludCB3ZWJr aXRfd2ViX2NvbnRleHRfZ2V0X3dlYl9wcm9jZXNzX2NvdW50X2xpbWl0KFdlYktpdFdlYkNvbnRl eHQqIGNvbnRleHQpCiB7CiAgICAgZ19yZXR1cm5fdmFsX2lmX2ZhaWwoV0VCS0lUX0lTX1dFQl9D T05URVhUKGNvbnRleHQpLCAwKTsKIAotICAgIHJldHVybiBjb250ZXh0LT5wcml2LT5wcm9jZXNz Q291bnRMaW1pdDsKKyAgICByZXR1cm4gMDsKK30KKworLyoqCisgKiB3ZWJraXRfd2ViX2NvbnRl eHRfZ2V0X3NpbmdsZV93ZWJfcHJvY2VzczoKKyAqIEBjb250ZXh0OiB0aGUgI1dlYktpdFdlYkNv bnRleHQKKyAqCisgKiBXaGV0aGVyIEBjb250ZXh0IGlzIGxpbWl0ZWQgdG8gYSBzaW5nbGUgd2Vi IHByb2Nlc3MgZm9yIGFsbCBvZiBpdHMgI1dlYktpdFdlYlZpZXcncy4KKyAqIFNlZSAjV2ViS2l0 V2ViQ29udGV4dDo6c2luZ2xlLXdlYi1wcm9jZXNzIGZvciBkZXRhaWxzLgorICoKKyAqIFJldHVy bnM6ICNUUlVFIGlmIEBjb250ZXh0IGlzIGxpbWl0ZWQgdG8gYSBzaW5nbGUgd2ViIHByb2Nlc3Ms ICNGQUxTRSBvdGhlcndpc2UuCisgKgorICogU2luY2U6IDIuMjYKKyAqKi8KK2dib29sZWFuIHdl YmtpdF93ZWJfY29udGV4dF9nZXRfc2luZ2xlX3dlYl9wcm9jZXNzKFdlYktpdFdlYkNvbnRleHQq IGNvbnRleHQpCit7CisgICAgZ19yZXR1cm5fdmFsX2lmX2ZhaWwoV0VCS0lUX0lTX1dFQl9DT05U RVhUKGNvbnRleHQpLCBGQUxTRSk7CisKKyAgICByZXR1cm4gY29udGV4dC0+cHJpdi0+dXNlc1Np bmdsZVdlYlByb2Nlc3M7CiB9CiAKIHN0YXRpYyB2b2lkIGFkZE9yaWdpblRvTWFwKFdlYktpdFNl Y3VyaXR5T3JpZ2luKiBvcmlnaW4sIEhhc2hNYXA8U3RyaW5nLCBib29sPiogbWFwLCBib29sIGFs bG93ZWQpCmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViS2l0L1VJUHJvY2Vzcy9BUEkvZ3RrL1dlYktp dFdlYkNvbnRleHQuaCBiL1NvdXJjZS9XZWJLaXQvVUlQcm9jZXNzL0FQSS9ndGsvV2ViS2l0V2Vi Q29udGV4dC5oCmluZGV4IDgyYThkODI4ZGZhMTcxMjQzMmFkMzMyZGI4YjA2YTNmNTMyNzdlOTMu LjJkZmEzNzE1ZWM0NmFkZTllZTRhN2E3MjY1YzJjZjA0ZWFjZjYxY2YgMTAwNjQ0Ci0tLSBhL1Nv dXJjZS9XZWJLaXQvVUlQcm9jZXNzL0FQSS9ndGsvV2ViS2l0V2ViQ29udGV4dC5oCisrKyBiL1Nv dXJjZS9XZWJLaXQvVUlQcm9jZXNzL0FQSS9ndGsvV2ViS2l0V2ViQ29udGV4dC5oCkBAIC0yMDAs NiArMjAwLDkgQEAgd2Via2l0X3dlYl9jb250ZXh0X3NldF93ZWJfcHJvY2Vzc19jb3VudF9saW1p dCAgICAgIChXZWJLaXRXZWJDb250ZXh0CiBXRUJLSVRfQVBJIGd1aW50CiB3ZWJraXRfd2ViX2Nv bnRleHRfZ2V0X3dlYl9wcm9jZXNzX2NvdW50X2xpbWl0ICAgICAgKFdlYktpdFdlYkNvbnRleHQg ICAgICAgICAgICAgICpjb250ZXh0KTsKIAorV0VCS0lUX0FQSSBnYm9vbGVhbgord2Via2l0X3dl Yl9jb250ZXh0X2dldF9zaW5nbGVfd2ViX3Byb2Nlc3MgICAgICAgICAgIChXZWJLaXRXZWJDb250 ZXh0ICAgICAgICAgICAgICAqY29udGV4dCk7CisKIFdFQktJVF9BUEkgdm9pZAogd2Via2l0X3dl Yl9jb250ZXh0X2NsZWFyX2NhY2hlICAgICAgICAgICAgICAgICAgICAgIChXZWJLaXRXZWJDb250 ZXh0ICAgICAgICAgICAgICAqY29udGV4dCk7CiAKZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJLaXQv VUlQcm9jZXNzL0FQSS9ndGsvZG9jcy93ZWJraXQyZ3RrLTQuMC1zZWN0aW9ucy50eHQgYi9Tb3Vy Y2UvV2ViS2l0L1VJUHJvY2Vzcy9BUEkvZ3RrL2RvY3Mvd2Via2l0Mmd0ay00LjAtc2VjdGlvbnMu dHh0CmluZGV4IGRmNTg1YTJlNmRlZWEzODk0YWNmOTQzMDkzY2UzYTE3YjA3MzUyNzIuLjNkOTU0 ZTk5YzZkMzBiMDI4NjIzYjgxNmIzOTlhMDFhNjIwMTIzNTIgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9X ZWJLaXQvVUlQcm9jZXNzL0FQSS9ndGsvZG9jcy93ZWJraXQyZ3RrLTQuMC1zZWN0aW9ucy50eHQK KysrIGIvU291cmNlL1dlYktpdC9VSVByb2Nlc3MvQVBJL2d0ay9kb2NzL3dlYmtpdDJndGstNC4w LXNlY3Rpb25zLnR4dApAQCAtNDAsNiArNDAsNyBAQCB3ZWJraXRfd2ViX2NvbnRleHRfZ2V0X2Nh Y2hlX21vZGVsCiB3ZWJraXRfd2ViX2NvbnRleHRfc2V0X2NhY2hlX21vZGVsCiB3ZWJraXRfd2Vi X2NvbnRleHRfZ2V0X3dlYl9wcm9jZXNzX2NvdW50X2xpbWl0CiB3ZWJraXRfd2ViX2NvbnRleHRf c2V0X3dlYl9wcm9jZXNzX2NvdW50X2xpbWl0Cit3ZWJraXRfd2ViX2NvbnRleHRfZ2V0X3Npbmds ZV93ZWJfcHJvY2Vzcwogd2Via2l0X3dlYl9jb250ZXh0X2NsZWFyX2NhY2hlCiB3ZWJraXRfd2Vi X2NvbnRleHRfc2V0X25ldHdvcmtfcHJveHlfc2V0dGluZ3MKIHdlYmtpdF93ZWJfY29udGV4dF9k b3dubG9hZF91cmkKZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJLaXQvVUlQcm9jZXNzL0FQSS93cGUv V2ViS2l0V2ViQ29udGV4dC5oIGIvU291cmNlL1dlYktpdC9VSVByb2Nlc3MvQVBJL3dwZS9XZWJL aXRXZWJDb250ZXh0LmgKaW5kZXggYTMyNjgwZmE4MzA1MDBiZmI1MzAzMjY5MTcxMDQzMmY4Mjg3 NGU3ZC4uZDM5OTQ2ZmQ5N2Y0ZDhjN2RmOGRkYTExNDQ4NmEwMmY3ZDAxMmVjYSAxMDA2NDQKLS0t IGEvU291cmNlL1dlYktpdC9VSVByb2Nlc3MvQVBJL3dwZS9XZWJLaXRXZWJDb250ZXh0LmgKKysr IGIvU291cmNlL1dlYktpdC9VSVByb2Nlc3MvQVBJL3dwZS9XZWJLaXRXZWJDb250ZXh0LmgKQEAg LTIwMCw2ICsyMDAsOSBAQCB3ZWJraXRfd2ViX2NvbnRleHRfc2V0X3dlYl9wcm9jZXNzX2NvdW50 X2xpbWl0ICAgICAgKFdlYktpdFdlYkNvbnRleHQKIFdFQktJVF9BUEkgZ3VpbnQKIHdlYmtpdF93 ZWJfY29udGV4dF9nZXRfd2ViX3Byb2Nlc3NfY291bnRfbGltaXQgICAgICAoV2ViS2l0V2ViQ29u dGV4dCAgICAgICAgICAgICAgKmNvbnRleHQpOwogCitXRUJLSVRfQVBJIGdib29sZWFuCit3ZWJr aXRfd2ViX2NvbnRleHRfZ2V0X3NpbmdsZV93ZWJfcHJvY2VzcyAgICAgICAgICAgKFdlYktpdFdl YkNvbnRleHQgICAgICAgICAgICAgICpjb250ZXh0KTsKKwogV0VCS0lUX0FQSSB2b2lkCiB3ZWJr aXRfd2ViX2NvbnRleHRfY2xlYXJfY2FjaGUgICAgICAgICAgICAgICAgICAgICAgKFdlYktpdFdl YkNvbnRleHQgICAgICAgICAgICAgICpjb250ZXh0KTsKIApkaWZmIC0tZ2l0IGEvU291cmNlL1dl YktpdC9VSVByb2Nlc3MvQVBJL3dwZS9kb2NzL3dwZS0xLjAtc2VjdGlvbnMudHh0IGIvU291cmNl L1dlYktpdC9VSVByb2Nlc3MvQVBJL3dwZS9kb2NzL3dwZS0xLjAtc2VjdGlvbnMudHh0CmluZGV4 IDY0ZWEzMGU5M2NkNGU5ZGQyNGMzNjNmNzk3M2MwZWYwY2RjMGNhZWEuLjZkYjY0OWY3OWY0NWMw OWUwN2FkZDk3MTg2MGFjOTNjZTU0OWI1NmUgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XZWJLaXQvVUlQ cm9jZXNzL0FQSS93cGUvZG9jcy93cGUtMS4wLXNlY3Rpb25zLnR4dAorKysgYi9Tb3VyY2UvV2Vi S2l0L1VJUHJvY2Vzcy9BUEkvd3BlL2RvY3Mvd3BlLTEuMC1zZWN0aW9ucy50eHQKQEAgLTE4LDYg KzE4LDcgQEAgd2Via2l0X3dlYl9jb250ZXh0X2dldF9jYWNoZV9tb2RlbAogd2Via2l0X3dlYl9j b250ZXh0X3NldF9jYWNoZV9tb2RlbAogd2Via2l0X3dlYl9jb250ZXh0X2dldF93ZWJfcHJvY2Vz c19jb3VudF9saW1pdAogd2Via2l0X3dlYl9jb250ZXh0X3NldF93ZWJfcHJvY2Vzc19jb3VudF9s aW1pdAord2Via2l0X3dlYl9jb250ZXh0X2dldF9zaW5nbGVfd2ViX3Byb2Nlc3MKIHdlYmtpdF93 ZWJfY29udGV4dF9jbGVhcl9jYWNoZQogd2Via2l0X3dlYl9jb250ZXh0X3NldF9uZXR3b3JrX3By b3h5X3NldHRpbmdzCiB3ZWJraXRfd2ViX2NvbnRleHRfZG93bmxvYWRfdXJpCg== 377687 2019-08-30 01:39:34 -0700 2019-08-30 01:39:34 -0700 test-wk2.c - reproducer client side test-wk2.c text/plain 6830 mcrha LyogZ2NjIGBwa2ctY29uZmlnIC0tY2ZsYWdzIC0tbGlicyBndGsrLTMuMCB3ZWJraXQyZ3RrLTQu MGAgdGVzdC13azIuYyAtZyAtTzAgLW8gdGVzdC13azIgJiYgLi90ZXN0LXdrMiAqLwoKI2luY2x1 ZGUgPHN0ZGlvLmg+CiNpbmNsdWRlIDxzdGRsaWIuaD4KI2luY2x1ZGUgPHN0cmluZy5oPgojaW5j bHVkZSA8Z3RrL2d0ay5oPgojaW5jbHVkZSA8d2Via2l0Mi93ZWJraXQyLmg+CgpzdGF0aWMgR1Rp bWVyICp0aW1lciA9IE5VTEw7CgpzdGF0aWMgdm9pZApyZWFkeV90b19zaG93X2NiIChXZWJLaXRX ZWJWaWV3ICp3ZWJfdmlldywKCQkgIGdwb2ludGVyIHVzZXJfZGF0YSkKewoJcHJpbnRmICgiICAg ICAlczogYWZ0ZXIgJWdzXG4iLCBfX0ZVTkNUSU9OX18sIGdfdGltZXJfZWxhcHNlZCAodGltZXIs IE5VTEwpKTsKfQoKc3RhdGljIHZvaWQKbG9hZF9jaGFuZ2VkX2NiIChXZWJLaXRXZWJWaWV3ICp3 ZWJfdmlldywKCQkgV2ViS2l0TG9hZEV2ZW50IGxvYWRfZXZlbnQsCgkJIGdwb2ludGVyIHVzZXJf ZGF0YSkKewoJcHJpbnRmICgiICAgICAlczogJXMgYWZ0ZXIgJWdzIG9uIHZpZXc6JXAgV2ViUGFn ZSAlIiBHX0dVSU5UNjRfRk9STUFUICJcbiIsIF9fRlVOQ1RJT05fXywKCQlsb2FkX2V2ZW50ID09 IFdFQktJVF9MT0FEX1NUQVJURUQgPyAiV0VCS0lUX0xPQURfU1RBUlRFRCIgOgoJCWxvYWRfZXZl bnQgPT0gV0VCS0lUX0xPQURfUkVESVJFQ1RFRCA/ICJXRUJLSVRfTE9BRF9SRURJUkVDVEVEIiA6 CgkJbG9hZF9ldmVudCA9PSBXRUJLSVRfTE9BRF9DT01NSVRURUQgPyAiV0VCS0lUX0xPQURfQ09N TUlUVEVEIiA6CgkJbG9hZF9ldmVudCA9PSBXRUJLSVRfTE9BRF9GSU5JU0hFRCA/ICJXRUJLSVRf TE9BRF9GSU5JU0hFRCIgOiAiPz8/IiwKCQlnX3RpbWVyX2VsYXBzZWQgKHRpbWVyLCBOVUxMKSwK CQl3ZWJfdmlldywgd2Via2l0X3dlYl92aWV3X2dldF9wYWdlX2lkICh3ZWJfdmlldykpOwp9Cgpz dGF0aWMgY29uc3QgZ2NoYXIgKmh0bWxfY29udGVudCA9CgkiPGh0bWw+PGJvZHk+VGV4dCBpbiBi b2R5PGJyPiIKCSJsaW5lMTxicj4iCgkibGluZTI8YnI+IgoJImxpbmUzPGJyPiIKCSJsaW5lNDxi cj4iCgkibGluZTU8YnI+IgoJImxpbmU2PGJyPiIKCSJsaW5lNzxicj4iCgkibGluZTg8YnI+IgoJ ImxpbmU5PGJyPiIKCSJsaW5lMTA8YnI+IgoJImxpbmUxMTxicj4iCgkibGluZTEyPGJyPiIKCSJs aW5lMTM8YnI+IgoJImxpbmUxNDxicj4iCgkibGluZTE1PGJyPiIKCSJsaW5lMTY8YnI+IgoJImxp bmUxNzxicj4iCgkibGluZTE4PGJyPiIKCSJsaW5lMTk8YnI+IgoJImxpbmUyMDxicj4iCgkibGlu ZTIxPGJyPiIKCSJsaW5lMjI8YnI+IgoJImxpbmUyMzxicj4iCgkibGluZTI0PGJyPiIKCSJsaW5l MjU8YnI+IgoJImxpbmUyNjxicj4iCgkibGluZTI3PGJyPiIKCSJsaW5lMjg8YnI+IgoJImxpbmUy OTxicj4iCgkibGluZTMwPGJyPiIKCSI8L2JvZHk+PC9odG1sPiI7CgpzdGF0aWMgZ2Jvb2xlYW4K ZmlsbF93ZWJfdmlld19jYiAoZ3BvaW50ZXIgd2ViX3ZpZXcpCnsKCXdlYmtpdF93ZWJfdmlld19s b2FkX2h0bWwgKHdlYl92aWV3LCBodG1sX2NvbnRlbnQsICJodHRwOi8vbm8ud2hlcmUvIik7CgoJ Z19vYmplY3RfdW5yZWYgKHdlYl92aWV3KTsKCglyZXR1cm4gRkFMU0U7Cn0KCnN0YXRpYyB2b2lk CnJlbG9hZF9jYiAoR3RrV2lkZ2V0ICpidXR0b24sCgkgICBXZWJLaXRXZWJWaWV3ICp3ZWJfdmll dykKewoJLypXZWJLaXRQcmludE9wZXJhdGlvbiAqcHJuOwoKCXBybiA9IHdlYmtpdF9wcmludF9v cGVyYXRpb25fbmV3ICh3ZWJfdmlldyk7Cgl3ZWJraXRfcHJpbnRfb3BlcmF0aW9uX3J1bl9kaWFs b2cgKHBybiwgTlVMTCk7CglnX29iamVjdF91bnJlZiAocHJuKTsqLwoJLy93ZWJraXRfd2ViX2lu c3BlY3Rvcl9zaG93ICh3ZWJraXRfd2ViX3ZpZXdfZ2V0X2luc3BlY3RvciAod2ViX3ZpZXcpKTsK CglwcmludGYgKCIlczogJXA6IHBhZ2UtaWQ6JSIgR19HVUlOVDY0X0ZPUk1BVCAiXG4iLCBfX0ZV TkNUSU9OX18sIHdlYl92aWV3LCB3ZWJraXRfd2ViX3ZpZXdfZ2V0X3BhZ2VfaWQgKHdlYl92aWV3 KSk7Cgl3ZWJraXRfd2ViX3ZpZXdfbG9hZF9odG1sICh3ZWJfdmlldywgIjxodG1sPjxib2R5Pkxv YWRpbmcuLi48L2JvZHk+PC9odG1sPiIsICJzb21lLW90aGVyOi8vb3RoZXIubm8ud2hlcmUvIik7 CgoJZ190aW1lb3V0X2FkZF9zZWNvbmRzICgyLCBmaWxsX3dlYl92aWV3X2NiLCBnX29iamVjdF9y ZWYgKHdlYl92aWV3KSk7Cn0KCmdib29sZWFuCmRlY2lkZV9wb2xpY3lfY2IgKFdlYktpdFdlYlZp ZXcgKndlYl92aWV3LAoJCSAgV2ViS2l0UG9saWN5RGVjaXNpb24gKmRlY2lzaW9uLAoJCSAgV2Vi S2l0UG9saWN5RGVjaXNpb25UeXBlIGRlY2lzaW9uX3R5cGUsCgkJICBncG9pbnRlciB1c2VyX2Rh dGEpCnsKCXByaW50ZiAoIiAgICAgICVzOiBkZWNpc2lvbl90eXBlOiVzIHZpZXc6JXAgcGFnZS1p ZDolIiBHX0dVSU5UNjRfRk9STUFUICJcbiIsIF9fRlVOQ1RJT05fXywKCQlkZWNpc2lvbl90eXBl ID09IFdFQktJVF9QT0xJQ1lfREVDSVNJT05fVFlQRV9OQVZJR0FUSU9OX0FDVElPTiA/ICJXRUJL SVRfUE9MSUNZX0RFQ0lTSU9OX1RZUEVfTkFWSUdBVElPTl9BQ1RJT04iIDoKCQlkZWNpc2lvbl90 eXBlID09IFdFQktJVF9QT0xJQ1lfREVDSVNJT05fVFlQRV9ORVdfV0lORE9XX0FDVElPTiA/ICJX RUJLSVRfUE9MSUNZX0RFQ0lTSU9OX1RZUEVfTkVXX1dJTkRPV19BQ1RJT04iIDoKCQlkZWNpc2lv bl90eXBlID09IFdFQktJVF9QT0xJQ1lfREVDSVNJT05fVFlQRV9SRVNQT05TRSA/ICJXRUJLSVRf UE9MSUNZX0RFQ0lTSU9OX1RZUEVfUkVTUE9OU0UiIDogIj8/IiwKCQl3ZWJfdmlldywgd2Via2l0 X3dlYl92aWV3X2dldF9wYWdlX2lkICh3ZWJfdmlldykpOwoJaWYgKGRlY2lzaW9uX3R5cGUgPT0g V0VCS0lUX1BPTElDWV9ERUNJU0lPTl9UWVBFX1JFU1BPTlNFKSB7CgkJV2ViS2l0VVJJUmVxdWVz dCAqcmVxID0gd2Via2l0X3Jlc3BvbnNlX3BvbGljeV9kZWNpc2lvbl9nZXRfcmVxdWVzdCAoV0VC S0lUX1JFU1BPTlNFX1BPTElDWV9ERUNJU0lPTiAoZGVjaXNpb24pKTsKCQlwcmludGYgKCIgICAg ICAgICAlczogcmVxOiclcydcbiIsIF9fRlVOQ1RJT05fXywgd2Via2l0X3VyaV9yZXF1ZXN0X2dl dF91cmkgKHJlcSkpOwoJfSBlbHNlIGlmIChkZWNpc2lvbl90eXBlID09IFdFQktJVF9QT0xJQ1lf REVDSVNJT05fVFlQRV9OQVZJR0FUSU9OX0FDVElPTikgewoJCVdlYktpdE5hdmlnYXRpb25BY3Rp b24gKm5hdiA9IHdlYmtpdF9uYXZpZ2F0aW9uX3BvbGljeV9kZWNpc2lvbl9nZXRfbmF2aWdhdGlv bl9hY3Rpb24gKFdFQktJVF9OQVZJR0FUSU9OX1BPTElDWV9ERUNJU0lPTiAoZGVjaXNpb24pKTsK CQlXZWJLaXRVUklSZXF1ZXN0ICpyZXEgPSB3ZWJraXRfbmF2aWdhdGlvbl9hY3Rpb25fZ2V0X3Jl cXVlc3QgKG5hdik7CgkJcHJpbnRmICgiICAgICAgICAgJXM6IHJlcTonJXMnXG4iLCBfX0ZVTkNU SU9OX18sIHdlYmtpdF91cmlfcmVxdWVzdF9nZXRfdXJpIChyZXEpKTsKCX0gZWxzZSB7CgkJd2Vi a2l0X3BvbGljeV9kZWNpc2lvbl91c2UgKGRlY2lzaW9uKTsKCX0KCglyZXR1cm4gVFJVRTsKfQoK c3RhdGljIGdib29sZWFuCmNsYWltX3dlYl92aWV3X3BhZ2VfaWRfY2IgKGdwb2ludGVyIHVzZXJf ZGF0YSkKewoJV2ViS2l0V2ViVmlldyAqd2ViX3ZpZXcgPSB1c2VyX2RhdGE7CgoJZ19yZXR1cm5f dmFsX2lmX2ZhaWwgKFdFQktJVF9JU19XRUJfVklFVyAod2ViX3ZpZXcpLCBGQUxTRSk7CgoJcHJp bnRmICgiICAgV2ViVmlldzolcCBoYW5kbGVzIFdlYlBhZ2UgSUQgJSIgR19HVUlOVDY0X0ZPUk1B VCAiXG4iLCB3ZWJfdmlldywgd2Via2l0X3dlYl92aWV3X2dldF9wYWdlX2lkICh3ZWJfdmlldykp OwoKCXJldHVybiBUUlVFOwp9CgpzdGF0aWMgdm9pZAppbml0aWFsaXplX3dlYl9leHRlbnNpb25z X2NiIChXZWJLaXRXZWJDb250ZXh0ICp3ZWJfY29udGV4dCwKCQkJICAgICAgZ3BvaW50ZXIgdXNl cl9kYXRhKQp7Cgl3ZWJraXRfd2ViX2NvbnRleHRfc2V0X3dlYl9leHRlbnNpb25zX2RpcmVjdG9y eSAod2ViX2NvbnRleHQsICIvdG1wL3Rlc3Qtd2syLWV4dGVuc2lvbiIpOwp9CgppbnQgbWFpbiAo aW50IGFyZ2MsIGNoYXIgKmFyZ3ZbXSkKewoJR3RrV2lkZ2V0ICpkaWFsb2csICpjb250YWluZXIs ICp3aywgKmJ0bjsKCVdlYktpdFNldHRpbmdzICpzZXR0aW5nczsKCVdlYktpdFdlYkNvbnRleHQg KmNvbnRleHQ7Cgljb25zdCBnY2hhciAqc3BlbGxfbGFuZ3NbMl0gPSB7ICJmaSIsIE5VTEwgfTsK CglndGtfaW5pdCAoJmFyZ2MsICZhcmd2KTsKCgkvL2dfc2V0ZW52ICgiV0VCS0lUX0RJU0FCTEVf Q09NUE9TSVRJTkdfTU9ERSIsICIxIiwgRkFMU0UpOwoKCWdfc2lnbmFsX2Nvbm5lY3QgKHdlYmtp dF93ZWJfY29udGV4dF9nZXRfZGVmYXVsdCAoKSwgImluaXRpYWxpemUtd2ViLWV4dGVuc2lvbnMi LAoJCUdfQ0FMTEJBQ0sgKGluaXRpYWxpemVfd2ViX2V4dGVuc2lvbnNfY2IpLCBOVUxMKTsKCglk aWFsb2cgPSBndGtfZGlhbG9nX25ld193aXRoX2J1dHRvbnMgKCJ0ZXN0LXdrMiIsIE5VTEwsIDAs ICJfQ2FuY2VsIiwgR1RLX1JFU1BPTlNFX0NBTkNFTCwgTlVMTCk7CglndGtfd2luZG93X3NldF9k ZWZhdWx0X3NpemUgKEdUS19XSU5ET1cgKGRpYWxvZyksIDMyMCwgNDAwKTsKCgljb250YWluZXIg PSBndGtfZGlhbG9nX2dldF9jb250ZW50X2FyZWEgKEdUS19ESUFMT0cgKGRpYWxvZykpOwoKCWJ0 biA9IGd0a19idXR0b25fbmV3X3dpdGhfbW5lbW9uaWMgKCJfUmVsb2FkIik7CglndGtfY29udGFp bmVyX2FkZCAoR1RLX0NPTlRBSU5FUiAoY29udGFpbmVyKSwgYnRuKTsKCglzZXR0aW5ncyA9IHdl YmtpdF9zZXR0aW5nc19uZXdfd2l0aF9zZXR0aW5ncyAoCgkJImF1dG8tbG9hZC1pbWFnZXMiLCBG QUxTRSwKCQkiZGVmYXVsdC1jaGFyc2V0IiwgInV0Zi04IiwKCQkiZW5hYmxlLWh0bWw1LWRhdGFi YXNlIiwgRkFMU0UsCgkJImVuYWJsZS1kbnMtcHJlZmV0Y2hpbmciLCBGQUxTRSwKCQkiZW5hYmxl LWh0bWw1LWxvY2FsLXN0b3JhZ2UiLCBGQUxTRSwKCQkiZW5hYmxlLWphdmEiLCBGQUxTRSwKCQki ZW5hYmxlLWphdmFzY3JpcHQiLCBUUlVFLAoJCSJlbmFibGUtb2ZmbGluZS13ZWItYXBwbGljYXRp b24tY2FjaGUiLCBGQUxTRSwKCQkiZW5hYmxlLXBhZ2UtY2FjaGUiLCBGQUxTRSwKCQkiZW5hYmxl LXBsdWdpbnMiLCBGQUxTRSwKCQkiZW5hYmxlLXNtb290aC1zY3JvbGxpbmciLCBGQUxTRSwKCQki bWVkaWEtcGxheWJhY2stYWxsb3dzLWlubGluZSIsIEZBTFNFLAoJCU5VTEwpOwoJd2Via2l0X3Nl dHRpbmdzX3NldF9lbmFibGVfZGV2ZWxvcGVyX2V4dHJhcyAoc2V0dGluZ3MsIFRSVUUpOwoJd2Vi a2l0X3NldHRpbmdzX3NldF9lbmFibGVfZnJhbWVfZmxhdHRlbmluZyAoc2V0dGluZ3MsIFRSVUUp OwoKCXdrID0gd2Via2l0X3dlYl92aWV3X25ld193aXRoX3NldHRpbmdzIChzZXR0aW5ncyk7CgoJ d2Via2l0X3dlYl92aWV3X3NldF9lZGl0YWJsZSAoV0VCS0lUX1dFQl9WSUVXICh3ayksIFRSVUUp OwoKCWdfc2lnbmFsX2Nvbm5lY3QgKHdrLCAiZGVjaWRlLXBvbGljeSIsIEdfQ0FMTEJBQ0sgKGRl Y2lkZV9wb2xpY3lfY2IpLCBOVUxMKTsKCglnX3NpZ25hbF9jb25uZWN0IChidG4sICJjbGlja2Vk IiwgR19DQUxMQkFDSyAocmVsb2FkX2NiKSwgd2spOwoKCWNvbnRleHQgPSB3ZWJraXRfd2ViX3Zp ZXdfZ2V0X2NvbnRleHQgKFdFQktJVF9XRUJfVklFVyAod2spKTsKCXdlYmtpdF93ZWJfY29udGV4 dF9zZXRfc3BlbGxfY2hlY2tpbmdfZW5hYmxlZCAoY29udGV4dCwgVFJVRSk7CgoJaWYgKGFyZ2Mg PT0gMikKCQlzcGVsbF9sYW5nc1swXSA9IGFyZ3ZbMV07CgoJd2Via2l0X3dlYl9jb250ZXh0X3Nl dF9zcGVsbF9jaGVja2luZ19sYW5ndWFnZXMgKGNvbnRleHQsIChjb25zdCBnY2hhciAqIGNvbnN0 ICopIHNwZWxsX2xhbmdzKTsKCglndGtfY29udGFpbmVyX2FkZCAoR1RLX0NPTlRBSU5FUiAoY29u dGFpbmVyKSwgd2spOwoJZ19vYmplY3Rfc2V0IChHX09CSkVDVCAod2spLAoJCSJoZXhwYW5kIiwg VFJVRSwKCQkiaGFsaWduIiwgR1RLX0FMSUdOX0ZJTEwsCgkJInZleHBhbmQiLCBUUlVFLAoJCSJ2 YWxpZ24iLCBHVEtfQUxJR05fRklMTCwKCQkiaGVpZ2h0LXJlcXVlc3QiLCA5MCwKCQkid2lkdGgt cmVxdWVzdCIsIDkwLAoJCU5VTEwpOwoKCXRpbWVyID0gZ190aW1lcl9uZXcgKCk7CglnX3NpZ25h bF9jb25uZWN0ICh3aywgInJlYWR5LXRvLXNob3ciLCBHX0NBTExCQUNLIChyZWFkeV90b19zaG93 X2NiKSwgTlVMTCk7CglnX3NpZ25hbF9jb25uZWN0ICh3aywgImxvYWQtY2hhbmdlZCIsIEdfQ0FM TEJBQ0sgKGxvYWRfY2hhbmdlZF9jYiksIE5VTEwpOwoJcHJpbnRmICgiJXM6ICVwOiBwYWdlLWlk OiUiIEdfR1VJTlQ2NF9GT1JNQVQgIlxuIiwgX19GVU5DVElPTl9fLCB3aywgd2Via2l0X3dlYl92 aWV3X2dldF9wYWdlX2lkIChXRUJLSVRfV0VCX1ZJRVcgKHdrKSkpOwoJd2Via2l0X3dlYl92aWV3 X2xvYWRfaHRtbCAoV0VCS0lUX1dFQl9WSUVXICh3ayksIGh0bWxfY29udGVudCwgImZpbGU6Ly8i KTsKCglnX3RpbWVvdXRfYWRkX3NlY29uZHMgKDMsIGNsYWltX3dlYl92aWV3X3BhZ2VfaWRfY2Is IHdrKTsKCglndGtfd2lkZ2V0X3Nob3dfYWxsIChndGtfZGlhbG9nX2dldF9jb250ZW50X2FyZWEg KEdUS19ESUFMT0cgKGRpYWxvZykpKTsKCS8vZ3RrX3dpZGdldF9oaWRlIChidG4pOwoKCWd0a19k aWFsb2dfcnVuIChHVEtfRElBTE9HIChkaWFsb2cpKTsKCglndGtfd2lkZ2V0X2Rlc3Ryb3kgKGRp YWxvZyk7CglnX3RpbWVyX2Rlc3Ryb3kgKHRpbWVyKTsKCglyZXR1cm4gMDsKfQo= 377688 2019-08-30 01:41:24 -0700 2019-08-30 01:41:24 -0700 test-wk2-extension.c - a WebExtension test-wk2-extension.c text/plain 1235 mcrha LyogbWtkaXIgL3RtcC90ZXN0LXdrMi1leHRlbnNpb24gMj4vZGV2L251bGw7IGdjYyBgcGtnLWNv bmZpZyAtLWNmbGFncyAtLWxpYnMgZ3RrKy0zLjAgd2Via2l0Mmd0ay00LjBgIHRlc3Qtd2syLWV4 dGVuc2lvbi5jIC1zaGFyZWQgLWZQSUMgLW8gL3RtcC90ZXN0LXdrMi1leHRlbnNpb24vdGVzdC13 azItZXh0ZW5zaW9uLnNvICovCgojaW5jbHVkZSA8c3lzL3R5cGVzLmg+CiNpbmNsdWRlIDx1bmlz dGQuaD4KI2luY2x1ZGUgPHN0ZGlvLmg+CiNpbmNsdWRlIDx3ZWJraXQyL3dlYmtpdC13ZWItZXh0 ZW5zaW9uLmg+CgpzdGF0aWMgdm9pZAp3ZWJfcGFnZV9nb25lIChncG9pbnRlciB1c2VyX2RhdGEs CgkgICAgICAgR09iamVjdCAqb2JqKQp7CglwcmludGYgKCIlZCAgICVzOiBleHQ6JXAgcGFnZTol cFxuIiwgZ2V0cGlkICgpLCBfX0ZVTkNUSU9OX18sIHVzZXJfZGF0YSwgb2JqKTsKfQoKc3RhdGlj IHZvaWQKZXh0ZW5zaW9uX3BhZ2VfY3JlYXRlZF9jYiAoV2ViS2l0V2ViRXh0ZW5zaW9uICpleHRl bnNpb24sCgkJCSAgIFdlYktpdFdlYlBhZ2UgKndlYl9wYWdlLAoJCQkgICBncG9pbnRlciB1c2Vy X2RhdGEpCnsKCXByaW50ZiAoIiVkICAgJXM6IGV4dDolcCBwYWdlOiVwIGlkOiUiIEdfR1VJTlQ2 NF9GT1JNQVQgIlxuIiwgZ2V0cGlkICgpLCBfX0ZVTkNUSU9OX18sIGV4dGVuc2lvbiwgd2ViX3Bh Z2UsIHdlYmtpdF93ZWJfcGFnZV9nZXRfaWQgKHdlYl9wYWdlKSk7CglnX29iamVjdF93ZWFrX3Jl ZiAoR19PQkpFQ1QgKHdlYl9wYWdlKSwgd2ViX3BhZ2VfZ29uZSwgZXh0ZW5zaW9uKTsKfQoKR19N T0RVTEVfRVhQT1JUIHZvaWQgd2Via2l0X3dlYl9leHRlbnNpb25faW5pdGlhbGl6ZV93aXRoX3Vz ZXJfZGF0YSAoV2ViS2l0V2ViRXh0ZW5zaW9uICp3a19leHRlbnNpb24sCgkJCQkJCQkJICAgICBH VmFyaWFudCAqdXNlcl9kYXRhKTsKCkdfTU9EVUxFX0VYUE9SVCB2b2lkCndlYmtpdF93ZWJfZXh0 ZW5zaW9uX2luaXRpYWxpemVfd2l0aF91c2VyX2RhdGEgKFdlYktpdFdlYkV4dGVuc2lvbiAqd2tf ZXh0ZW5zaW9uLAoJCQkJCQlHVmFyaWFudCAqdXNlcl9kYXRhKQp7CglwcmludGYgKCIlZCAlczog ZXh0OiVwXG4iLCBnZXRwaWQgKCksIF9fRlVOQ1RJT05fXywgd2tfZXh0ZW5zaW9uKTsKCglnX3Np Z25hbF9jb25uZWN0ICh3a19leHRlbnNpb24sICJwYWdlLWNyZWF0ZWQiLAoJCUdfQ0FMTEJBQ0sg KGV4dGVuc2lvbl9wYWdlX2NyZWF0ZWRfY2IpLCBOVUxMKTsKfQo=