193439 2019-01-15 01:17:04 -0800 [GTK][WPE] Add enable-javascript-markup setting 2026-04-07 01:17:48 -0700 1 1 1 Unclassified WebKit WebKitGTK WebKit Nightly Build Unspecified Unspecified RESOLVED FIXED https://bugs.webkit.org/show_bug.cgi?id=192753 Gtk P2 Normal --- 1 cgarcia webkit-unassigned aperez berto bugs-noreply ews-watchlist ggaren gustavo mcatanzaro ntd87w2jth ramtin.beheshti ramtinbeheshti webkit-bug-importer oldest_to_newest 1494571 0 cgarcia 2019-01-15 01:17:04 -0800 To disable js markup instead of all js execution. 1494572 1 359147 cgarcia 2019-01-15 01:19:27 -0800 Created attachment 359147 Patch 1494573 2 ews-watchlist 2019-01-15 01:22:34 -0800 Thanks for the patch. If this patch contains new public API please make sure it follows the guidelines for new WebKit2 GTK+ API. See http://trac.webkit.org/wiki/WebKitGTK/AddingNewWebKit2API 1494589 3 359147 aperez 2019-01-15 03:37:55 -0800 Comment on attachment 359147 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=359147&action=review Informally reviewing, this would be a r- for my: the description in the API documentation is seriously lacking, and the name of the setting is quite bad (non-descriptive, and difficult to search online for). I don't care what WebKit calls the setting internally, I would rather have a name for it that better indicates what it does *and* that we provide a good description of what the setting does and its intended usage. > Source/WebKit/UIProcess/API/glib/WebKitSettings.cpp:3582 > + * Returns: %TRUE If JavaScript markup is enabled or %FALSE otherwise. What is “JavaScript Markup”? A specification, a WebKit specific concept? Something widely understood among Web developers?... I think the documentation for this setting needs an explanation of what the option does, as it is nearly impossible to find anything about this topic that would seem relevant when implementing an application which makes use of WebKit. After some digging in the repository history I arrived at bug #112999 and bug #113122 and it took me wading through a pile of comments and reading some bits of the code to guess what the setting does. So please let's make the API documentation better by adding something in the lines of: “Enabling this setting will strip <script> tags from loaded HTML content, but other forms of JavaScript execution e.g. using webkit_web_view_run_javascript() are still allowed. This setting is intended for applications which display HTML content but are not full browsers, and which want to avoid the risk of script injection attacks, as is the case of applications like e-mail and news readers.” If possible it should be more concrete that the above explaining what gets restricted and what not, because very often we programmers end up introducing accidental security vulnerabilities due to assumptions we make caused by incomplete documentation of third party code used. 1494593 4 aperez 2019-01-15 03:44:16 -0800 FWIW, my main issue with this is the lack of explanation in the API documentation. The name is quite “meh”, but that is less of a concern if the others out there prefer to keep it as is :) 1494598 5 cgarcia 2019-01-15 04:19:13 -0800 (In reply to Adrian Perez from comment #3) > Comment on attachment 359147 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=359147&action=review > > Informally reviewing, this would be a r- for my: the description > in the API documentation is seriously lacking, and the name of the > setting is quite bad (non-descriptive, and difficult to search > online for). I don't care what WebKit calls the setting internally, > I would rather have a name for it that better indicates what it does > *and* that we provide a good description of what the setting does and > its intended usage. > > > Source/WebKit/UIProcess/API/glib/WebKitSettings.cpp:3582 > > + * Returns: %TRUE If JavaScript markup is enabled or %FALSE otherwise. > > What is “JavaScript Markup”? A specification, a WebKit specific concept? > Something widely understood among Web developers?... I think the > documentation > for this setting needs an explanation of what the option does, as it is > nearly > impossible to find anything about this topic that would seem relevant when > implementing an application which makes use of WebKit. > > After some digging in the repository history I arrived at bug #112999 and > bug #113122 and it took me wading through a pile of comments and reading > some bits of the code to guess what the setting does. So please let's make > the API documentation better by adding something in the lines of: > > “Enabling this setting will strip <script> tags from loaded HTML > content, but other forms of JavaScript execution e.g. using > webkit_web_view_run_javascript() are still allowed. This setting > is intended for applications which display HTML content but are > not full browsers, and which want to avoid the risk of script > injection attacks, as is the case of applications like e-mail > and news readers.” The explanation in the patch is even more accurate and complete than this one, I would say: + * Determines whether or not JavaScript markup is allowed in document. When this setting is disabled, + * all JavaScript related elements and attributes are removed from the document during parsing. Note that + * executing JavaScript is still allowed if #WebKitSettings:enable-javascript is %TRUE. It's not only about script tags but also even listener attributes like onload and other js related attributes. That's clear in the current explanation. It also says that elements are removed while parsing and that js execution is still possible (not only run_js, but any js execution). > If possible it should be more concrete that the above explaining what > gets restricted and what not, because very often we programmers end up > introducing accidental security vulnerabilities due to assumptions we > make caused by incomplete documentation of third party code used. I think it's clear enough. I'm open to change the name of the setting, though. 1494609 6 aperez 2019-01-15 06:25:24 -0800 (In reply to Carlos Garcia Campos from comment #5) > (In reply to Adrian Perez from comment #3) > > Comment on attachment 359147 [details] > > Patch > > > > View in context: > > https://bugs.webkit.org/attachment.cgi?id=359147&action=review > > > > Informally reviewing, this would be a r- for my: the description > > in the API documentation is seriously lacking, and the name of the > > setting is quite bad (non-descriptive, and difficult to search > > online for). I don't care what WebKit calls the setting internally, > > I would rather have a name for it that better indicates what it does > > *and* that we provide a good description of what the setting does and > > its intended usage. > > > > > Source/WebKit/UIProcess/API/glib/WebKitSettings.cpp:3582 > > > + * Returns: %TRUE If JavaScript markup is enabled or %FALSE otherwise. > > > > What is “JavaScript Markup”? A specification, a WebKit specific concept? > > Something widely understood among Web developers?... I think the > > documentation > > for this setting needs an explanation of what the option does, as it is > > nearly > > impossible to find anything about this topic that would seem relevant when > > implementing an application which makes use of WebKit. > > > > After some digging in the repository history I arrived at bug #112999 and > > bug #113122 and it took me wading through a pile of comments and reading > > some bits of the code to guess what the setting does. So please let's make > > the API documentation better by adding something in the lines of: > > > > “Enabling this setting will strip <script> tags from loaded HTML > > content, but other forms of JavaScript execution e.g. using > > webkit_web_view_run_javascript() are still allowed. This setting > > is intended for applications which display HTML content but are > > not full browsers, and which want to avoid the risk of script > > injection attacks, as is the case of applications like e-mail > > and news readers.” > > The explanation in the patch is even more accurate and complete than this > one, I would say: > > + * Determines whether or not JavaScript markup is allowed in document. > When this setting is disabled, > + * all JavaScript related elements and attributes are removed from the > document during parsing. Note that > + * executing JavaScript is still allowed if > #WebKitSettings:enable-javascript is %TRUE. TBH, with this writing it is not completely clear to me what the setting does. What does “all JavaScript related elements and attributes” mean? For example it does not answer question like: - Can the JS DOM API be used to insert a new <script> tag? - If a <script> tag can be inserted using the DOM, will it work for <script src="..."> or only for elements with inline JS code in them? - Will <script> tags inside nested frames or an <iframe> be loaded and executed? (and that's only from the top of my head, I could come up with more) > It's not only about script tags but also even listener attributes like > onload and other js related attributes. That's clear in the current > explanation. It also says that elements are removed while parsing and that > js execution is still possible (not only run_js, but any js execution). Which other means of execution other than *_run_javascript()? If “ALL JavaScript related elements and attributes” can't be used (according to the description, emphasis mine on “all”), how come that other means of execution whih are NOT under control of the C API can result in JS being executed? > > If possible it should be more concrete that the above explaining what > > gets restricted and what not, because very often we programmers end up > > introducing accidental security vulnerabilities due to assumptions we > > make caused by incomplete documentation of third party code used. > > I think it's clear enough. I'm open to change the name of the setting, > though. To be honest, I am left with even more questions, so definitely not “clear enough” for me. Not being clear and exhaustive explaining this kind of things in the API documentation which affect security would do a disservice, IMO. My least of concerns is the name of the option, like I wrote already. :-\ 1494611 7 cgarcia 2019-01-15 06:35:25 -0800 (In reply to Adrian Perez from comment #6) > (In reply to Carlos Garcia Campos from comment #5) > > (In reply to Adrian Perez from comment #3) > > > Comment on attachment 359147 [details] > > > Patch > > > > > > View in context: > > > https://bugs.webkit.org/attachment.cgi?id=359147&action=review > > > > > > Informally reviewing, this would be a r- for my: the description > > > in the API documentation is seriously lacking, and the name of the > > > setting is quite bad (non-descriptive, and difficult to search > > > online for). I don't care what WebKit calls the setting internally, > > > I would rather have a name for it that better indicates what it does > > > *and* that we provide a good description of what the setting does and > > > its intended usage. > > > > > > > Source/WebKit/UIProcess/API/glib/WebKitSettings.cpp:3582 > > > > + * Returns: %TRUE If JavaScript markup is enabled or %FALSE otherwise. > > > > > > What is “JavaScript Markup”? A specification, a WebKit specific concept? > > > Something widely understood among Web developers?... I think the > > > documentation > > > for this setting needs an explanation of what the option does, as it is > > > nearly > > > impossible to find anything about this topic that would seem relevant when > > > implementing an application which makes use of WebKit. > > > > > > After some digging in the repository history I arrived at bug #112999 and > > > bug #113122 and it took me wading through a pile of comments and reading > > > some bits of the code to guess what the setting does. So please let's make > > > the API documentation better by adding something in the lines of: > > > > > > “Enabling this setting will strip <script> tags from loaded HTML > > > content, but other forms of JavaScript execution e.g. using > > > webkit_web_view_run_javascript() are still allowed. This setting > > > is intended for applications which display HTML content but are > > > not full browsers, and which want to avoid the risk of script > > > injection attacks, as is the case of applications like e-mail > > > and news readers.” > > > > The explanation in the patch is even more accurate and complete than this > > one, I would say: > > > > + * Determines whether or not JavaScript markup is allowed in document. > > When this setting is disabled, > > + * all JavaScript related elements and attributes are removed from the > > document during parsing. Note that > > + * executing JavaScript is still allowed if > > #WebKitSettings:enable-javascript is %TRUE. > > TBH, with this writing it is not completely clear to me what the > setting does. What does “all JavaScript related elements and attributes” > mean? For example it does not answer question like: > > - Can the JS DOM API be used to insert a new <script> tag? Yes, that happens after parsing. > - If a <script> tag can be inserted using the DOM, will it work for > <script src="..."> or only for elements with inline JS code in them? It should work either way. > - Will <script> tags inside nested frames or an <iframe> be loaded > and executed? No. > (and that's only from the top of my head, I could come up with more) > > > It's not only about script tags but also even listener attributes like > > onload and other js related attributes. That's clear in the current > > explanation. It also says that elements are removed while parsing and that > > js execution is still possible (not only run_js, but any js execution). > > Which other means of execution other than *_run_javascript()? Use scripts, js api in the web extension, user message handlers, etc. > If “ALL > JavaScript related elements and attributes” can't be used (according to > the description, emphasis mine on “all”), The description doesn't say they can't be used, it says they are removed from the document during parsing. > how come that other means of > execution whih are NOT under control of the C API can result in JS > being executed? Because other means of execution don't depend on script tags and attributes present in the document during parsing. > > > If possible it should be more concrete that the above explaining what > > > gets restricted and what not, because very often we programmers end up > > > introducing accidental security vulnerabilities due to assumptions we > > > make caused by incomplete documentation of third party code used. > > > > I think it's clear enough. I'm open to change the name of the setting, > > though. > > To be honest, I am left with even more questions, so definitely not > “clear enough” for me. Not being clear and exhaustive explaining this > kind of things in the API documentation which affect security would > do a disservice, IMO. I'm fine with adding more explanations, but what you propose doesn't look better than the current text IMO. > My least of concerns is the name of the option, like I wrote already. > > :-\ I agree. 1496502 8 359147 mcatanzaro 2019-01-20 20:33:59 -0800 Comment on attachment 359147 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=359147&action=review Nice test. > Source/WebKit/UIProcess/API/glib/WebKitSettings.cpp:1458 > + * Determines whether or not JavaScript markup is allowed in document. When this setting is disabled, documents. > Source/WebKit/UIProcess/API/glib/WebKitSettings.cpp:1459 > + * all JavaScript related elements and attributes are removed from the document during parsing. Note that JavaScript-related > Source/WebKit/UIProcess/API/glib/WebKitSettings.cpp:1460 > + * all JavaScript related elements and attributes are removed from the document during parsing. Note that > + * executing JavaScript is still allowed if #WebKitSettings:enable-javascript is %TRUE. I agree with Adrian that this documentation in insufficient. Basically all of his questions should be clarified by better documentation. But I have another concern. Executing JavaScript is still allowed... how? "Use scripts, js api in the web extension, user message handlers, etc." OK, but those are API requests, and I've separately suggests that API requests should always ignore #WebKitSettings:enable-javascript and execute anyway. This looked like something we could change on a cross-platform basis. So then maybe this new setting is not needed after all, if it, in practice, just blocks all JS except API requests? I really don't like mentioning that executing JavaScript is still allowed via API if #WebKitSettings:enable-javascript is %TRUE here, because I want to change that! Basically my fear is that "enable-javascript-markup" is the setting that most applications will want to use, and "enable-javascript" will be a wrong trap choice. So I'd rather make that usable first. Would this setting still be useful after that change? r- to improve the docs and continue this discussion. The code is fine, of course. >>>>> Source/WebKit/UIProcess/API/glib/WebKitSettings.cpp:3582 >>>>> + * Returns: %TRUE If JavaScript markup is enabled or %FALSE otherwise. >>>> >>>> What is “JavaScript Markup”? A specification, a WebKit specific concept? >>>> Something widely understood among Web developers?... I think the documentation >>>> for this setting needs an explanation of what the option does, as it is nearly >>>> impossible to find anything about this topic that would seem relevant when >>>> implementing an application which makes use of WebKit. >>>> >>>> After some digging in the repository history I arrived at bug #112999 and >>>> bug #113122 and it took me wading through a pile of comments and reading >>>> some bits of the code to guess what the setting does. So please let's make >>>> the API documentation better by adding something in the lines of: >>>> >>>> “Enabling this setting will strip <script> tags from loaded HTML >>>> content, but other forms of JavaScript execution e.g. using >>>> webkit_web_view_run_javascript() are still allowed. This setting >>>> is intended for applications which display HTML content but are >>>> not full browsers, and which want to avoid the risk of script >>>> injection attacks, as is the case of applications like e-mail >>>> and news readers.” >>>> >>>> If possible it should be more concrete that the above explaining what >>>> gets restricted and what not, because very often we programmers end up >>>> introducing accidental security vulnerabilities due to assumptions we >>>> make caused by incomplete documentation of third party code used. >>> >>> The explanation in the patch is even more accurate and complete than this one, I would say: >>> >>> + * Determines whether or not JavaScript markup is allowed in document. When this setting is disabled, >>> + * all JavaScript related elements and attributes are removed from the document during parsing. Note that >>> + * executing JavaScript is still allowed if #WebKitSettings:enable-javascript is %TRUE. >>> >>> It's not only about script tags but also even listener attributes like onload and other js related attributes. That's clear in the current explanation. It also says that elements are removed while parsing and that js execution is still possible (not only run_js, but any js execution). >> >> TBH, with this writing it is not completely clear to me what the >> setting does. What does “all JavaScript related elements and attributes” >> mean? For example it does not answer question like: >> >> - Can the JS DOM API be used to insert a new <script> tag? >> - If a <script> tag can be inserted using the DOM, will it work for >> <script src="..."> or only for elements with inline JS code in them? >> - Will <script> tags inside nested frames or an <iframe> be loaded >> and executed? >> >> (and that's only from the top of my head, I could come up with more) > > Yes, that happens after parsing. "%TRUE If" -> "%TRUE if" > Tools/TestWebKitAPI/Tests/WebKitGLib/TestWebKitSettings.cpp:437 > + " <body onload='document.title = \"JavaScript allowed from body onload attribute\"'>" JavaScript improperly allowed > Tools/TestWebKitAPI/Tests/WebKitGLib/TestWebKitSettings.cpp:439 > + " <script>document.title = 'JavaScript allowed from body script'</script>" JavaScript improperly allowed > Tools/TestWebKitAPI/Tests/WebKitGLib/TestWebKitSettings.cpp:447 > + g_assert(jsResult); g_assert_nonnull 1496537 9 cgarcia 2019-01-21 00:00:35 -0800 (In reply to Michael Catanzaro from comment #8) > Comment on attachment 359147 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=359147&action=review > > Nice test. > > > Source/WebKit/UIProcess/API/glib/WebKitSettings.cpp:1458 > > + * Determines whether or not JavaScript markup is allowed in document. When this setting is disabled, > > documents. I mean the page document. > > Source/WebKit/UIProcess/API/glib/WebKitSettings.cpp:1459 > > + * all JavaScript related elements and attributes are removed from the document during parsing. Note that > > JavaScript-related > > > Source/WebKit/UIProcess/API/glib/WebKitSettings.cpp:1460 > > + * all JavaScript related elements and attributes are removed from the document during parsing. Note that > > + * executing JavaScript is still allowed if #WebKitSettings:enable-javascript is %TRUE. > > I agree with Adrian that this documentation in insufficient. Basically all > of his questions should be clarified by better documentation. Ok, I'm open to suggestions. > But I have another concern. Executing JavaScript is still allowed... how? I think this is pretty clear too... JavaScript execution is not disallowed at all, the script elements and attributes are re moved from the document, that's the only thing. > "Use scripts, js api in the web extension, user message handlers, etc." OK, > but those are API requests, and I've separately suggests that API requests > should always ignore #WebKitSettings:enable-javascript and execute anyway. Yes, that's also desirable. > This looked like something we could change on a cross-platform basis. So > then maybe this new setting is not needed after all, if it, in practice, > just blocks all JS except API requests? That's a good question, I'm adding Geoffrey to the CC, since he suggested to use this setting instead of enable-js. > I really don't like mentioning that > executing JavaScript is still allowed via API if > #WebKitSettings:enable-javascript is %TRUE here, because I want to change > that! Basically my fear is that "enable-javascript-markup" is the setting > that most applications will want to use, and "enable-javascript" will be a > wrong trap choice. So I'd rather make that usable first. Would this setting > still be useful after that change? If removing js markup from document is a better approach we could just deprecate the other setting. I find more confusing a setting that disables js, but still allows it for API stuff, than a setting that removes js markup from document (but it seems this is only clear enough for me). > r- to improve the docs and continue this discussion. The code is fine, of > course. > > >>>>> Source/WebKit/UIProcess/API/glib/WebKitSettings.cpp:3582 > >>>>> + * Returns: %TRUE If JavaScript markup is enabled or %FALSE otherwise. > >>>> > >>>> What is “JavaScript Markup”? A specification, a WebKit specific concept? > >>>> Something widely understood among Web developers?... I think the documentation > >>>> for this setting needs an explanation of what the option does, as it is nearly > >>>> impossible to find anything about this topic that would seem relevant when > >>>> implementing an application which makes use of WebKit. > >>>> > >>>> After some digging in the repository history I arrived at bug #112999 and > >>>> bug #113122 and it took me wading through a pile of comments and reading > >>>> some bits of the code to guess what the setting does. So please let's make > >>>> the API documentation better by adding something in the lines of: > >>>> > >>>> “Enabling this setting will strip <script> tags from loaded HTML > >>>> content, but other forms of JavaScript execution e.g. using > >>>> webkit_web_view_run_javascript() are still allowed. This setting > >>>> is intended for applications which display HTML content but are > >>>> not full browsers, and which want to avoid the risk of script > >>>> injection attacks, as is the case of applications like e-mail > >>>> and news readers.” > >>>> > >>>> If possible it should be more concrete that the above explaining what > >>>> gets restricted and what not, because very often we programmers end up > >>>> introducing accidental security vulnerabilities due to assumptions we > >>>> make caused by incomplete documentation of third party code used. > >>> > >>> The explanation in the patch is even more accurate and complete than this one, I would say: > >>> > >>> + * Determines whether or not JavaScript markup is allowed in document. When this setting is disabled, > >>> + * all JavaScript related elements and attributes are removed from the document during parsing. Note that > >>> + * executing JavaScript is still allowed if #WebKitSettings:enable-javascript is %TRUE. > >>> > >>> It's not only about script tags but also even listener attributes like onload and other js related attributes. That's clear in the current explanation. It also says that elements are removed while parsing and that js execution is still possible (not only run_js, but any js execution). > >> > >> TBH, with this writing it is not completely clear to me what the > >> setting does. What does “all JavaScript related elements and attributes” > >> mean? For example it does not answer question like: > >> > >> - Can the JS DOM API be used to insert a new <script> tag? > >> - If a <script> tag can be inserted using the DOM, will it work for > >> <script src="..."> or only for elements with inline JS code in them? > >> - Will <script> tags inside nested frames or an <iframe> be loaded > >> and executed? > >> > >> (and that's only from the top of my head, I could come up with more) > > > > Yes, that happens after parsing. > > "%TRUE If" -> "%TRUE if" > > > Tools/TestWebKitAPI/Tests/WebKitGLib/TestWebKitSettings.cpp:437 > > + " <body onload='document.title = \"JavaScript allowed from body onload attribute\"'>" > > JavaScript improperly allowed > > > Tools/TestWebKitAPI/Tests/WebKitGLib/TestWebKitSettings.cpp:439 > > + " <script>document.title = 'JavaScript allowed from body script'</script>" > > JavaScript improperly allowed > > > Tools/TestWebKitAPI/Tests/WebKitGLib/TestWebKitSettings.cpp:447 > > + g_assert(jsResult); > > g_assert_nonnull 1496641 10 mcatanzaro 2019-01-21 12:46:12 -0800 (In reply to Carlos Garcia Campos from comment #9) > I think this is pretty clear too... JavaScript execution is not disallowed > at all, the script elements and attributes are re moved from the document, > that's the only thing. Are there other ways to execute JavaScript, asides from script elements, script attributes, and API requests? I guess not? > > This looked like something we could change on a cross-platform basis. So > > then maybe this new setting is not needed after all, if it, in practice, > > just blocks all JS except API requests? > > That's a good question, I'm adding Geoffrey to the CC, since he suggested to > use this setting instead of enable-js. Basically I think we should fix bug #192753 one way or the other *first* and only *then* decide whether to add this setting. Because as I understand this setting, our solution to that bug might obviate the need for this setting. 1498172 11 cgarcia 2019-01-25 01:26:24 -0800 (In reply to Michael Catanzaro from comment #10) > (In reply to Carlos Garcia Campos from comment #9) > > I think this is pretty clear too... JavaScript execution is not disallowed > > at all, the script elements and attributes are re moved from the document, > > that's the only thing. > > Are there other ways to execute JavaScript, asides from script elements, > script attributes, and API requests? I guess not? > > > > This looked like something we could change on a cross-platform basis. So > > > then maybe this new setting is not needed after all, if it, in practice, > > > just blocks all JS except API requests? > > > > That's a good question, I'm adding Geoffrey to the CC, since he suggested to > > use this setting instead of enable-js. > > Basically I think we should fix bug #192753 one way or the other *first* and > only *then* decide whether to add this setting. Because as I understand this > setting, our solution to that bug might obviate the need for this setting. This is not so easy in the end. Maybe run_js should be allowed when js is disabled in settings, but FrameLoader doesn't dispatch didClearWindowObjectInWorld() when scripts are not allowed, so we can't inject our internal js api in the web process. There are more places where canExecuteScripts() is checked. I think it's by far a lot easier to explain and understand that script elements and attributes are removed from the document while parsing. 1498234 12 mcatanzaro 2019-01-25 07:41:42 -0800 (In reply to Carlos Garcia Campos from comment #11) > This is not so easy in the end. Maybe run_js should be allowed when js is > disabled in settings, but FrameLoader doesn't dispatch > didClearWindowObjectInWorld() when scripts are not allowed So that means accessibility doesn't work when enable-js is disabled and nobody ever noticed this, right? 1498235 13 mcatanzaro 2019-01-25 07:43:08 -0800 r=me with improved documentation, then. Maybe add a sentence or two listing some of the forms of JS execution that are blocked and not blocked by this setting. 1498248 14 cgarcia 2019-01-25 08:14:17 -0800 (In reply to Michael Catanzaro from comment #12) > (In reply to Carlos Garcia Campos from comment #11) > > This is not so easy in the end. Maybe run_js should be allowed when js is > > disabled in settings, but FrameLoader doesn't dispatch > > didClearWindowObjectInWorld() when scripts are not allowed > > So that means accessibility doesn't work when enable-js is disabled and > nobody ever noticed this, right? Accessibility? why? 1498254 15 mcatanzaro 2019-01-25 08:46:58 -0800 (In reply to Carlos Garcia Campos from comment #14) > Accessibility? why? https://bugs.webkit.org/show_bug.cgi?id=182257#c18 1498260 16 cgarcia 2019-01-25 08:51:36 -0800 (In reply to Michael Catanzaro from comment #15) > (In reply to Carlos Garcia Campos from comment #14) > > Accessibility? why? > > https://bugs.webkit.org/show_bug.cgi?id=182257#c18 Oh, wow, a11y stuff doesn't belong to did clear window object indeed. 1504806 17 cgarcia 2019-02-10 22:35:42 -0800 I'm going to land this before branching, we can improve the documentation in a follow up patch. Suggestions would be welcome, because current wording is still crystal clear for me. 1504807 18 cgarcia 2019-02-10 22:36:11 -0800 Committed r241258: <https://trac.webkit.org/changeset/241258> 1504858 19 359147 mcatanzaro 2019-02-11 07:07:35 -0800 Comment on attachment 359147 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=359147&action=review >>> Source/WebKit/UIProcess/API/glib/WebKitSettings.cpp:1458 >>> + * Determines whether or not JavaScript markup is allowed in document. When this setting is disabled, >> >> documents. > > I mean the page document. Still should be: "documents." 359147 2019-01-15 01:19:27 -0800 2019-02-11 07:07:35 -0800 Patch wk-js-markup-setting.diff text/plain 11353 cgarcia ZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJLaXQvQ2hhbmdlTG9nIGIvU291cmNlL1dlYktpdC9DaGFu Z2VMb2cKaW5kZXggYjE1ODBmYzA1OGIuLjdjYjI2MWJmYmU2IDEwMDY0NAotLS0gYS9Tb3VyY2Uv V2ViS2l0L0NoYW5nZUxvZworKysgYi9Tb3VyY2UvV2ViS2l0L0NoYW5nZUxvZwpAQCAtMSwzICsx LDIzIEBACisyMDE5LTAxLTE1ICBDYXJsb3MgR2FyY2lhIENhbXBvcyAgPGNnYXJjaWFAaWdhbGlh LmNvbT4KKworICAgICAgICBbR1RLXVtXUEVdIEFkZCBlbmFibGUtamF2YXNjcmlwdC1tYXJrdXAg c2V0dGluZworICAgICAgICBodHRwczovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9 MTkzNDM5CisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAg RXhwb3NlIEphdmFTY3JpcHRNYXJrdXBFbmFibGVkIHNldHRpbmcgaW4gdGhlIEdMaWIgQVBJLgor CisgICAgICAgICogVUlQcm9jZXNzL0FQSS9nbGliL1dlYktpdFNldHRpbmdzLmNwcDoKKyAgICAg ICAgKHdlYktpdFNldHRpbmdzU2V0UHJvcGVydHkpOgorICAgICAgICAod2ViS2l0U2V0dGluZ3NH ZXRQcm9wZXJ0eSk6CisgICAgICAgICh3ZWJraXRfc2V0dGluZ3NfY2xhc3NfaW5pdCk6CisgICAg ICAgICh3ZWJraXRfc2V0dGluZ3NfZ2V0X2VuYWJsZV9qYXZhc2NyaXB0X21hcmt1cCk6CisgICAg ICAgICh3ZWJraXRfc2V0dGluZ3Nfc2V0X2VuYWJsZV9qYXZhc2NyaXB0X21hcmt1cCk6CisgICAg ICAgICogVUlQcm9jZXNzL0FQSS9ndGsvV2ViS2l0U2V0dGluZ3MuaDoKKyAgICAgICAgKiBVSVBy b2Nlc3MvQVBJL2d0ay9kb2NzL3dlYmtpdDJndGstNC4wLXNlY3Rpb25zLnR4dDoKKyAgICAgICAg KiBVSVByb2Nlc3MvQVBJL3dwZS9XZWJLaXRTZXR0aW5ncy5oOgorICAgICAgICAqIFVJUHJvY2Vz cy9BUEkvd3BlL2RvY3Mvd3BlLTAuMS1zZWN0aW9ucy50eHQ6CisKIDIwMTktMDEtMTQgIEFsZXgg Q2hyaXN0ZW5zZW4gIDxhY2hyaXN0ZW5zZW5Ad2Via2l0Lm9yZz4KIAogICAgICAgICBTcGxpdCBo ZWFkZXJWYWx1ZUZvclZhcnkgaW50byBzcGVjaWFsaXplZCBmdW5jdGlvbnMgZm9yIE5ldHdvcmtQ cm9jZXNzIGFuZCBXZWJQcm9jZXNzL1dlYktpdExlZ2FjeQpkaWZmIC0tZ2l0IGEvU291cmNlL1dl YktpdC9VSVByb2Nlc3MvQVBJL2dsaWIvV2ViS2l0U2V0dGluZ3MuY3BwIGIvU291cmNlL1dlYktp dC9VSVByb2Nlc3MvQVBJL2dsaWIvV2ViS2l0U2V0dGluZ3MuY3BwCmluZGV4IDRlYzdmOTgxMzlh Li5iNWQ0NGJjMWFhZiAxMDA2NDQKLS0tIGEvU291cmNlL1dlYktpdC9VSVByb2Nlc3MvQVBJL2ds aWIvV2ViS2l0U2V0dGluZ3MuY3BwCisrKyBiL1NvdXJjZS9XZWJLaXQvVUlQcm9jZXNzL0FQSS9n bGliL1dlYktpdFNldHRpbmdzLmNwcApAQCAtMTYyLDYgKzE2Miw3IEBAIGVudW0gewogI2lmIFBM QVRGT1JNKEdUSykKICAgICBQUk9QX0hBUkRXQVJFX0FDQ0VMRVJBVElPTl9QT0xJQ1ksCiAjZW5k aWYKKyAgICBQUk9QX0VOQUJMRV9KQVZBU0NSSVBUX01BUktVUCwKIH07CiAKIHN0YXRpYyB2b2lk IHdlYktpdFNldHRpbmdzRGlzcG9zZShHT2JqZWN0KiBvYmplY3QpCkBAIC0zODIsNiArMzgzLDkg QEAgc3RhdGljIHZvaWQgd2ViS2l0U2V0dGluZ3NTZXRQcm9wZXJ0eShHT2JqZWN0KiBvYmplY3Qs IGd1aW50IHByb3BJZCwgY29uc3QgR1ZhbHUKICAgICAgICAgd2Via2l0X3NldHRpbmdzX3NldF9o YXJkd2FyZV9hY2NlbGVyYXRpb25fcG9saWN5KHNldHRpbmdzLCBzdGF0aWNfY2FzdDxXZWJLaXRI YXJkd2FyZUFjY2VsZXJhdGlvblBvbGljeT4oZ192YWx1ZV9nZXRfZW51bSh2YWx1ZSkpKTsKICAg ICAgICAgYnJlYWs7CiAjZW5kaWYKKyAgICBjYXNlIFBST1BfRU5BQkxFX0pBVkFTQ1JJUFRfTUFS S1VQOgorICAgICAgICB3ZWJraXRfc2V0dGluZ3Nfc2V0X2VuYWJsZV9qYXZhc2NyaXB0X21hcmt1 cChzZXR0aW5ncywgZ192YWx1ZV9nZXRfYm9vbGVhbih2YWx1ZSkpOworICAgICAgICBicmVhazsK ICAgICBkZWZhdWx0OgogICAgICAgICBHX09CSkVDVF9XQVJOX0lOVkFMSURfUFJPUEVSVFlfSUQo b2JqZWN0LCBwcm9wSWQsIHBhcmFtU3BlYyk7CiAgICAgICAgIGJyZWFrOwpAQCAtNTYxLDYgKzU2 NSw5IEBAIHN0YXRpYyB2b2lkIHdlYktpdFNldHRpbmdzR2V0UHJvcGVydHkoR09iamVjdCogb2Jq ZWN0LCBndWludCBwcm9wSWQsIEdWYWx1ZSogdmFsCiAgICAgICAgIGdfdmFsdWVfc2V0X2VudW0o dmFsdWUsIHdlYmtpdF9zZXR0aW5nc19nZXRfaGFyZHdhcmVfYWNjZWxlcmF0aW9uX3BvbGljeShz ZXR0aW5ncykpOwogICAgICAgICBicmVhazsKICNlbmRpZgorICAgIGNhc2UgUFJPUF9FTkFCTEVf SkFWQVNDUklQVF9NQVJLVVA6CisgICAgICAgIGdfdmFsdWVfc2V0X2Jvb2xlYW4odmFsdWUsIHdl YmtpdF9zZXR0aW5nc19nZXRfZW5hYmxlX2phdmFzY3JpcHRfbWFya3VwKHNldHRpbmdzKSk7Cisg ICAgICAgIGJyZWFrOwogICAgIGRlZmF1bHQ6CiAgICAgICAgIEdfT0JKRUNUX1dBUk5fSU5WQUxJ RF9QUk9QRVJUWV9JRChvYmplY3QsIHByb3BJZCwgcGFyYW1TcGVjKTsKICAgICAgICAgYnJlYWs7 CkBAIC0xNDQ0LDYgKzE0NTEsMjMgQEAgc3RhdGljIHZvaWQgd2Via2l0X3NldHRpbmdzX2NsYXNz X2luaXQoV2ViS2l0U2V0dGluZ3NDbGFzcyoga2xhc3MpCiAgICAgICAgICAgICBXRUJLSVRfSEFS RFdBUkVfQUNDRUxFUkFUSU9OX1BPTElDWV9PTl9ERU1BTkQsCiAgICAgICAgICAgICByZWFkV3Jp dGVDb25zdHJ1Y3RQYXJhbUZsYWdzKSk7CiAjZW5kaWYgLy8gUExBVEZPVE0oR1RLKQorCisgICAg LyoqCisgICAgICogV2ViS2l0U2V0dGluZ3M6ZW5hYmxlLWphdmFzY3JpcHQtbWFya3VwOgorICAg ICAqCisgICAgICogRGV0ZXJtaW5lcyB3aGV0aGVyIG9yIG5vdCBKYXZhU2NyaXB0IG1hcmt1cCBp cyBhbGxvd2VkIGluIGRvY3VtZW50LiBXaGVuIHRoaXMgc2V0dGluZyBpcyBkaXNhYmxlZCwKKyAg ICAgKiBhbGwgSmF2YVNjcmlwdCByZWxhdGVkIGVsZW1lbnRzIGFuZCBhdHRyaWJ1dGVzIGFyZSBy ZW1vdmVkIGZyb20gdGhlIGRvY3VtZW50IGR1cmluZyBwYXJzaW5nLiBOb3RlIHRoYXQKKyAgICAg KiBleGVjdXRpbmcgSmF2YVNjcmlwdCBpcyBzdGlsbCBhbGxvd2VkIGlmICNXZWJLaXRTZXR0aW5n czplbmFibGUtamF2YXNjcmlwdCBpcyAlVFJVRS4KKyAgICAgKgorICAgICAqIFNpbmNlOiAyLjI0 CisgICAgICovCisgICAgZ19vYmplY3RfY2xhc3NfaW5zdGFsbF9wcm9wZXJ0eShnT2JqZWN0Q2xh c3MsCisgICAgICAgIFBST1BfRU5BQkxFX0pBVkFTQ1JJUFRfTUFSS1VQLAorICAgICAgICBnX3Bh cmFtX3NwZWNfYm9vbGVhbigiZW5hYmxlLWphdmFzY3JpcHQtbWFya3VwIiwKKyAgICAgICAgICAg IF8oIkVuYWJsZSBKYXZhU2NyaXB0IE1hcmt1cCIpLAorICAgICAgICAgICAgXygiRW5hYmxlIEph dmFTY3JpcHQgaW4gZG9jdW1lbnQgbWFya3VwLiIpLAorICAgICAgICAgICAgVFJVRSwKKyAgICAg ICAgICAgIHJlYWRXcml0ZUNvbnN0cnVjdFBhcmFtRmxhZ3MpKTsKIH0KIAogV2ViUHJlZmVyZW5j ZXMqIHdlYmtpdFNldHRpbmdzR2V0UHJlZmVyZW5jZXMoV2ViS2l0U2V0dGluZ3MqIHNldHRpbmdz KQpAQCAtMzU0OCwzICszNTcyLDQyIEBAIGd1aW50MzIgd2Via2l0X3NldHRpbmdzX2ZvbnRfc2l6 ZV90b19waXhlbHMoZ3VpbnQzMiBwb2ludHMpCiAgICAgcmV0dXJuIHN0ZDo6cm91bmQocG9pbnRz ICogV2ViQ29yZTo6c2NyZWVuRFBJKCkgLyA3Mik7CiB9CiAjZW5kaWYgLy8gUExBVEZPUk0oR1RL KQorCisvKioKKyAqIHdlYmtpdF9zZXR0aW5nc19nZXRfZW5hYmxlX2phdmFzY3JpcHRfbWFya3Vw OgorICogQHNldHRpbmdzOiBhICNXZWJLaXRTZXR0aW5ncworICoKKyAqIEdldCB0aGUgI1dlYktp dFNldHRpbmdzOmVuYWJsZS1qYXZhc2NyaXB0LW1hcmt1cCBwcm9wZXJ0eS4KKyAqCisgKiBSZXR1 cm5zOiAlVFJVRSBJZiBKYXZhU2NyaXB0IG1hcmt1cCBpcyBlbmFibGVkIG9yICVGQUxTRSBvdGhl cndpc2UuCisgKgorICogU2luY2U6IDIuMjQKKyAqLworZ2Jvb2xlYW4gd2Via2l0X3NldHRpbmdz X2dldF9lbmFibGVfamF2YXNjcmlwdF9tYXJrdXAoV2ViS2l0U2V0dGluZ3MqIHNldHRpbmdzKQor eworICAgIGdfcmV0dXJuX3ZhbF9pZl9mYWlsKFdFQktJVF9JU19TRVRUSU5HUyhzZXR0aW5ncyks IEZBTFNFKTsKKworICAgIHJldHVybiBzZXR0aW5ncy0+cHJpdi0+cHJlZmVyZW5jZXMtPmphdmFT Y3JpcHRNYXJrdXBFbmFibGVkKCk7Cit9CisKKy8qKgorICogd2Via2l0X3NldHRpbmdzX3NldF9l bmFibGVfamF2YXNjcmlwdF9tYXJrdXA6CisgKiBAc2V0dGluZ3M6IGEgI1dlYktpdFNldHRpbmdz CisgKiBAZW5hYmxlZDogVmFsdWUgdG8gYmUgc2V0CisgKgorICogU2V0IHRoZSAjV2ViS2l0U2V0 dGluZ3M6ZW5hYmxlLWphdmFzY3JpcHQtbWFya3VwIHByb3BlcnR5LgorICoKKyAqIFNpbmNlOiAy LjI0CisgKi8KK3ZvaWQgd2Via2l0X3NldHRpbmdzX3NldF9lbmFibGVfamF2YXNjcmlwdF9tYXJr dXAoV2ViS2l0U2V0dGluZ3MqIHNldHRpbmdzLCBnYm9vbGVhbiBlbmFibGVkKQoreworICAgIGdf cmV0dXJuX2lmX2ZhaWwoV0VCS0lUX0lTX1NFVFRJTkdTKHNldHRpbmdzKSk7CisKKyAgICBXZWJL aXRTZXR0aW5nc1ByaXZhdGUqIHByaXYgPSBzZXR0aW5ncy0+cHJpdjsKKyAgICBib29sIGN1cnJl bnRWYWx1ZSA9IHByaXYtPnByZWZlcmVuY2VzLT5qYXZhU2NyaXB0TWFya3VwRW5hYmxlZCgpOwor ICAgIGlmIChjdXJyZW50VmFsdWUgPT0gZW5hYmxlZCkKKyAgICAgICAgcmV0dXJuOworCisgICAg cHJpdi0+cHJlZmVyZW5jZXMtPnNldEphdmFTY3JpcHRNYXJrdXBFbmFibGVkKGVuYWJsZWQpOwor ICAgIGdfb2JqZWN0X25vdGlmeShHX09CSkVDVChzZXR0aW5ncyksICJlbmFibGUtamF2YXNjcmlw dC1tYXJrdXAiKTsKK30KZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJLaXQvVUlQcm9jZXNzL0FQSS9n dGsvV2ViS2l0U2V0dGluZ3MuaCBiL1NvdXJjZS9XZWJLaXQvVUlQcm9jZXNzL0FQSS9ndGsvV2Vi S2l0U2V0dGluZ3MuaAppbmRleCBjYjJjMjA2ZTJmNi4uMDEwMzdkNGZkOWYgMTAwNjQ0Ci0tLSBh L1NvdXJjZS9XZWJLaXQvVUlQcm9jZXNzL0FQSS9ndGsvV2ViS2l0U2V0dGluZ3MuaAorKysgYi9T b3VyY2UvV2ViS2l0L1VJUHJvY2Vzcy9BUEkvZ3RrL1dlYktpdFNldHRpbmdzLmgKQEAgLTQ3OCw2 ICs0NzgsMTMgQEAgd2Via2l0X3NldHRpbmdzX2ZvbnRfc2l6ZV90b19wb2ludHMgICAgICAgICAg ICAgICAgICAgICAgICAgICAgKGd1aW50MzIgcGl4ZWxzKTsKIFdFQktJVF9BUEkgZ3VpbnQzMgog d2Via2l0X3NldHRpbmdzX2ZvbnRfc2l6ZV90b19waXhlbHMgICAgICAgICAgICAgICAgICAgICAg ICAgICAgKGd1aW50MzIgcG9pbnRzKTsKIAorV0VCS0lUX0FQSSBnYm9vbGVhbgord2Via2l0X3Nl dHRpbmdzX2dldF9lbmFibGVfamF2YXNjcmlwdF9tYXJrdXAgICAgICAgICAgICAgICAgICAgKFdl YktpdFNldHRpbmdzICpzZXR0aW5ncyk7CisKK1dFQktJVF9BUEkgdm9pZAord2Via2l0X3NldHRp bmdzX3NldF9lbmFibGVfamF2YXNjcmlwdF9tYXJrdXAgICAgICAgICAgICAgICAgICAgKFdlYktp dFNldHRpbmdzICpzZXR0aW5ncywKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBnYm9vbGVhbiAgICAgICAgZW5hYmxlZCk7CisK IEdfRU5EX0RFQ0xTCiAKICNlbmRpZiAvKiBXZWJLaXRTZXR0aW5nc19oICovCmRpZmYgLS1naXQg YS9Tb3VyY2UvV2ViS2l0L1VJUHJvY2Vzcy9BUEkvZ3RrL2RvY3Mvd2Via2l0Mmd0ay00LjAtc2Vj dGlvbnMudHh0IGIvU291cmNlL1dlYktpdC9VSVByb2Nlc3MvQVBJL2d0ay9kb2NzL3dlYmtpdDJn dGstNC4wLXNlY3Rpb25zLnR4dAppbmRleCA3NTZhYWE0ZGU3Mi4uZmRhN2RlYWE2YmUgMTAwNjQ0 Ci0tLSBhL1NvdXJjZS9XZWJLaXQvVUlQcm9jZXNzL0FQSS9ndGsvZG9jcy93ZWJraXQyZ3RrLTQu MC1zZWN0aW9ucy50eHQKKysrIGIvU291cmNlL1dlYktpdC9VSVByb2Nlc3MvQVBJL2d0ay9kb2Nz L3dlYmtpdDJndGstNC4wLXNlY3Rpb25zLnR4dApAQCAtMzkyLDYgKzM5Miw4IEBAIHdlYmtpdF9z ZXR0aW5nc19nZXRfZW5hYmxlX2phdmEKIHdlYmtpdF9zZXR0aW5nc19zZXRfZW5hYmxlX2phdmEK IHdlYmtpdF9zZXR0aW5nc19nZXRfZW5hYmxlX2phdmFzY3JpcHQKIHdlYmtpdF9zZXR0aW5nc19z ZXRfZW5hYmxlX2phdmFzY3JpcHQKK3dlYmtpdF9zZXR0aW5nc19nZXRfZW5hYmxlX2phdmFzY3Jp cHRfbWFya3VwCit3ZWJraXRfc2V0dGluZ3Nfc2V0X2VuYWJsZV9qYXZhc2NyaXB0X21hcmt1cAog d2Via2l0X3NldHRpbmdzX2dldF9lbmFibGVfb2ZmbGluZV93ZWJfYXBwbGljYXRpb25fY2FjaGUK IHdlYmtpdF9zZXR0aW5nc19zZXRfZW5hYmxlX29mZmxpbmVfd2ViX2FwcGxpY2F0aW9uX2NhY2hl CiB3ZWJraXRfc2V0dGluZ3NfZ2V0X2VuYWJsZV9wbHVnaW5zCmRpZmYgLS1naXQgYS9Tb3VyY2Uv V2ViS2l0L1VJUHJvY2Vzcy9BUEkvd3BlL1dlYktpdFNldHRpbmdzLmggYi9Tb3VyY2UvV2ViS2l0 L1VJUHJvY2Vzcy9BUEkvd3BlL1dlYktpdFNldHRpbmdzLmgKaW5kZXggMmVjMGM5ZTI1YzMuLmE3 OTIxYWJmZWQxIDEwMDY0NAotLS0gYS9Tb3VyY2UvV2ViS2l0L1VJUHJvY2Vzcy9BUEkvd3BlL1dl YktpdFNldHRpbmdzLmgKKysrIGIvU291cmNlL1dlYktpdC9VSVByb2Nlc3MvQVBJL3dwZS9XZWJL aXRTZXR0aW5ncy5oCkBAIC00NDIsNiArNDQyLDEzIEBAIFdFQktJVF9BUEkgdm9pZAogd2Via2l0 X3NldHRpbmdzX3NldF9hbGxvd191bml2ZXJzYWxfYWNjZXNzX2Zyb21fZmlsZV91cmxzICAgICAg KFdlYktpdFNldHRpbmdzICpzZXR0aW5ncywKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBnYm9vbGVhbiAgICAgICAgYWxsb3dl ZCk7CiAKK1dFQktJVF9BUEkgZ2Jvb2xlYW4KK3dlYmtpdF9zZXR0aW5nc19nZXRfZW5hYmxlX2ph dmFzY3JpcHRfbWFya3VwICAgICAgICAgICAgICAgICAgIChXZWJLaXRTZXR0aW5ncyAqc2V0dGlu Z3MpOworCitXRUJLSVRfQVBJIHZvaWQKK3dlYmtpdF9zZXR0aW5nc19zZXRfZW5hYmxlX2phdmFz Y3JpcHRfbWFya3VwICAgICAgICAgICAgICAgICAgIChXZWJLaXRTZXR0aW5ncyAqc2V0dGluZ3Ms CisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgZ2Jvb2xlYW4gICAgICAgIGVuYWJsZWQpOworCiBHX0VORF9ERUNMUwogCiAjZW5k aWYgLyogV2ViS2l0U2V0dGluZ3NfaCAqLwpkaWZmIC0tZ2l0IGEvU291cmNlL1dlYktpdC9VSVBy b2Nlc3MvQVBJL3dwZS9kb2NzL3dwZS0wLjEtc2VjdGlvbnMudHh0IGIvU291cmNlL1dlYktpdC9V SVByb2Nlc3MvQVBJL3dwZS9kb2NzL3dwZS0wLjEtc2VjdGlvbnMudHh0CmluZGV4IDYyOGRiNDI1 MmE0Li42ZmNmNjFhZDBmNCAxMDA2NDQKLS0tIGEvU291cmNlL1dlYktpdC9VSVByb2Nlc3MvQVBJ L3dwZS9kb2NzL3dwZS0wLjEtc2VjdGlvbnMudHh0CisrKyBiL1NvdXJjZS9XZWJLaXQvVUlQcm9j ZXNzL0FQSS93cGUvZG9jcy93cGUtMC4xLXNlY3Rpb25zLnR4dApAQCAtMzc1LDYgKzM3NSw4IEBA IHdlYmtpdF9zZXR0aW5nc19nZXRfZW5hYmxlX2phdmEKIHdlYmtpdF9zZXR0aW5nc19zZXRfZW5h YmxlX2phdmEKIHdlYmtpdF9zZXR0aW5nc19nZXRfZW5hYmxlX2phdmFzY3JpcHQKIHdlYmtpdF9z ZXR0aW5nc19zZXRfZW5hYmxlX2phdmFzY3JpcHQKK3dlYmtpdF9zZXR0aW5nc19nZXRfZW5hYmxl X2phdmFzY3JpcHRfbWFya3VwCit3ZWJraXRfc2V0dGluZ3Nfc2V0X2VuYWJsZV9qYXZhc2NyaXB0 X21hcmt1cAogd2Via2l0X3NldHRpbmdzX2dldF9lbmFibGVfb2ZmbGluZV93ZWJfYXBwbGljYXRp b25fY2FjaGUKIHdlYmtpdF9zZXR0aW5nc19zZXRfZW5hYmxlX29mZmxpbmVfd2ViX2FwcGxpY2F0 aW9uX2NhY2hlCiB3ZWJraXRfc2V0dGluZ3NfZ2V0X2VuYWJsZV9wbHVnaW5zCmRpZmYgLS1naXQg YS9Ub29scy9DaGFuZ2VMb2cgYi9Ub29scy9DaGFuZ2VMb2cKaW5kZXggOTdiMjcyMDVjMzkuLmE1 MDI0ZGZjZTU1IDEwMDY0NAotLS0gYS9Ub29scy9DaGFuZ2VMb2cKKysrIGIvVG9vbHMvQ2hhbmdl TG9nCkBAIC0xLDMgKzEsMTcgQEAKKzIwMTktMDEtMTUgIENhcmxvcyBHYXJjaWEgQ2FtcG9zICA8 Y2dhcmNpYUBpZ2FsaWEuY29tPgorCisgICAgICAgIFtHVEtdW1dQRV0gQWRkIGVuYWJsZS1qYXZh c2NyaXB0LW1hcmt1cCBzZXR0aW5nCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3No b3dfYnVnLmNnaT9pZD0xOTM0MzkKKworICAgICAgICBSZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMh KS4KKworICAgICAgICBBZGQgdGVzdCBjYXNlcyB0byBjaGVjayB0aGUgbmV3IHNldHRpbmcuCisK KyAgICAgICAgKiBUZXN0V2ViS2l0QVBJL1Rlc3RzL1dlYktpdEdMaWIvVGVzdFdlYktpdFNldHRp bmdzLmNwcDoKKyAgICAgICAgKHRlc3RXZWJLaXRTZXR0aW5ncyk6CisgICAgICAgICh0ZXN0V2Vi S2l0U2V0dGluZ3NKYXZhU2NyaXB0TWFya3VwKToKKyAgICAgICAgKGJlZm9yZUFsbCk6CisKIDIw MTktMDEtMTQgIFRpbSBIb3J0b24gIDx0aW1vdGh5X2hvcnRvbkBhcHBsZS5jb20+CiAKICAgICAg ICAgTW92ZSBhIHRlc3QgaW1wbGVtZW50YXRpb24gZmlsZSB0aGF0IGdvdCBtaXNwbGFjZWQgaW4g dGhlIFhjb2RlIHByb2plY3QKZGlmZiAtLWdpdCBhL1Rvb2xzL1Rlc3RXZWJLaXRBUEkvVGVzdHMv V2ViS2l0R0xpYi9UZXN0V2ViS2l0U2V0dGluZ3MuY3BwIGIvVG9vbHMvVGVzdFdlYktpdEFQSS9U ZXN0cy9XZWJLaXRHTGliL1Rlc3RXZWJLaXRTZXR0aW5ncy5jcHAKaW5kZXggM2VkZDUzY2VkOTcu LjY5OTMyNDE5ODMxIDEwMDY0NAotLS0gYS9Ub29scy9UZXN0V2ViS2l0QVBJL1Rlc3RzL1dlYktp dEdMaWIvVGVzdFdlYktpdFNldHRpbmdzLmNwcAorKysgYi9Ub29scy9UZXN0V2ViS2l0QVBJL1Rl c3RzL1dlYktpdEdMaWIvVGVzdFdlYktpdFNldHRpbmdzLmNwcApAQCAtMzUwLDYgKzM1MCwxMSBA QCBzdGF0aWMgdm9pZCB0ZXN0V2ViS2l0U2V0dGluZ3MoVGVzdCosIGdjb25zdHBvaW50ZXIpCiAg ICAgZ19hc3NlcnRfY21wdWludCh3ZWJraXRfc2V0dGluZ3NfZ2V0X2hhcmR3YXJlX2FjY2VsZXJh dGlvbl9wb2xpY3koc2V0dGluZ3MpLCA9PSwgV0VCS0lUX0hBUkRXQVJFX0FDQ0VMRVJBVElPTl9Q T0xJQ1lfT05fREVNQU5EKTsKICNlbmRpZgogCisgICAgLy8gSmF2YVNjcmlwdCBtYXJrdXAgaXMg ZW5hYmxlZCBieSBkZWZhdWx0LgorICAgIGdfYXNzZXJ0X3RydWUod2Via2l0X3NldHRpbmdzX2dl dF9lbmFibGVfamF2YXNjcmlwdF9tYXJrdXAoc2V0dGluZ3MpKTsKKyAgICB3ZWJraXRfc2V0dGlu Z3Nfc2V0X2VuYWJsZV9qYXZhc2NyaXB0X21hcmt1cChzZXR0aW5ncywgRkFMU0UpOworICAgIGdf YXNzZXJ0X2ZhbHNlKHdlYmtpdF9zZXR0aW5nc19nZXRfZW5hYmxlX2phdmFzY3JpcHRfbWFya3Vw KHNldHRpbmdzKSk7CisKICAgICBnX29iamVjdF91bnJlZihHX09CSkVDVChzZXR0aW5ncykpOwog fQogCkBAIC00MjAsNiArNDI1LDMxIEBAIHN0YXRpYyB2b2lkIHRlc3RXZWJLaXRTZXR0aW5nc1Vz ZXJBZ2VudChXZWJWaWV3VGVzdCogdGVzdCwgZ2NvbnN0cG9pbnRlcikKIH0KICNlbmRpZiAvLyBQ TEFURk9STShHVEspCiAKK3N0YXRpYyB2b2lkIHRlc3RXZWJLaXRTZXR0aW5nc0phdmFTY3JpcHRN YXJrdXAoV2ViVmlld1Rlc3QqIHRlc3QsIGdjb25zdHBvaW50ZXIpCit7CisgICAgd2Via2l0X3Nl dHRpbmdzX3NldF9lbmFibGVfamF2YXNjcmlwdF9tYXJrdXAod2Via2l0X3dlYl92aWV3X2dldF9z ZXR0aW5ncyh0ZXN0LT5tX3dlYlZpZXcpLCBGQUxTRSk7CisgICAgc3RhdGljIGNvbnN0IGNoYXIq IGh0bWwgPQorICAgICAgICAiPGh0bWw+IgorICAgICAgICAiIDxoZWFkPiIKKyAgICAgICAgIiAg PHRpdGxlPk5vIEphdmFTY3JpcHQgYWxsb3dlZDwvdGl0bGU+IgorICAgICAgICAiICA8c2NyaXB0 PmRvY3VtZW50LnRpdGxlID0gJ0phdmFTY3JpcHQgYWxsb3dlZCBmcm9tIGhlYWQgc2NyaXB0Jzwv c2NyaXB0PiIKKyAgICAgICAgIiA8L2hlYWQ+IgorICAgICAgICAiIDxib2R5IG9ubG9hZD0nZG9j dW1lbnQudGl0bGUgPSBcIkphdmFTY3JpcHQgYWxsb3dlZCBmcm9tIGJvZHkgb25sb2FkIGF0dHJp YnV0ZVwiJz4iCisgICAgICAgICIgIDxwPk5vIEphdmFTY3JpcHQgbWFya3VwIHNob3VsZCBiZSBh bGxvd2VkPC9wPiIKKyAgICAgICAgIiAgPHNjcmlwdD5kb2N1bWVudC50aXRsZSA9ICdKYXZhU2Ny aXB0IGFsbG93ZWQgZnJvbSBib2R5IHNjcmlwdCc8L3NjcmlwdD4iCisgICAgICAgICIgPC9ib2R5 PiIKKyAgICAgICAgIjwvaHRtbD4iOworICAgIHRlc3QtPmxvYWRIdG1sKGh0bWwsIG51bGxwdHIp OworICAgIHRlc3QtPndhaXRVbnRpbExvYWRGaW5pc2hlZCgpOworCisgICAgZ19hc3NlcnRfY21w c3RyKHdlYmtpdF93ZWJfdmlld19nZXRfdGl0bGUodGVzdC0+bV93ZWJWaWV3KSwgPT0sICJObyBK YXZhU2NyaXB0IGFsbG93ZWQiKTsKKyAgICBhdXRvKiBqc1Jlc3VsdCA9IHRlc3QtPnJ1bkphdmFT Y3JpcHRBbmRXYWl0VW50aWxGaW5pc2hlZCgiZG9jdW1lbnQuZ2V0RWxlbWVudHNCeVRhZ05hbWUo J3NjcmlwdCcpLmxlbmd0aCIsIG51bGxwdHIpOworICAgIGdfYXNzZXJ0KGpzUmVzdWx0KTsKKyAg ICBnX2Fzc2VydF9jbXBmbG9hdChXZWJWaWV3VGVzdDo6amF2YXNjcmlwdFJlc3VsdFRvTnVtYmVy KGpzUmVzdWx0KSwgPT0sIDApOworCisgICAgd2Via2l0X3NldHRpbmdzX3NldF9lbmFibGVfamF2 YXNjcmlwdF9tYXJrdXAod2Via2l0X3dlYl92aWV3X2dldF9zZXR0aW5ncyh0ZXN0LT5tX3dlYlZp ZXcpLCBUUlVFKTsKK30KKwogc3RhdGljIHZvaWQgc2VydmVyQ2FsbGJhY2soU291cFNlcnZlciog c2VydmVyLCBTb3VwTWVzc2FnZSogbWVzc2FnZSwgY29uc3QgY2hhciogcGF0aCwgR0hhc2hUYWJs ZSosIFNvdXBDbGllbnRDb250ZXh0KiwgZ3BvaW50ZXIpCiB7CiAgICAgaWYgKG1lc3NhZ2UtPm1l dGhvZCAhPSBTT1VQX01FVEhPRF9HRVQpIHsKQEAgLTQ0Niw2ICs0NzYsNyBAQCB2b2lkIGJlZm9y ZUFsbCgpCiAjaWYgUExBVEZPUk0oR1RLKQogICAgIFdlYlZpZXdUZXN0OjphZGQoIldlYktpdFNl dHRpbmdzIiwgInVzZXItYWdlbnQiLCB0ZXN0V2ViS2l0U2V0dGluZ3NVc2VyQWdlbnQpOwogI2Vu ZGlmCisgICAgV2ViVmlld1Rlc3Q6OmFkZCgiV2ViS2l0U2V0dGluZ3MiLCAiamF2YXNjcmlwdC1t YXJrdXAiLCB0ZXN0V2ViS2l0U2V0dGluZ3NKYXZhU2NyaXB0TWFya3VwKTsKIH0KIAogdm9pZCBh ZnRlckFsbCgpCg==