28350 2009-08-15 20:31:58 -0700 REGRESSION (r47255): MediaWiki's (including Wikipedia) navigation pane appears below the main content 2024-05-22 14:30:24 -0700 1 1 1 Unclassified WebKit Evangelism 528+ (Nightly build) All All RESOLVED FIXED https://bugs.webkit.org/show_bug.cgi?id=195597 InRadar, Regression P1 Critical --- 1 rniwa webkit-unassigned ayg darin dglazkov ggaren hyatt jon mitz muellerp.bugzilla pkasting simon.bugzilla simon.fraser thakis oldest_to_newest 140520 0 rniwa 2009-08-15 20:31:58 -0700 Use the nightly build (27291) and go visit http://en.wikipedia.org/wiki/Main_Page navigation, search, and all other contents on the left-pane shows up below the main content. 140521 1 simon.fraser 2009-08-15 20:44:25 -0700 Maybe caused by http://trac.webkit.org/changeset/47255 ? We don't have a regression window yet. 140522 2 simon.fraser 2009-08-15 20:47:44 -0700 Yeah, reverting 47255 fixes it. 140523 3 mitz 2009-08-15 20:59:13 -0700 Changing the page’s DOCTYPE to <!DOCTYPE html> causes the layout to break even without r47255. 140526 4 34916 mitz 2009-08-15 21:31:58 -0700 Created attachment 34916 Reduction 140530 5 34918 mitz 2009-08-15 21:46:34 -0700 Created attachment 34918 Extended test case Firefox behavior is rather strange: in cases A and B, the overflow section (blue) clears the float (yellow), but in case C it does not. Note that the only difference between case B and case C is that the container has a top border. 140532 6 mitz 2009-08-15 22:24:14 -0700 The layout difference between WebKit and Gecko is caused by <http://en.wikipedia.org/skins-1.5/monobook/KHTMLFixes.css>, which is loaded dynamically based on UA sniffing via JavaScript. The only rule in that style sheet is: /* work around the horizontal scrollbars */ #column-content { margin-left: 0; } which overrides the margin specific in main.css: margin: 0 0 .6em -12.2em; Using the Web Inspector to disable the 'margin-left: 0;' rule fixes the layout and does not cause a horizontal scroll bar to appear. 140534 7 mitz 2009-08-15 22:28:40 -0700 <rdar://problem/7145895> 140535 8 rniwa 2009-08-15 22:30:03 -0700 (In reply to comment #6) > The layout difference between WebKit and Gecko is caused by > <http://en.wikipedia.org/skins-1.5/monobook/KHTMLFixes.css>, which is loaded > dynamically based on UA sniffing via JavaScript. The only rule in that style > sheet is: > > /* work around the horizontal scrollbars */ > #column-content { margin-left: 0; } > > which overrides the margin specific in main.css: > > margin: 0 0 .6em -12.2em; > > Using the Web Inspector to disable the 'margin-left: 0;' rule fixes the layout > and does not cause a horizontal scroll bar to appear. Is that work around still required for the latest WebKit? i.e. will horizontal scrollbars appear without it? If not, we can ask people in wikipedia to disable that rule for the latest webkit. 140536 9 mitz 2009-08-15 22:31:15 -0700 > > Using the Web Inspector to disable the 'margin-left: 0;' rule fixes the layout > > and does not cause a horizontal scroll bar to appear. > > Is that work around still required for the latest WebKit? i.e. will horizontal > scrollbars appear without it? No. Like I said, disabling the rule does not cause a horizontal scroll bar to appear. > If not, we can ask people in wikipedia to > disable that rule for the latest webkit. I have moved the bug to the Evangelism component. 140538 10 rniwa 2009-08-15 22:35:17 -0700 (In reply to comment #9) > No. Like I said, disabling the rule does not cause a horizontal scroll bar to > appear. I see. It seems like we should contact wikipedia then. 140540 11 rniwa 2009-08-15 22:49:04 -0700 (In reply to comment #10) > (In reply to comment #9) > > No. Like I said, disabling the rule does not cause a horizontal scroll bar to > > appear. > > I see. It seems like we should contact wikipedia then. Maybe we should bring it up at http://en.wikipedia.org/wiki/Wikipedia:Help_desk 140544 12 rniwa 2009-08-16 00:53:53 -0700 Ugh... I just noticed that this bug reproduces on other MediaWiki as well. We can't really force every site using MediaWiki to change their script. e.g. http://www.mediawiki.org/wiki/MediaWiki I guess we need to preserve the old behavior or add work around for MediaWiki. But meanwhile, we should tell MediaWiki folks to modify the script so that it won't apply that style rule for the new versions of WebKit. 140545 13 34922 mitz 2009-08-16 02:02:12 -0700 Created attachment 34922 Proposed site-specific hack The scope of this hack can be narrowed further by adding path components before /KHTMLFixes.css or widened by not requiring an exact string match. An alternative hack would be to bypass the UA detection, but I think would be more risky. 140565 14 dglazkov 2009-08-16 09:55:28 -0700 It's curious that Firefox does something completely different for the first Reduction: blue just overlaps yellow and stays side-by-side. What the heck is the "right" way here? 140566 15 dglazkov 2009-08-16 09:59:16 -0700 Extended test case appears to look the same pre-r47255 and post. 140567 16 mitz 2009-08-16 10:00:15 -0700 (In reply to comment #15) > Extended test case appears to look the same pre-r47255 and post. Because it has <!DOCTYPE html>. Without it, it looks different in WebKit. Anyway, both test cases are pretty much irrelevant to this bug. 140569 17 hyatt 2009-08-16 10:10:47 -0700 I'm confused... Wikipedia isn't in strict mode is it? It looks like it's in "almost strict" mode, so isn't the strict mode issue relevant to this? 140571 18 mitz 2009-08-16 10:14:19 -0700 (In reply to comment #17) > I'm confused... Wikipedia isn't in strict mode is it? It looks like it's in > "almost strict" mode, so isn't the strict mode issue relevant to this? <http://trac.webkit.org/changeset/47255> dropped unified float clearing behavior across modes since neither Firefox nor IE8 have the quirk WebKit used to have. 140574 19 rniwa 2009-08-16 10:33:53 -0700 (In reply to comment #5) > Created an attachment (id=34918) [details] > Extended test case > > Firefox behavior is rather strange: in cases A and B, the overflow section > (blue) clears the float (yellow), but in case C it does not. Note that the only > difference between case B and case C is that the container has a top border. The rendering of this on WebKit and MSIE8 are identical. 140576 20 rniwa 2009-08-16 10:36:07 -0700 (In reply to comment #5) > Created an attachment (id=34918) [details] > Extended test case > > Firefox behavior is rather strange: in cases A and B, the overflow section > (blue) clears the float (yellow), but in case C it does not. Note that the only > difference between case B and case C is that the container has a top border. On MSIE8, width of the outer box is ignored. Yellow box appears on the right of screen, and blue box appears on the left with the same y. 140578 21 34922 darin 2009-08-16 10:45:42 -0700 Comment on attachment 34922 Proposed site-specific hack r=me 140579 22 darin 2009-08-16 10:50:14 -0700 I marked this as reviewed, because I think it's a great thing to do. We don't need a KHTML-specific style sheet that's working around a bug we no longer have. Hyatt and other experts may wish to continue to debate other aspects of this, but it seems clear cut that we don't need this style rule. 140583 23 hyatt 2009-08-16 12:04:21 -0700 I'm not a fan of this hack though. What incentive does Wikipedia have to fix the issue if we work around it like this? I am worried this hack will just stay in the code forever. 140584 24 mitz 2009-08-16 12:11:34 -0700 (In reply to comment #23) > I'm not a fan of this hack though. What incentive does Wikipedia have to fix > the issue if we work around it like this? I am worried this hack will just > stay in the code forever. Yeah, that’s why I originally made this an evangelism bug. However, the problem here is that the buggy code is replicated in many websites that use the MediaWiki system, so this is more like the kind of workarounds we have for 3rd-party apps than a site-specific hack. Maybe the right thing to do is wait for Wikipedia to respond and if they do, re-evaluate the necessity of the hack. 140585 25 hyatt 2009-08-16 12:12:11 -0700 I guess I'm just questioning what our site-specific-hack policy is. Do we have to immediately put the site-specific hack into the code, or can we give evangelism some time to work first? 140586 26 hyatt 2009-08-16 12:13:49 -0700 I guess I don't mind this landing as long as we have a bug open and continue to evangelize, but you have a bigger stick to bargain with when you can actually say "This is broken now. Please fix." If you approach Wikipedia with "Well this would be broken, but we worked around it, so you can work across old and new versions of WebKit without doing anything," then they have no incentive to change. 140593 27 dglazkov 2009-08-16 13:09:14 -0700 I can get WebKit evangelism folks at Google chip in with the effort as well. 140594 28 rniwa 2009-08-16 13:24:46 -0700 (In reply to comment #26) > I guess I don't mind this landing as long as we have a bug open and continue to > evangelize, but you have a bigger stick to bargain with when you can actually > say "This is broken now. Please fix." > > If you approach Wikipedia with "Well this would be broken, but we worked around > it, so you can work across old and new versions of WebKit without doing > anything," then they have no incentive to change. I agree. It's probably better for us to contact MediaWiki / Wikipedia before we add this work around. 140605 29 pkasting 2009-08-16 15:14:21 -0700 (In reply to comment #25) > I guess I'm just questioning what our site-specific-hack policy is. Do we have > to immediately put the site-specific hack into the code, or can we give > evangelism some time to work first? When this kind of issue came up for Google Chrome, I proposed that we have a policy of not doing site-specific hacks until we had contacted the site author(s) and obtained an agreement from them to fix their site. At that point we could check in a temporary hack if fixing things was going to take time. I'm not sure we made this our official policy but it got general agreement from those to whom I proposed it. We used this pattern when dealing with a Hotmail problem (see http://googlechromereleases.blogspot.com/2009/01/stable-beta-update-yahoo-mail-and.html ). 140619 30 hartman.wiki 2009-08-16 16:01:00 -0700 This KHTML specific line for mediawiki is already removed upstream, but it will take a LONG while before all the mediawiki installations are going to be updated. As noted, not even Wikipedia itself has this deployed yet at this time. See: "* Remove five-year-old KHTMLFixes.css, which is unlikely to be relevant anymore and was causing problems." in http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/RELEASE-NOTES?revision=55124&view=markup 140621 31 hartman.wiki 2009-08-16 16:04:57 -0700 specific revision: http://svn.wikimedia.org/viewvc/mediawiki?view=rev&revision=53141 140622 32 dglazkov 2009-08-16 16:14:23 -0700 (In reply to comment #30) > This KHTML specific line for mediawiki is already removed upstream, but it will > take a LONG while before all the mediawiki installations are going to be > updated. As noted, not even Wikipedia itself has this deployed yet at this > time. > > See: "* Remove five-year-old KHTMLFixes.css, which is unlikely to be relevant > anymore and was causing problems." > > in > http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/RELEASE-NOTES?revision=55124&view=markup This is precisely the gist of the issue. We're not dealing with one site, but a widely used software. This hack has also been duplicated verbatim on many derivative projects, such as GForge and SpringWiki, which makes evangelism effort a bit daunting. The site-specific hack patch looks pretty good to me atm. 140623 33 ayg 2009-08-16 16:24:42 -0700 This was due to ludicrously broken UA-sniffing on our part; sorry about that. For those who didn't catch it, in May 2004 someone committed a workaround to MediaWiki for a KHTML bug. Unfortunately, rather than using version-based sniffing, he just assumed all KHTML versions would have the bug forever -- KHTML was rather minor back then and it probably didn't seem important. So we ended up serving the fix to WebKit well over five years later. It came to light when I was trying out a switch to HTML 5, and the strict doctype caused incorrect display in WebKit. When I figured out the problem I removed the check in r53141, which Derk-Jan linked to. The fix will be in MediaWiki 1.16 and should go live on Wikipedia within a few weeks, but you're going to have to handle it for other MediaWiki installs for years, sadly. 140718 34 ayg 2009-08-17 08:33:36 -0700 I got hold of the appropriate people just now, and Wikipedia is no longer serving the broken CSS: http://en.wikipedia.org/skins-1.5/monobook/KHTMLFixes.css The fix should also be in MediaWiki 1.16. That should theoretically be released in a month, but might take longer. Needless to say, though, there are a *lot* of MediaWiki installs out there that don't keep up with updates. If you guys aren't willing to keep a site-specific hack in WebKit for a while, we could *maybe* backport the fix to old versions -- normally we only backport security fixes -- but we can't make people upgrade. The breakage is pretty ugly, with all content shoved down a large amount. For future reference, the best place to reach us is wikitech-l: <https://lists.wikimedia.org/mailman/listinfo/wikitech-l>. Anything posted there will be read by most Wikimedia sysadmins and MediaWiki developers. For real-time response, you can also go to #mediawiki (for MediaWiki) or #wikimedia-tech (for Wikimedia site administration) on freenode, but of course you'll reach fewer people that way. Sorry about the problems we've caused. Please let us know about any future difficulties. I've posted on wikitech-l to remind people to be careful about browser sniffing in the future: http://lists.wikimedia.org/pipermail/wikitech-l/2009-August/044767.html 140733 35 pkasting 2009-08-17 09:48:23 -0700 (In reply to comment #34) > Needless to say, though, there are a *lot* of MediaWiki installs out there that > don't keep up with updates. My question would be whether these sites are high-profile enough that we should check in a site-specific hack for them, and whether not checking in would make it more likely that the site authors would update sooner. To put it differently, if we do land this hack, what are the criteria we'll use to decide when to revert it, and how will we remember to check on them? 140744 36 dglazkov 2009-08-17 10:21:19 -0700 We chatted some more on #webkit and I believe the general consensus is that we don't to land this patch. Wikipedia is now serving the hack-free theme, which should serve as the right motivator for others to catch up. 140745 37 ayg 2009-08-17 10:22:53 -0700 The largest single user of MediaWiki other than Wikimedia is wikia.com, most likely. Some other large wikis are listed here: http://s23.org/wikistats/largest_html.php The problem is more lots of little sites than a few big ones, I'd think. MediaWiki is probably the most popular wiki software out there even if you don't count Wikipedia. For instance, my mother is an art historian and has sometimes used a wiki meant to track university job openings in 19th century art history, which runs MediaWiki. She was using Chrome for a while and would undoubtedly summon me and ask for an explanation if it randomly broke. There are zillions of little sites like that. I don't what your/WebKit's attitude is on maintaining compatibility vs. cleaning out cruft, so I can't say what you should do. Not having a fix in place for, say, the next couple of years would certainly break a lot of sites, that's all I can say. We don't have a very good upgrade rate; there are still a remarkable number of sites running three-year-old copies of MediaWiki. 140804 38 rniwa 2009-08-17 13:11:07 -0700 (In reply to comment #36) > We chatted some more on #webkit and I believe the general consensus is that we > don't to land this patch. Wikipedia is now serving the hack-free theme, which > should serve as the right motivator for others to catch up. We should publicize that version 1.16 or later is required. Or otherwise people think it's WebKit/Safari/Chrome's fault and we obviously don't want that. 140809 39 mitz 2009-08-17 13:21:32 -0700 Fixed in <http://trac.webkit.org/projects/webkit/changeset/47383>. 141677 40 ap 2009-08-19 18:04:39 -0700 *** Bug 28372 has been marked as a duplicate of this bug. *** 147000 41 mitz 2009-09-13 15:23:47 -0700 The workaround doesn’t apply to yet older versions of MediaWiki (see <http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/skins/monobook/KHTMLFixes.css?view=log&pathrev=53140>) because: 1) The stylesheet has only one instead of two trailing newlines and 2) The stylesheet is loaded from a <link> element rather than an @import rule 147053 42 darin 2009-09-14 07:46:45 -0700 Are there some sites that still have that older version of MediaWiki running? Clearly it will be straightforward to broaden the workaround to cover the other cases if there is a significant benefit to doing so and at least one site to test with. 147065 43 ayg 2009-09-14 09:03:24 -0700 Yes, it should be basically any MediaWiki site other than Wikipedia, due to the <link> issue. The change from @import to <link> only occurred in <http://www.mediawiki.org/wiki/Special:Code/MediaWiki/52886>, which is after the last stable release (1.15). So look at almost any non-Wikimedia, non-Wikia wiki that uses the default MonoBook skin, e.g., http://wikileaks.org/. Wikileaks makes some effort to hide their version, but it looks like it's based off 1.10, so they should exhibit both problems (extra newline for <= 1.11, and <link> for <= 1.15). I can confirm the problem is visible there. For that matter, you could also check almost any wiki from this list that's not a Wikimedia or Wikia project: http://s23.org/wikistats/largest_html.php?th=999&lines=999 148031 44 mitz 2009-09-18 00:55:21 -0700 (In reply to comment #42) > Are there some sites that still have that older version of MediaWiki running? > Clearly it will be straightforward to broaden the workaround to cover the other > cases if there is a significant benefit to doing so and at least one site to > test with. <http://wikileaks.org/> is one such site. 150444 45 mitz 2009-09-27 19:05:44 -0700 Filed bug 29792. 615128 46 rniwa 2012-05-03 03:09:06 -0700 Unfortunately, 47 out of 200 top WikiMedia users are still using the version 1.5 or older according to http://s23.org/wikistats/largest_html.php. It appears that we'll need to wait for another couple of years before we can remove this work around. 1504250 47 ggaren 2019-02-08 12:41:58 -0800 Maybe try again now? 1515203 48 rniwa 2019-03-11 19:32:51 -0700 (In reply to Geoffrey Garen from comment #47) > Maybe try again now? It looks like Chromium has removed this code in 2013: https://github.com/chromium/chromium/commit/ecf84fc9c1a51c8ede7adfd0b0cba446d9a8caa0 Only one year after I had commented above. 1515207 49 rniwa 2019-03-11 19:38:01 -0700 Tracking the removal in https://bugs.webkit.org/show_bug.cgi?id=195597. 2037143 50 frances_c 2024-05-22 14:30:24 -0700 *** Bug 21434 has been marked as a duplicate of this bug. *** 34916 2009-08-15 21:31:58 -0700 2009-08-15 22:14:52 -0700 Reduction 28350 reduction.html text/html 311 mitz PGJvZHkgc3R5bGU9IndpZHRoOiAyMDBweDsiPgogICAgPGRpdiBzdHlsZT0iCiAgICAgICAgZmxv YXQ6IHJpZ2h0OwogICAgICAgIHdpZHRoOiAxNTBweDsKICAgICAgICBoZWlnaHQ6IDIwMHB4Owog ICAgICAgIGJhY2tncm91bmQtY29sb3I6IHllbGxvdzsKICAgICI+CiAgICA8L2Rpdj4KICAgIDxk aXYgc3R5bGU9IgogICAgICAgIG92ZXJmbG93OiBoaWRkZW47CiAgICAgICAgaGVpZ2h0OiAxMDBw eDsKICAgICAgICB3aWR0aDogMTAwcHg7CiAgICAgICAgYmFja2dyb3VuZC1jb2xvcjogYmx1ZTsK ICAgICI+CiAgICA8L2Rpdj4KPC9ib2R5Pgo= 34918 2009-08-15 21:46:34 -0700 2009-08-15 22:14:59 -0700 Extended test case 28350 reduction.html text/html 773 mitz PCFET0NUWVBFIEhUTUw+CjxzdHlsZT4KICAgIC5jb250YWluZXIgewogICAgICAgIHdpZHRoOiAx NTBweDsKICAgICAgICBoZWlnaHQ6IDIyNXB4OwogICAgICAgIG1hcmdpbi1ib3R0b206IDI1cHg7 CiAgICAgICAgYmFja2dyb3VuZC1jb2xvcjogYWxpY2VibHVlOwogICAgfQoKICAgIC5mbG9hdCB7 CiAgICAgICAgZmxvYXQ6IHJpZ2h0OwogICAgICAgIHdpZHRoOiAxMDBweDsKICAgICAgICBoZWln aHQ6IDEwMHB4OwogICAgICAgIGJhY2tncm91bmQtY29sb3I6IHllbGxvdzsKICAgIH0KCiAgICAu b3ZlcmZsb3cgewogICAgICAgIG92ZXJmbG93OiBoaWRkZW47CiAgICAgICAgaGVpZ2h0OiAxMDBw eDsKICAgICAgICB3aWR0aDogMTAwcHg7CiAgICAgICAgYmFja2dyb3VuZC1jb2xvcjogYmx1ZTsK ICAgIH0KPC9zdHlsZT4KCkE6CjxkaXYgY2xhc3M9ImNvbnRhaW5lciI+CiAgICA8ZGl2IGNsYXNz PSJmbG9hdCI+CiAgICA8L2Rpdj4KICAgIGZvbwogICAgPGRpdiBjbGFzcz0ib3ZlcmZsb3ciPgog ICAgPC9kaXY+CjwvZGl2PgoKQjoKPGRpdiBjbGFzcz0iY29udGFpbmVyIiBzdHlsZT0iYm9yZGVy LXRvcDogc29saWQ7Ij4KICAgIDxkaXYgY2xhc3M9ImZsb2F0Ij4KICAgIDwvZGl2PgogICAgPGRp diBjbGFzcz0ib3ZlcmZsb3ciPgogICAgPC9kaXY+CjwvZGl2PgoKQzoKPGRpdiBjbGFzcz0iY29u dGFpbmVyIj4KICAgIDxkaXYgY2xhc3M9ImZsb2F0Ij4KICAgIDwvZGl2PgogICAgPGRpdiBjbGFz cz0ib3ZlcmZsb3ciPgogICAgPC9kaXY+CjwvZGl2Pgo= 34922 2009-08-16 02:02:12 -0700 2009-08-16 10:45:42 -0700 Proposed site-specific hack 28350_r0.diff text/plain 3103 mitz SW5kZXg6IFdlYkNvcmUvQ2hhbmdlTG9nCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFdlYkNvcmUvQ2hhbmdlTG9n CShyZXZpc2lvbiA0NzMzNSkKKysrIFdlYkNvcmUvQ2hhbmdlTG9nCSh3b3JraW5nIGNvcHkpCkBA IC0xLDMgKzEsMjMgQEAKKzIwMDktMDgtMTYgIERhbiBCZXJuc3RlaW4gIDxtaXR6QGFwcGxlLmNv bT4KKworICAgICAgICBSZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKworICAgICAgICBSRUdS RVNTSU9OIChyNDcyNTUpOiBNZWRpYVdpa2kncyAoaW5jbHVkaW5nIFdpa2lwZWRpYSkgbmF2aWdh dGlvbiBwYW5lCisgICAgICAgIGFwcGVhcnMgYmVsb3cgdGhlIG1haW4gY29udGVudAorICAgICAg ICBodHRwczovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MjgzNTAKKworICAgICAg ICBBIHBhcnRpY3VsYXIgdmVyc2lvbiBvZiB0aGUgTWVkaWFXaWtpIHNvZnR3YXJlIGRldGVjdHMg V2ViS2l0IHRocm91Z2gKKyAgICAgICAgdXNlciBhZ2VudCBzbmlmZmluZyBhbmQgaW1wb3J0cyBh IHN0eWxlIHNoZWV0IGNhbGxlZCBLSFRNTEZpeGVzLmNzcywKKyAgICAgICAgd2hpY2ggY29udGFp bnMgYSBzaW5nbGUgcnVsZSB0aGF0IHdhcyBtZWFudCB0byB3b3JrIGFyb3VuZCBzb21lIEtIVE1M CisgICAgICAgIGJ1ZywgYnV0IGN1cnJlbnRseSBoYXMgdGhlIHNvbGUgZWZmZWN0IG9mIGNhdXNp bmcgdGhlIGZsb2F0IGNvbnRhaW5pbmcKKyAgICAgICAgdGhlIG1haW4gYXJ0aWNsZSBjb250ZW50 IHRvIGV4dGVuZCBhbGwgdGhlIHdheSB0byB0aGUgbGVmdCBhbmQgdGh1cyBwdXNoCisgICAgICAg IGRvd24gdGhlIGxlZnQgbmF2aWdhdGlvbiBwYW5lLgorCisgICAgICAgICogY3NzL0NTU0ltcG9y dFJ1bGUuY3BwOgorICAgICAgICAoV2ViQ29yZTo6Q1NTSW1wb3J0UnVsZTo6c2V0Q1NTU3R5bGVT aGVldCk6IElmIHNpdGUgc3BlY2lmaWMgaGFja3MgYXJlCisgICAgICAgIGVuYWJsZWQsIGNoZWNr IGlmIHRoZSBpbXBvcnRlZCBzdHlsZSBzaGVldCBpcyB0aGUgTWVkaWFXaWtpCisgICAgICAgIEtI VE1MRml4ZXMuY3NzLiBJZiBzbywgcmVtb3ZlIHRoZSBvZmZlbmRpbmcgcnVsZS4KKwogMjAwOS0w OC0xNSAgU2ltb24gRnJhc2VyICA8c2ltb24uZnJhc2VyQGFwcGxlLmNvbT4KIAogICAgICAgICBS ZXZpZXdlZCBieSBEYXZlIEh5YXR0CkluZGV4OiBXZWJDb3JlL2Nzcy9DU1NJbXBvcnRSdWxlLmNw cAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09Ci0tLSBXZWJDb3JlL2Nzcy9DU1NJbXBvcnRSdWxlLmNwcAkocmV2aXNpb24g NDczMjMpCisrKyBXZWJDb3JlL2Nzcy9DU1NJbXBvcnRSdWxlLmNwcAkod29ya2luZyBjb3B5KQpA QCAtMSw3ICsxLDcgQEAKIC8qCiAgKiAoQykgMTk5OS0yMDAzIExhcnMgS25vbGwgKGtub2xsQGtk ZS5vcmcpCiAgKiAoQykgMjAwMi0yMDAzIERpcmsgTXVlbGxlciAobXVlbGxlckBrZGUub3JnKQot ICogQ29weXJpZ2h0IChDKSAyMDAyLCAyMDA1LCAyMDA2LCAyMDA4IEFwcGxlIEluYy4gQWxsIHJp Z2h0cyByZXNlcnZlZC4KKyAqIENvcHlyaWdodCAoQykgMjAwMiwgMjAwNSwgMjAwNiwgMjAwOCwg MjAwOSBBcHBsZSBJbmMuIEFsbCByaWdodHMgcmVzZXJ2ZWQuCiAgKgogICogVGhpcyBsaWJyYXJ5 IGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0IGFuZC9vcgogICogbW9k aWZ5IGl0IHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05VIExpYnJhcnkgR2VuZXJhbCBQdWJsaWMK QEAgLTI2LDYgKzI2LDggQEAKICNpbmNsdWRlICJEb2NMb2FkZXIuaCIKICNpbmNsdWRlICJEb2N1 bWVudC5oIgogI2luY2x1ZGUgIk1lZGlhTGlzdC5oIgorI2luY2x1ZGUgIlNldHRpbmdzLmgiCisj aW5jbHVkZSA8d3RmL1N0ZExpYkV4dHJhcy5oPgogCiBuYW1lc3BhY2UgV2ViQ29yZSB7CiAKQEAg LTYwLDcgKzYyLDIwIEBAIHZvaWQgQ1NTSW1wb3J0UnVsZTo6c2V0Q1NTU3R5bGVTaGVldChjb24K IAogICAgIENTU1N0eWxlU2hlZXQqIHBhcmVudCA9IHBhcmVudFN0eWxlU2hlZXQoKTsKICAgICBi b29sIHN0cmljdCA9ICFwYXJlbnQgfHwgcGFyZW50LT51c2VTdHJpY3RQYXJzaW5nKCk7Ci0gICAg bV9zdHlsZVNoZWV0LT5wYXJzZVN0cmluZyhzaGVldC0+c2hlZXRUZXh0KHN0cmljdCksIHN0cmlj dCk7CisgICAgU3RyaW5nIHNoZWV0VGV4dCA9IHNoZWV0LT5zaGVldFRleHQoc3RyaWN0KTsKKyAg ICBtX3N0eWxlU2hlZXQtPnBhcnNlU3RyaW5nKHNoZWV0VGV4dCwgc3RyaWN0KTsKKworICAgIGlm IChzdHJpY3QgJiYgcGFyZW50ICYmIHBhcmVudC0+ZG9jKCkgJiYgcGFyZW50LT5kb2MoKS0+c2V0 dGluZ3MoKSAmJiBwYXJlbnQtPmRvYygpLT5zZXR0aW5ncygpLT5uZWVkc1NpdGVTcGVjaWZpY1F1 aXJrcygpKSB7CisgICAgICAgIC8vIFdvcmsgYXJvdW5kIDxodHRwczovL2J1Z3Mud2Via2l0Lm9y Zy9zaG93X2J1Zy5jZ2k/aWQ9MjgzNTA+LgorICAgICAgICBERUZJTkVfU1RBVElDX0xPQ0FMKGNv bnN0IFN0cmluZywgc2xhc2hLSFRNTEZpeGVzRG90Q3NzLCAoIi9LSFRNTEZpeGVzLmNzcyIpKTsK KyAgICAgICAgREVGSU5FX1NUQVRJQ19MT0NBTChjb25zdCBTdHJpbmcsIG1lZGlhV2lraUtIVE1M Rml4ZXNTdHlsZVNoZWV0LCAoIi8qIEtIVE1MIGZpeCBzdHlsZXNoZWV0ICovXG4vKiB3b3JrIGFy b3VuZCB0aGUgaG9yaXpvbnRhbCBzY3JvbGxiYXJzICovXG4jY29sdW1uLWNvbnRlbnQgeyBtYXJn aW4tbGVmdDogMDsgfVxuXG4iKSk7CisgICAgICAgIGlmICh1cmwuZW5kc1dpdGgoc2xhc2hLSFRN TEZpeGVzRG90Q3NzKSAmJiBzaGVldFRleHQgPT0gbWVkaWFXaWtpS0hUTUxGaXhlc1N0eWxlU2hl ZXQpIHsKKyAgICAgICAgICAgIEFTU0VSVChtX3N0eWxlU2hlZXQtPmxlbmd0aCgpID09IDEpOwor ICAgICAgICAgICAgRXhjZXB0aW9uQ29kZSBlYzsKKyAgICAgICAgICAgIG1fc3R5bGVTaGVldC0+ ZGVsZXRlUnVsZSgwLCBlYyk7CisgICAgICAgIH0KKyAgICB9CisKICAgICBtX2xvYWRpbmcgPSBm YWxzZTsKIAogICAgIGlmIChwYXJlbnQpCg==