107613 2013-01-22 19:11:33 -0800 Assert that computePreferredLogicalWidths never calls setNeedsLayout 2016-06-27 03:22:48 -0700 1 1 1 Unclassified WebKit New Bugs 528+ (Nightly build) Unspecified Unspecified RESOLVED FIXED P2 Normal --- 107913 108057 153991 1 ojan ojan alex davidc dbarton eric fred.wang hyatt jchaffraix leviw ojan.autocc simon.fraser tony webkit.review.bot oldest_to_newest 813680 0 ojan 2013-01-22 19:11:33 -0800 Assert that computePreferredLogicalWidths never calls setNeedsLayout 813681 1 184106 ojan 2013-01-22 19:18:38 -0800 Created attachment 184106 Patch 813845 2 184106 eric 2013-01-22 22:31:18 -0800 Comment on attachment 184106 Patch Odd that this is a RenderBox method. I had assumed the perferred widths where something from RenderObject. 813846 3 eric 2013-01-22 22:32:11 -0800 Eventually I think the MathML will end up with a separate (opaque) rendering tree, similar to how SVG started. If MathML truly has a different layout model than HTML, then it will just need to have its own rendering tree and not depend on RenderBox. 814260 4 dbarton 2013-01-23 09:33:26 -0800 (In reply to comment #3) > Eventually I think the MathML will end up with a separate (opaque) rendering tree, similar to how SVG started. If MathML truly has a different layout model than HTML, then it will just need to have its own rendering tree and not depend on RenderBox. I of course disagree completely with this patch, and even more with this comment. I just want to register my opinion here, for anyone who might work on improving MathML's rendering in the future. 814309 5 ojan 2013-01-23 10:16:08 -0800 (In reply to comment #2) > (From update of attachment 184106 [details]) > Odd that this is a RenderBox method. I had assumed the perferred widths where something from RenderObject. Nope. It's on RenderBox. FWIW, RenderText also has a method by the same name that takes arguments (e.g. leadWidth). (In reply to comment #4) > (In reply to comment #3) > > Eventually I think the MathML will end up with a separate (opaque) rendering tree, similar to how SVG started. If MathML truly has a different layout model than HTML, then it will just need to have its own rendering tree and not depend on RenderBox. > > I of course disagree completely with this patch, and even more with this comment. I just want to register my opinion here, for anyone who might work on improving MathML's rendering in the future. I don't see what's controversial in this patch. Even if we decide we want to keep the current mathml behavior, we would still want this assert for the rest of the code. The only thing that would change is that we'd replace the FIXMEs with explanatory comments. 814368 6 184106 webkit.review.bot 2013-01-23 10:56:25 -0800 Comment on attachment 184106 Patch Clearing flags on attachment: 184106 Committed r140554: <http://trac.webkit.org/changeset/140554> 814369 7 webkit.review.bot 2013-01-23 10:56:30 -0800 All reviewed patches have been landed. Closing bug. 814426 8 dbarton 2013-01-23 11:41:47 -0800 (In reply to comment #5) > I don't see what's controversial in this patch. Even if we decide we want to keep the current mathml behavior, we would still want this assert for the rest of the code. The only thing that would change is that we'd replace the FIXMEs with explanatory comments. I think I can state my position plainly. Standard mathematical convention (and common sense, frankly) say that large operators are wider than small ones. In general, an object's intrinsic width obviously can depend on its contents. For the simplest case, HTML declares block elements like <p> to be as wide as their parents, even if the paragraph is only a fraction of a line. This is counter-intuitive and surprises everyone at first, but is simple and workable. Shrink-to-fit elements like tables and inline-block need a more sophisticated measure of preferred widths, so one does calculations involving the preferred widths of sub-elements. This is more complicated but obviously can be made to work. In general, layout and preferred widths of complex objects can depend on the overall sizes, including heights, of sub-elements, not just their widths. This is more complicated, but can also be made to work. If there's really a problem in recursively calling layout to calculate these sizes, then separate routines will have to be written. However, it seems to me like this is exactly what LayoutStateDisabler is for, so I researched it and used it in MathML layout. You are not used to this complexity, so you'd like to outlaw it by fiat, and assert it never happens. My position is that if someone notices a bug it leads to, or gives some other concrete reason we shouldn't do it, then you are right. But I think you are now putting a higher priority on the possibility of bugs that haven't appeared (and may not exist), than on decent MathML layout in the future. I am a bit frustrated because I (and Alex M. before me) repeatedly asked for guidance on implementing MathML layout from rendering experts, and got very little. After not objecting at the time, you are now asserting that what I did is a bad thing, when I think it's a necessary small complication that has led to no problems. The main issue is that Alex M. followed virtually all mathematical layout engines before him and stretched operators by stitching together partial glyphs. The easiest way to do this was by mutating the render tree during layout. This has led to a bad bug. We could try to fix that bug, but expert judgment (yours, Julien's, etc.) is that there would probably be other bugs if we continue to mutate the render tree during layout, so it's better to just scale glyphs for now. I accept that judgment. I don't yet accept the claim that it's bad to layout subexpressions during layout (e.g. during computePreferredLogicalWidths). I call this bottom-up layout, as opposed to top-down layout, but see no reason it has to be bad. It is different, but it's used in virtually all other mathematical layout systems, so obviously it can work. I'm just asking for a bug it causes, or a definite reason it's bad, other than "that's not what we do now so it violates an invariant" before we start asserting it can't happen. If there's an assert in the code, people will think there's a reason and it's necessary to comply. I am registering my opinion that this is false. In summary, I think we both agree that you are saying the added complexity of having computePreferredLogicalWidths do what is needed for good MathML layout is not worth it. I think this is because you put very little value on good MathML layout, whereas I think hundreds of millions of users will need it (or switch). Also, I think you exaggerate the added complexity, because of a bug involving a different issue (mutating the render tree during layout). That was your original rationale for this change, until I pointed out that fixing it was independent of computePreferredLogicalWidths. 814598 9 davidc 2013-01-23 13:52:37 -0800 (In reply to comment #8) > I think I can state my position plainly. I'd also like to note on the record that this seems a very unfortunate stance to take. I'm not familiar with the webkit codebase but I have been involved with mathematical typesetting for 25 years and I was asked to review mathml related bugs as they were handled. It's been a pleasure to watch the webkit implementation mature over the last year and finally make it to a stable Chrome release. To see this effort so severely compromised with apparently no weight at all given to the most basic norms of mathematical layout so shortly after it has been released is a real disappointment. 816211 10 webkit.review.bot 2013-01-24 21:59:30 -0800 Re-opened since this is blocked by bug 107913 816699 11 leviw 2013-01-25 10:05:11 -0800 (In reply to comment #9) > (In reply to comment #8) > > > I think I can state my position plainly. > > I'd also like to note on the record that this seems a very unfortunate stance to take. > > I'm not familiar with the webkit codebase but I have been involved with mathematical typesetting for 25 years and I was asked to review mathml related bugs as they were handled. It's been a pleasure to watch the webkit implementation mature over the last year and finally make it to a stable Chrome release. To see this effort so severely compromised with apparently no weight at all given to the most basic norms of mathematical layout so shortly after it has been released is a real disappointment. Hi Dave and David, Just to try and explain, one of our highest priorities as a rendering engine is security, and these patches are intended to fix a known source of security issues. That MathML requires a layout paradigm that HTML/CSS does not is unfortunate, as in its current implementation, it's built on top of WebKit's HTML/CSS rendering primitives. Our goal is not to make MathML rendering worse, but to make everyone safe. The reason Chromium didn't have MathML turned on initially was that it had security issues. If we can't address them in a way we're comfortable with, we'll be left with the unfortunate option of turning it off again. I, personally, would very much rather that not happen. I appreciate your interest and passion in getting our renderings to be right. I, too, want us to get there. Hopefully we can find a way to address all of our concerns. 816835 12 dbarton 2013-01-25 12:17:15 -0800 Levi, thanks for the comment. But believe me, David C. and I are intimately aware of Google's excellent attitude toward security, and its role in deciding whether to ship MathML in Chrome. See bug 107353 comment 44. 817197 13 davidc 2013-01-26 08:06:30 -0800 (In reply to comment #11) > Hi Dave and David, > > Just to try and explain, one of our highest priorities as a rendering engine is security, and these patches are intended to fix a known source of security issues. As I (and Dave Barton) have consistently stated we both recognise that security is a prime concern. I have in fact defended Chrome on several occasions in the last year as end users complained that the MathML that was in webkit base and in Safari was not turned on in Chrome. If code does not pass your security review you have every right not to include it. That does not appear to be the case here. Dave Barton has repeatedly asked what bug or security failure this change is fixing and the answer appears to be that it is not fixing a bug. The only reasons given are that there is a code invariant that large characters should be the same width as small ones, and that the code would be simpler without the complication of dealing with character widths. This is like saying that you have a code invariant that text should be set left right and that not having the Unicode bidi algorithm would make things simpler. It probably would be simpler but that doesn't mean it should be removed. You don't have to review the code or the result to see that just common sense dictates that characters get wider as they get bigger. It's one thing to say that an implementation has not yet implemented mathematical layout, it is another to put in place asserts that say that mathematical layout is by design not possible. > That MathML requires a layout paradigm that HTML/CSS does not is unfortunate, as in its current implementation, it's built on top of WebKit's HTML/CSS rendering primitives. Our goal is not to make MathML rendering worse, but to make everyone safe. I can not comment on the code (that is not why I was asked to review every MathML component bug) but as I note above Dave Barton's repeated requests to be told what security failure this code triggers have gone un-answered. > > The reason Chromium didn't have MathML turned on initially was that it had security issues. If we can't address them in a way we're comfortable with, we'll be left with the unfortunate option of turning it off again. I, personally, would very much rather that not happen. Judging by discussion in this bug and in bug 107353 turning off won't be necessary. If you can't be convinced that the existing code is safe then the change suggested by Tony Chang in comment 35 would apparently get to the same end result (at some possible run time costs). Or, if it comes to it, I assume I have no right of veto here so you can just overrule comments that the patch is wrong and make the change anyway. Any of those outcomes would be better than removing support completely. > > I appreciate your interest and passion in getting our renderings to be right. I, too, want us to get there. Hopefully we can find a way to address all of our concerns. I'm sure we all agree with the aims of having a secure browser that does the right thing (and also in fact that having a secure browser that does the wrong thing is better than having an insecure browser.) 822127 14 ojan 2013-01-31 16:51:45 -0800 Trying again in bug 108539. 1174388 15 fred.wang 2016-03-14 03:47:02 -0700 I don't think the MathML code calls setNeedsLayout in computePreferredLogicalWidths anymore. However, I'm making this depends on bug 153991 since all the MathML layout functions will have been properly rewritten at that point. 1205510 16 fred.wang 2016-06-27 03:22:48 -0700 This was merged in r141517 and the hacks for MathML have been removed for a while. MathML's computePreferredLogicalWidths functions really only set m_minPreferredLogicalWidth and m_maxPreferredLogicalWidth and don't have any other side effect. So I'm closing this bug. 184106 2013-01-22 19:18:38 -0800 2013-01-23 10:56:25 -0800 Patch bug-107613-20130122191532.patch text/plain 6333 ojan U3VidmVyc2lvbiBSZXZpc2lvbjogMTQwNDg2CmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViQ29yZS9D aGFuZ2VMb2cgYi9Tb3VyY2UvV2ViQ29yZS9DaGFuZ2VMb2cKaW5kZXggZGE2NWQ3ZDY3YjFmMzIz ODVmODVmNjZjNzYzYTNjYzdjZDE2M2FhNS4uZjk1NmRmOWQ3ZGY1MTQ3NjBkZjhmMmFiY2Y2OTNm NDMyMGNkODUzYiAxMDA2NDQKLS0tIGEvU291cmNlL1dlYkNvcmUvQ2hhbmdlTG9nCisrKyBiL1Nv dXJjZS9XZWJDb3JlL0NoYW5nZUxvZwpAQCAtMSwzICsxLDI0IEBACisyMDEzLTAxLTIyICBPamFu IFZhZmFpICA8b2phbkBjaHJvbWl1bS5vcmc+CisKKyAgICAgICAgQXNzZXJ0IHRoYXQgY29tcHV0 ZVByZWZlcnJlZExvZ2ljYWxXaWR0aHMgbmV2ZXIgY2FsbHMgc2V0TmVlZHNMYXlvdXQKKyAgICAg ICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTEwNzYxMworCisgICAg ICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAgIGNvbXB1dGVQcmVmZXJy ZWRMb2dpY2FsV2lkdGhzIHNob3VsZCBvbmx5IHNldCBtX21pblByZWZlcnJlZExvZ2ljYWxXaWR0 aAorICAgICAgICBhbmQgbV9tYXhQcmVmZXJyZWRMb2dpY2FsV2lkdGguIEl0IHNob3VsZG4ndCBo YXZlIG90aGVyIHNpZGUtZWZmZWN0cy4KKyAgICAgICAgVGhlIG1hdGhtbCBiaXRzIGNhbiBiZSBy ZW1vdmVkIG9uY2UgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTEwNzM1 MworICAgICAgICBpcyByZXNvbHZlZC4KKworICAgICAgICAqIHJlbmRlcmluZy9SZW5kZXJCb3gu Y3BwOgorICAgICAgICAoV2ViQ29yZTo6UmVuZGVyQm94OjptaW5QcmVmZXJyZWRMb2dpY2FsV2lk dGgpOgorICAgICAgICAqIHJlbmRlcmluZy9tYXRobWwvUmVuZGVyTWF0aE1MT3BlcmF0b3IuY3Bw OgorICAgICAgICAoV2ViQ29yZTo6UmVuZGVyTWF0aE1MT3BlcmF0b3I6OmNvbXB1dGVQcmVmZXJy ZWRMb2dpY2FsV2lkdGhzKToKKyAgICAgICAgKiByZW5kZXJpbmcvbWF0aG1sL1JlbmRlck1hdGhN TFJvb3QuY3BwOgorICAgICAgICAoV2ViQ29yZTo6UmVuZGVyTWF0aE1MUm9vdDo6Y29tcHV0ZVBy ZWZlcnJlZExvZ2ljYWxXaWR0aHMpOgorICAgICAgICAqIHJlbmRlcmluZy9tYXRobWwvUmVuZGVy TWF0aE1MUm93LmNwcDoKKyAgICAgICAgKFdlYkNvcmU6OlJlbmRlck1hdGhNTFJvdzo6Y29tcHV0 ZVByZWZlcnJlZExvZ2ljYWxXaWR0aHMpOgorCiAyMDEzLTAxLTIyICBUb255IEdlbnRpbGNvcmUg IDx0b255Z0BjaHJvbWl1bS5vcmc+CiAKICAgICAgICAgRml4IGFzc2VydGlvbnMgaW4gbWFrZThC aXRGcm9tMTZCaXRTb3VyY2UoKSB3aXRoIHRocmVhZGVkIHBhcnNlcgpkaWZmIC0tZ2l0IGEvU291 cmNlL1dlYkNvcmUvcmVuZGVyaW5nL1JlbmRlckJveC5jcHAgYi9Tb3VyY2UvV2ViQ29yZS9yZW5k ZXJpbmcvUmVuZGVyQm94LmNwcAppbmRleCBjNGE5Y2U0MzBkODNjNWFjNjhjYWU3ODg0YTMyOWJl ZmZhYmE5NzI2Li40NDNkMjI0NjljMmYzOTU5ZGYzYWIzNWMxYWMxYzc2ZTI3NDNkNWRmIDEwMDY0 NAotLS0gYS9Tb3VyY2UvV2ViQ29yZS9yZW5kZXJpbmcvUmVuZGVyQm94LmNwcAorKysgYi9Tb3Vy Y2UvV2ViQ29yZS9yZW5kZXJpbmcvUmVuZGVyQm94LmNwcApAQCAtODQ5LDE2ICs4NDksMjQgQEAg dm9pZCBSZW5kZXJCb3g6OmNvbXB1dGVJbnRyaW5zaWNMb2dpY2FsV2lkdGhzKExheW91dFVuaXQm IG1pbkxvZ2ljYWxXaWR0aCwgTGF5b3UKIAogTGF5b3V0VW5pdCBSZW5kZXJCb3g6Om1pblByZWZl cnJlZExvZ2ljYWxXaWR0aCgpIGNvbnN0CiB7Ci0gICAgaWYgKHByZWZlcnJlZExvZ2ljYWxXaWR0 aHNEaXJ0eSgpKQorICAgIGlmIChwcmVmZXJyZWRMb2dpY2FsV2lkdGhzRGlydHkoKSkgeworI2lm bmRlZiBOREVCVUcKKyAgICAgICAgU2V0TGF5b3V0TmVlZGVkRm9yYmlkZGVuU2NvcGUgbGF5b3V0 Rm9yYmlkZGVuU2NvcGUoY29uc3RfY2FzdDxSZW5kZXJCb3gqPih0aGlzKSk7CisjZW5kaWYKICAg ICAgICAgY29uc3RfY2FzdDxSZW5kZXJCb3gqPih0aGlzKS0+Y29tcHV0ZVByZWZlcnJlZExvZ2lj YWxXaWR0aHMoKTsKKyAgICB9CiAgICAgICAgIAogICAgIHJldHVybiBtX21pblByZWZlcnJlZExv Z2ljYWxXaWR0aDsKIH0KIAogTGF5b3V0VW5pdCBSZW5kZXJCb3g6Om1heFByZWZlcnJlZExvZ2lj YWxXaWR0aCgpIGNvbnN0CiB7Ci0gICAgaWYgKHByZWZlcnJlZExvZ2ljYWxXaWR0aHNEaXJ0eSgp KQorICAgIGlmIChwcmVmZXJyZWRMb2dpY2FsV2lkdGhzRGlydHkoKSkgeworI2lmbmRlZiBOREVC VUcKKyAgICAgICAgU2V0TGF5b3V0TmVlZGVkRm9yYmlkZGVuU2NvcGUgbGF5b3V0Rm9yYmlkZGVu U2NvcGUoY29uc3RfY2FzdDxSZW5kZXJCb3gqPih0aGlzKSk7CisjZW5kaWYKICAgICAgICAgY29u c3RfY2FzdDxSZW5kZXJCb3gqPih0aGlzKS0+Y29tcHV0ZVByZWZlcnJlZExvZ2ljYWxXaWR0aHMo KTsKKyAgICB9CiAgICAgICAgIAogICAgIHJldHVybiBtX21heFByZWZlcnJlZExvZ2ljYWxXaWR0 aDsKIH0KZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJDb3JlL3JlbmRlcmluZy9tYXRobWwvUmVuZGVy TWF0aE1MT3BlcmF0b3IuY3BwIGIvU291cmNlL1dlYkNvcmUvcmVuZGVyaW5nL21hdGhtbC9SZW5k ZXJNYXRoTUxPcGVyYXRvci5jcHAKaW5kZXggYmFiM2E0ODcyMDg3OWRiZmY3MTRlYmMzZjc1OGJh NjI0NDViNDgwMC4uYzVlNmUzNjk0Y2ZkODliZDVlN2YwNGUyYjc1YzliZmRjZmU1NTY3YyAxMDA2 NDQKLS0tIGEvU291cmNlL1dlYkNvcmUvcmVuZGVyaW5nL21hdGhtbC9SZW5kZXJNYXRoTUxPcGVy YXRvci5jcHAKKysrIGIvU291cmNlL1dlYkNvcmUvcmVuZGVyaW5nL21hdGhtbC9SZW5kZXJNYXRo TUxPcGVyYXRvci5jcHAKQEAgLTgzLDExICs4MywyMSBAQCB2b2lkIFJlbmRlck1hdGhNTE9wZXJh dG9yOjpzdHlsZURpZENoYW5nZShTdHlsZURpZmZlcmVuY2UgZGlmZiwgY29uc3QgUmVuZGVyU3R5 bAogdm9pZCBSZW5kZXJNYXRoTUxPcGVyYXRvcjo6Y29tcHV0ZVByZWZlcnJlZExvZ2ljYWxXaWR0 aHMoKSAKIHsKICAgICBBU1NFUlQocHJlZmVycmVkTG9naWNhbFdpZHRoc0RpcnR5KCkpOworCisj aWZuZGVmIE5ERUJVRworICAgIC8vIEZJWE1FOiBSZW1vdmUgdGhlIHNldE5lZWRzTGF5b3V0SXNG b3JiaWRkZW4gY2FsbHMgb25jZSBtYXRobWwgc3RvcHMgbW9kaWZ5aW5nIHRoZSByZW5kZXIgdHJl ZSBoZXJlLgorICAgIGJvb2wgb2xkU2V0TmVlZHNMYXlvdXRJc0ZvcmJpZGRlbiA9IGlzU2V0TmVl ZHNMYXlvdXRGb3JiaWRkZW4oKTsKKyAgICBzZXROZWVkc0xheW91dElzRm9yYmlkZGVuKGZhbHNl KTsKKyNlbmRpZgogICAgIAogICAgIC8vIENoZWNrIGZvciBhbiB1bmluaXRpYWxpemVkIG9wZXJh dG9yLgogICAgIGlmICghZmlyc3RDaGlsZCgpKQogICAgICAgICB1cGRhdGVGcm9tRWxlbWVudCgp OwotICAgIAorCisjaWZuZGVmIE5ERUJVRworICAgIHNldE5lZWRzTGF5b3V0SXNGb3JiaWRkZW4o b2xkU2V0TmVlZHNMYXlvdXRJc0ZvcmJpZGRlbik7CisjZW5kaWYKKwogICAgIFJlbmRlck1hdGhN TEJsb2NrOjpjb21wdXRlUHJlZmVycmVkTG9naWNhbFdpZHRocygpOwogfQogCmRpZmYgLS1naXQg YS9Tb3VyY2UvV2ViQ29yZS9yZW5kZXJpbmcvbWF0aG1sL1JlbmRlck1hdGhNTFJvb3QuY3BwIGIv U291cmNlL1dlYkNvcmUvcmVuZGVyaW5nL21hdGhtbC9SZW5kZXJNYXRoTUxSb290LmNwcAppbmRl eCAzZmMxNzIzZDJlNjkwMmYxZDE5ZjQzNWU0MzNjNGE3MWUxZjFmZGRmLi4xN2ZhMjNlOWE2ZDcw ZTY2YjU2MTRhNDgxNzU1NTFjMTU1Njc4ZWUxIDEwMDY0NAotLS0gYS9Tb3VyY2UvV2ViQ29yZS9y ZW5kZXJpbmcvbWF0aG1sL1JlbmRlck1hdGhNTFJvb3QuY3BwCisrKyBiL1NvdXJjZS9XZWJDb3Jl L3JlbmRlcmluZy9tYXRobWwvUmVuZGVyTWF0aE1MUm9vdC5jcHAKQEAgLTE4Nyw2ICsxODcsMTIg QEAgdm9pZCBSZW5kZXJNYXRoTUxSb290Ojpjb21wdXRlUHJlZmVycmVkTG9naWNhbFdpZHRocygp CiB7CiAgICAgQVNTRVJUKHByZWZlcnJlZExvZ2ljYWxXaWR0aHNEaXJ0eSgpICYmIG5lZWRzTGF5 b3V0KCkpOwogICAgIAorI2lmbmRlZiBOREVCVUcKKyAgICAvLyBGSVhNRTogUmVtb3ZlIHRoZSBz ZXROZWVkc0xheW91dElzRm9yYmlkZGVuIGNhbGxzIG9uY2UgbWF0aG1sIHN0b3BzIG1vZGlmeWlu ZyB0aGUgcmVuZGVyIHRyZWUgaGVyZS4KKyAgICBib29sIG9sZFNldE5lZWRzTGF5b3V0SXNGb3Ji aWRkZW4gPSBpc1NldE5lZWRzTGF5b3V0Rm9yYmlkZGVuKCk7CisgICAgc2V0TmVlZHNMYXlvdXRJ c0ZvcmJpZGRlbihmYWxzZSk7CisjZW5kaWYKKyAgICAKICAgICBjb21wdXRlQ2hpbGRyZW5QcmVm ZXJyZWRMb2dpY2FsSGVpZ2h0cygpOwogICAgIAogICAgIGludCBiYXNlSGVpZ2h0ID0gZmlyc3RD aGlsZCgpID8gcm91bmRUb0ludChwcmVmZXJyZWRMb2dpY2FsSGVpZ2h0QWZ0ZXJTaXppbmcoZmly c3RDaGlsZCgpKSkgOiBzdHlsZSgpLT5mb250U2l6ZSgpOwpAQCAtMjE5LDcgKzIyNSwxMSBAQCB2 b2lkIFJlbmRlck1hdGhNTFJvb3Q6OmNvbXB1dGVQcmVmZXJyZWRMb2dpY2FsV2lkdGhzKCkKICAg ICAgICAgICAgIG1faW5kZXhUb3AgPSAtIHJvb3RFeHRyYVRvcDsKICAgICB9IGVsc2UKICAgICAg ICAgbV9pbnRyaW5zaWNQYWRkaW5nU3RhcnQgPSBmcm9udFdpZHRoOwotICAgIAorCisjaWZuZGVm IE5ERUJVRworICAgIHNldE5lZWRzTGF5b3V0SXNGb3JiaWRkZW4ob2xkU2V0TmVlZHNMYXlvdXRJ c0ZvcmJpZGRlbik7CisjZW5kaWYKKwogICAgIFJlbmRlck1hdGhNTEJsb2NrOjpjb21wdXRlUHJl ZmVycmVkTG9naWNhbFdpZHRocygpOwogICAgIAogICAgIC8vIFNocmluayBvdXIgbG9naWNhbCB3 aWR0aCB0byBpdHMgcHJvYmFibGUgdmFsdWUgbm93IHdpdGhvdXQgdHJpZ2dlcmluZyB1bm5lY2Vz c2FyeSByZWxheW91dCBvZiBvdXIgY2hpbGRyZW4uCmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViQ29y ZS9yZW5kZXJpbmcvbWF0aG1sL1JlbmRlck1hdGhNTFJvdy5jcHAgYi9Tb3VyY2UvV2ViQ29yZS9y ZW5kZXJpbmcvbWF0aG1sL1JlbmRlck1hdGhNTFJvdy5jcHAKaW5kZXggYTE0MzhhNGZjNmM5ZTc0 YmQ1YzM1ODRmZjQyMDYwYjdlYjg2Y2ZlOC4uZDc0NzM1OTQ1NTAxMjIxMjdiOTZjYWUzYjI3Mzk5 ZjQ5NzkzYjc3OSAxMDA2NDQKLS0tIGEvU291cmNlL1dlYkNvcmUvcmVuZGVyaW5nL21hdGhtbC9S ZW5kZXJNYXRoTUxSb3cuY3BwCisrKyBiL1NvdXJjZS9XZWJDb3JlL3JlbmRlcmluZy9tYXRobWwv UmVuZGVyTWF0aE1MUm93LmNwcApAQCAtNTQsNyArNTQsMTMgQEAgUmVuZGVyTWF0aE1MUm93KiBS ZW5kZXJNYXRoTUxSb3c6OmNyZWF0ZUFub255bW91c1dpdGhQYXJlbnRSZW5kZXJlcihjb25zdCBS ZW5kZXIKIHZvaWQgUmVuZGVyTWF0aE1MUm93Ojpjb21wdXRlUHJlZmVycmVkTG9naWNhbFdpZHRo cygpCiB7CiAgICAgQVNTRVJUKHByZWZlcnJlZExvZ2ljYWxXaWR0aHNEaXJ0eSgpICYmIG5lZWRz TGF5b3V0KCkpOwotICAgIAorCisjaWZuZGVmIE5ERUJVRworICAgIC8vIEZJWE1FOiBSZW1vdmUg dGhlIHNldE5lZWRzTGF5b3V0SXNGb3JiaWRkZW4gY2FsbHMgb25jZSBtYXRobWwgc3RvcHMgbW9k aWZ5aW5nIHRoZSByZW5kZXIgdHJlZSBoZXJlLgorICAgIGJvb2wgb2xkU2V0TmVlZHNMYXlvdXRJ c0ZvcmJpZGRlbiA9IGlzU2V0TmVlZHNMYXlvdXRGb3JiaWRkZW4oKTsKKyAgICBzZXROZWVkc0xh eW91dElzRm9yYmlkZGVuKGZhbHNlKTsKKyNlbmRpZgorCiAgICAgY29tcHV0ZUNoaWxkcmVuUHJl ZmVycmVkTG9naWNhbEhlaWdodHMoKTsKICAgICBpbnQgc3RyZXRjaExvZ2ljYWxIZWlnaHQgPSAw OwogICAgIGZvciAoUmVuZGVyT2JqZWN0KiBjaGlsZCA9IGZpcnN0Q2hpbGQoKTsgY2hpbGQ7IGNo aWxkID0gY2hpbGQtPm5leHRTaWJsaW5nKCkpIHsKQEAgLTc3LDcgKzgzLDExIEBAIHZvaWQgUmVu ZGVyTWF0aE1MUm93Ojpjb21wdXRlUHJlZmVycmVkTG9naWNhbFdpZHRocygpCiAgICAgICAgICAg ICAgICAgcmVuZGVyTW8tPnN0cmV0Y2hUb0hlaWdodChzdHJldGNoTG9naWNhbEhlaWdodCk7CiAg ICAgICAgIH0KICAgICB9Ci0gICAgCisKKyNpZm5kZWYgTkRFQlVHCisgICAgc2V0TmVlZHNMYXlv dXRJc0ZvcmJpZGRlbihvbGRTZXROZWVkc0xheW91dElzRm9yYmlkZGVuKTsKKyNlbmRpZgorCiAg ICAgUmVuZGVyTWF0aE1MQmxvY2s6OmNvbXB1dGVQcmVmZXJyZWRMb2dpY2FsV2lkdGhzKCk7CiAg ICAgCiAgICAgLy8gU2hyaW5rIG91ciBsb2dpY2FsIHdpZHRoIHRvIGl0cyBwcm9iYWJsZSB2YWx1 ZSBub3cgd2l0aG91dCB0cmlnZ2VyaW5nIHVubmVjZXNzYXJ5IHJlbGF5b3V0IG9mIG91ciBjaGls ZHJlbi4K