58727 2011-04-16 02:06:38 -0700 [Qt] QWebView can not show eBay pages correctly 2011-07-06 10:11:32 -0700 1 1 1 Unclassified WebKit Page Loading 528+ (Nightly build) All Windows XP RESOLVED WONTFIX Qt, QtTriaged P1 Critical --- 1 zhiyiliu luiz ademar benjamin christian.webkit joel.parks kenneth kling laszlo.gombos markus menard rafael.lobo robert thomas.thrainer ttf11 zhiyiliu oldest_to_newest 387235 0 zhiyiliu 2011-04-16 02:06:38 -0700 For some eBay pages, QWebView always shows blank page. I've checked the LoadFinished signal, and the OK is false. The same pages can be rendered correctly on popular browsers, such as IE, Safari or Chrome. I can consistently reproduce the problem both on Windows and Ubuntu Linux. Here's how to reproduce it (a 2 minute effort), 1. Create a QT Gui project 2. Drag a QWebView widget to the form 3. In the MainWindow constructor, add ui->webView->setUrl(QUrl("http://www.ebay.com")); 4. Now run your project 5. Login to eBay in your app, click on the top-right "My eBay" link, and you get a blank page. 387372 1 benjamin 2011-04-17 10:22:43 -0700 Moving to P1, this should be investigated before QtWebKit 2.2. I can reproduce with trunk on Linux. When clicking on "MyEbay" (or loading http://my.ebay.com/ ) after login, I only get "OK" on the page. Changing the user-agent string to the one of Safari fixes the issue. We should have a look for the missing bits like for hotmail. If no sensible workaround can be found, we will close this bug. We should also raise the issue to ebay.com. 388360 2 zhiyiliu 2011-04-19 01:50:44 -0700 (In reply to comment #1) > Moving to P1, this should be investigated before QtWebKit 2.2. > > I can reproduce with trunk on Linux. When clicking on "MyEbay" (or loading http://my.ebay.com/ ) after login, I only get "OK" on the page. > > Changing the user-agent string to the one of Safari fixes the issue. We should have a look for the missing bits like for hotmail. If no sensible workaround can be found, we will close this bug. > > We should also raise the issue to ebay.com. I just did some more tests. If I put "Safari/533.20.27" or "Safari/531.22.7" in the user-agent, it will break. But if I take the Safari part out, it will work. In fact, anything other than "Safari" (such as "my browser") for user-agent would work fine. 399129 3 92487 luiz 2011-05-05 15:59:46 -0700 Created attachment 92487 patch 399432 4 92487 kenneth 2011-05-06 01:53:56 -0700 Comment on attachment 92487 patch could this be a security issue? 399595 5 luiz 2011-05-06 10:13:07 -0700 (In reply to comment #4) > (From update of attachment 92487 [details]) > could this be a security issue? I am not sure. I think that it may be not because in this specific case QNAM is not emitting the sslErrors signal. But it would be nice to have Markus opinion on that. 401112 6 markus 2011-05-10 02:58:21 -0700 Can you backtrace to where QNAM is setting/emitting the ProtocolFailure? 404565 7 luiz 2011-05-16 10:18:52 -0700 (In reply to comment #6) > Can you backtrace to where QNAM is setting/emitting the ProtocolFailure? Sure, I will do it today. But more then finding out what is going on in this specific case, I would like to ignore all the errors that are not related to security issues. In this case for example the error is not SslHandshakeFailedError, no sslErrors signal is been emited (I will confirm it) and the response content seems to be good enough for WebKit to render the page and proceed the eBay navigation, meaning the the pair user/password has been accepted by eBay. What I would like to know is how to identify the security issues with the information provided by QNetworkReply. With this information I will be able to ignore the other QNAM errors and proceed based on message headers and contents only (if they are present), on a best effort basis. 410107 8 92487 hausmann 2011-05-25 18:30:29 -0700 Comment on attachment 92487 patch View in context: https://bugs.webkit.org/attachment.cgi?id=92487&action=review r- because neither the ChangeLog nor the hunk in QNetworkReplyHandler explain why this is done, i.e. why QNAM sets ProtocolFailure but we choose to ignore it. > Source/WebCore/platform/network/qt/QNetworkReplyHandler.cpp:430 > + if (httpStatusCode == 200 && reply->error() == QNetworkReply::ProtocolFailure) > + return true; > + Please find out why QNAM is setting ProtocolFailure as error here. If the situation is justified, we should explain with a comment why we ignore the error. 410863 9 95047 luiz 2011-05-26 14:50:06 -0700 Created attachment 95047 patch 411098 10 95047 hausmann 2011-05-26 20:18:26 -0700 Comment on attachment 95047 patch View in context: https://bugs.webkit.org/attachment.cgi?id=95047&action=review > Source/WebCore/ChangeLog:11 > + QNAM is having problems when uncompressing some of the contents returned by eBay and > + notifing error QNetworkReply::ProtocolFailure. It happens that the HTTP status code > + for the same message is 200 OK and QNetworkReply::ProtocolFailure does not seem to be > + related to any security issue. Thanks for the analysis :). So isn't this actually a Qt bug? I mean, the fact that we get _some_ data but an error is set makes me think that either a) the data was successfully decompressed but Qt thinks that there's an error even though there isn't (interpreting zlib results incorrectly?) or b) there was a real error decompressing the data and we deliver corrupted content to webkit, but as it turns out webkit handles the corrupted content and we don't see any visual glitches in the resulting rendering. Do you know which one it is? 411549 11 luiz 2011-05-27 11:06:23 -0700 (In reply to comment #10) > (From update of attachment 95047 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=95047&action=review > > > Source/WebCore/ChangeLog:11 > > + QNAM is having problems when uncompressing some of the contents returned by eBay and > > + notifing error QNetworkReply::ProtocolFailure. It happens that the HTTP status code > > + for the same message is 200 OK and QNetworkReply::ProtocolFailure does not seem to be > > + related to any security issue. > > Thanks for the analysis :). So isn't this actually a Qt bug? I mean, the fact that we get _some_ data but an error is set makes me think that either > > a) the data was successfully decompressed but Qt thinks that there's an error even though there isn't (interpreting zlib results incorrectly?) > > or > > b) there was a real error decompressing the data and we deliver corrupted content to webkit, but as it turns out webkit handles the corrupted content and we don't see any visual glitches in the resulting rendering. > > Do you know which one it is? I have always been working with hypothesis b. After a quick look at the QNAM's code now I think that the server is closing the connection a bit early and some bits of the message are lost. So, there were indeed a protocol failure and the content is probably corrupted. 412811 12 luiz 2011-05-31 13:04:52 -0700 Simon, the idea was to ignore those QNAM errors that are not security issues, if there is some content to WebKit to deal with. I think that it would not be very different from actually receiving not compressed corrupted content from the server. It seems that QNAM aborts just after noticing the error and before uncompressing the last data chunk. It would be better, considering this best effort policy, to uncompress all the received content before aborting. 418157 13 luiz 2011-06-09 11:52:09 -0700 How should we proceed here? 420550 14 luiz 2011-06-14 10:40:58 -0700 Does anyone have any opinions regarding this issue? Although I think that this change is OK, we may just close this bug and raise the issue to ebay.com. 420772 15 kenneth 2011-06-14 15:31:19 -0700 (In reply to comment #14) > Does anyone have any opinions regarding this issue? > > Although I think that this change is OK, we may just close this bug and raise the issue to ebay.com. Adding christian as he might know people who can actually raise that issue. 423843 16 robert 2011-06-20 12:15:13 -0700 *** Bug 50746 has been marked as a duplicate of this bug. *** 428265 17 joel.parks 2011-06-27 14:02:53 -0700 (In reply to comment #16) > *** Bug 50746 has been marked as a duplicate of this bug. *** as part of the discussion in 50746, the Qt bug was raised: http://bugreports.qt.nokia.com/browse/QTBUG-16022 And the associated analysis shows that the Ebay has delivered gzip-compressed content without end-of-stream marker. (In reply to comment #12) > Simon, the idea was to ignore those QNAM errors that are not security issues, if there is some content to WebKit to deal with. > I think that it would not be very different from actually receiving not compressed corrupted content from the server. > > It seems that QNAM aborts just after noticing the error and before uncompressing the last data chunk. It would be better, considering this best effort policy, to uncompress all the received content before aborting. I am in favor of that "best effort policy" attempt to uncompress all the received content before aborting. 429473 18 ttf11 2011-06-29 01:31:43 -0700 I encounter the same bug with http://sports.qq.com At first I thought it was a generic gzip-handling issue, but now I assume this site is also missing the end-of-stream marker. I am also very much in favor of "best effort policy". Can I help out? 429478 19 ttf11 2011-06-29 01:53:37 -0700 I saved the gzipped reply from http://sports.qq.com to a local file and then ran zcat to decompress it. It didn't report any problems at all, so I'm not yet sure if sports.qq.com also fails because of missing end-of-stream marker, or because some other problem. 429482 20 thomas.thrainer 2011-06-29 01:56:53 -0700 Comment #1 states that changing the user-agent string fixes the issue with eBay, maybe sports.qq.com does deliver different gzip-streams for different user-agents as well? 429654 21 luiz 2011-06-29 09:13:29 -0700 (In reply to comment #18) > I encounter the same bug with http://sports.qq.com > At first I thought it was a generic gzip-handling issue, but now I assume this site is also missing the end-of-stream marker. > > I am also very much in favor of "best effort policy". Can I help out? I could not reproduce the problem with http://sports.qq.com. Could you provide a sequence of steps that I could use to reproduce it? I must say that I cannot understand much of that page. :) 430264 22 ttf11 2011-06-30 01:59:45 -0700 @Thomas : I've created a separate test case and found which code causes the error (the returned data is not uncompressed, but shown inside the browser): 1) create a custom QNetworkAccessManager and override createRequest(...) 2) inside the function createRequest(...) create a copy of the request object (so I can modify it) as such : QNetworkRequest reqCopy(req); 3) then do: reqCopy.setRawHeader("Accept-Encoding", "gzip"); //this causes the problems Note that the value ("gzip" here) doesn't matter. Just setting the Accept-Encoding header confuses QtWebKit. when I disable this setRawHeader() call, it works 100% reliable (so gzipped content is handled correctly if i didn't set the "Accept-Encoding" header). note: sports.qq.com sometimes returns uncompressed data, but usually it is compressed. You might need to try a few times and make sure caching is disabled. I disabled cache with : reqCopy.setAttribute(QNetworkRequest::CacheLoadControlAttribute, QNetworkRequest::AlwaysNetwork); 430275 23 ttf11 2011-06-30 02:17:05 -0700 (In reply to comment #22) from the source code of qhttpnetworkconnection.cpp : ==================== value = request.headerField("accept-encoding"); if (value.isEmpty()) { #ifndef QT_NO_COMPRESS request.setHeaderField("Accept-Encoding", "gzip"); request.d->autoDecompress = true; #else // if zlib is not available set this to false always request.d->autoDecompress = false; #endif } ==================== I believe this is a bug. If I manually set the "accept-encoding" header, autoDecompress becomes false (even if I set it to "gzip"). 430297 24 ttf11 2011-06-30 02:41:29 -0700 (In reply to comment #23) > I believe this is a bug. If I manually set the "accept-encoding" header, autoDecompress becomes false (even if I set it to "gzip"). Created a new bug report this this issue with a proposed solution: https://bugs.webkit.org/show_bug.cgi?id=63696 432244 25 95047 vestbo 2011-07-05 06:17:05 -0700 Comment on attachment 95047 patch I believe this is related to the Qt network stack not dealing with a missing EOF marker in the gzip data, and we should fix it in Qt, not work around it here. 432316 26 ademar 2011-07-05 10:28:07 -0700 (In reply to comment #25) > (From update of attachment 95047 [details]) > I believe this is related to the Qt network stack not dealing with a missing EOF marker in the gzip data, and we should fix it in Qt, not work around it here. The bug in Qt is http://bugreports.qt.nokia.com/browse/QTBUG-16022, how can we make sure this bug is closed on qt-4.7 and qt-4.8 (worst case just qt-4.8)? 432319 27 luiz 2011-07-05 10:30:49 -0700 (In reply to comment #25) > (From update of attachment 95047 [details]) > I believe this is related to the Qt network stack not dealing with a missing EOF marker in the gzip data, and we should fix it in Qt, not work around it here. The idea was to have a workaround for 2.2. But I agree with you. Then I think that we should close this bug. 432852 28 ademar 2011-07-06 10:11:32 -0700 This was fixed in Qt (http://bugreports.qt.nokia.com/browse/QTBUG-16022). I've tested it (using qt-4.7) and it works fine (the fix will also be merged into 4.8 in the next days). 92487 2011-05-05 15:59:46 -0700 2011-05-26 14:50:06 -0700 patch 0001-Qt-QWebView-can-not-show-eBay-pages-correctly.patch text/plain 2601 luiz RnJvbSAwN2JlNmQ3NjQ3ZWFmYTAzZDcxOTQ5MzU5M2RkZjNiYmI2NTMxMjAwIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBMdWl6IEFnb3N0aW5pIDxsdWl6LmFnb3N0aW5pQG9wZW5ib3Nz YS5vcmc+CkRhdGU6IFRodSwgNSBNYXkgMjAxMSAxOTo1NzowOSAtMDMwMApTdWJqZWN0OiBbUEFU Q0hdIFtRdF0gUVdlYlZpZXcgY2FuIG5vdCBzaG93IGVCYXkgcGFnZXMgY29ycmVjdGx5CiBodHRw czovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9NTg3MjcKClJldmlld2VkIGJ5IE5P Qk9EWSAoT09QUyEpLgoKUU5BTSBpcyByZXR1cm5pbmcgYW4gZXJyb3Igb2YgdHlwZSBRTmV0d29y a1JlcGx5OjpQcm90b2NvbEZhaWx1cmUgaW4gc29tZSBzaXR1YXRpb24Kd2hlbiBuYXZpZ2F0aW5n IGluIGViYXkuIEl0IGhhcHBlbnMgdGhhdCB0aGUgSFRUUCBzdGF0dXMgY29kZSBmb3IgdGhlIHNh bWUgbWVzc2FnZQppcyAyMDAgT0suCgpXaGF0IHRoaXMgcGF0Y2ggZG9lcyBpcyB0byBpZ25vcmUg dGhlIGVycm9yIGlmIGl0cyB0eXBlIGlzIFFOZXR3b3JrUmVwbHk6OlByb3RvY29sRmFpbHVyZQph bmQgSFRUUCBzdGF0dXMgY29kZSBpcyAyMDAsIGFuZCB0byBsZXQgV2ViS2l0IGhhbmRsZSBwb3Nz aWJseSBtYWxmb3JtZWQgY29udGVudC4KCiogcGxhdGZvcm0vbmV0d29yay9xdC9RTmV0d29ya1Jl cGx5SGFuZGxlci5jcHA6CihXZWJDb3JlOjpzaG91bGRJZ25vcmVIdHRwRXJyb3IpOgotLS0KIFNv dXJjZS9XZWJDb3JlL0NoYW5nZUxvZyAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAxNyAr KysrKysrKysrKysrKysrKwogLi4uL3BsYXRmb3JtL25ldHdvcmsvcXQvUU5ldHdvcmtSZXBseUhh bmRsZXIuY3BwICAgfCAgICAzICsrKwogMiBmaWxlcyBjaGFuZ2VkLCAyMCBpbnNlcnRpb25zKCsp LCAwIGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJDb3JlL0NoYW5nZUxvZyBi L1NvdXJjZS9XZWJDb3JlL0NoYW5nZUxvZwppbmRleCBhOTM1MmU3Li5mYTk1ZDI2IDEwMDY0NAot LS0gYS9Tb3VyY2UvV2ViQ29yZS9DaGFuZ2VMb2cKKysrIGIvU291cmNlL1dlYkNvcmUvQ2hhbmdl TG9nCkBAIC0xLDMgKzEsMjAgQEAKKzIwMTEtMDUtMDUgIEx1aXogQWdvc3RpbmkgIDxsdWl6LmFn b3N0aW5pQG9wZW5ib3NzYS5vcmc+CisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BT ISkuCisKKyAgICAgICAgW1F0XSBRV2ViVmlldyBjYW4gbm90IHNob3cgZUJheSBwYWdlcyBjb3Jy ZWN0bHkKKyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTU4 NzI3CisKKyAgICAgICAgUU5BTSBpcyByZXR1cm5pbmcgYW4gZXJyb3Igb2YgdHlwZSBRTmV0d29y a1JlcGx5OjpQcm90b2NvbEZhaWx1cmUgaW4gc29tZSBzaXR1YXRpb24KKyAgICAgICAgd2hlbiBu YXZpZ2F0aW5nIGluIGViYXkuIEl0IGhhcHBlbnMgdGhhdCB0aGUgSFRUUCBzdGF0dXMgY29kZSBm b3IgdGhlIHNhbWUgbWVzc2FnZQorICAgICAgICBpcyAyMDAgT0suCisKKyAgICAgICAgV2hhdCB0 aGlzIHBhdGNoIGRvZXMgaXMgdG8gaWdub3JlIHRoZSBlcnJvciBpZiBpdHMgdHlwZSBpcyBRTmV0 d29ya1JlcGx5OjpQcm90b2NvbEZhaWx1cmUKKyAgICAgICAgYW5kIEhUVFAgc3RhdHVzIGNvZGUg aXMgMjAwLCBhbmQgdG8gbGV0IFdlYktpdCBoYW5kbGUgcG9zc2libHkgbWFsZm9ybWVkIGNvbnRl bnQuCisKKyAgICAgICAgKiBwbGF0Zm9ybS9uZXR3b3JrL3F0L1FOZXR3b3JrUmVwbHlIYW5kbGVy LmNwcDoKKyAgICAgICAgKFdlYkNvcmU6OnNob3VsZElnbm9yZUh0dHBFcnJvcik6CisKIDIwMTEt MDUtMDUgIEp1c3RpbiBOb3Zvc2FkICA8anVub3ZAY2hyb21pdW0ub3JnPgogCiAgICAgICAgIFJl dmlld2VkIGJ5IEtlbm5ldGggUnVzc2VsbC4KZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJDb3JlL3Bs YXRmb3JtL25ldHdvcmsvcXQvUU5ldHdvcmtSZXBseUhhbmRsZXIuY3BwIGIvU291cmNlL1dlYkNv cmUvcGxhdGZvcm0vbmV0d29yay9xdC9RTmV0d29ya1JlcGx5SGFuZGxlci5jcHAKaW5kZXggMGMz Y2Y1MC4uZjg2NDdkMyAxMDA2NDQKLS0tIGEvU291cmNlL1dlYkNvcmUvcGxhdGZvcm0vbmV0d29y ay9xdC9RTmV0d29ya1JlcGx5SGFuZGxlci5jcHAKKysrIGIvU291cmNlL1dlYkNvcmUvcGxhdGZv cm0vbmV0d29yay9xdC9RTmV0d29ya1JlcGx5SGFuZGxlci5jcHAKQEAgLTQyNSw2ICs0MjUsOSBA QCBzdGF0aWMgYm9vbCBzaG91bGRJZ25vcmVIdHRwRXJyb3IoUU5ldHdvcmtSZXBseSogcmVwbHks IGJvb2wgcmVjZWl2ZWREYXRhKQogewogICAgIGludCBodHRwU3RhdHVzQ29kZSA9IHJlcGx5LT5h dHRyaWJ1dGUoUU5ldHdvcmtSZXF1ZXN0OjpIdHRwU3RhdHVzQ29kZUF0dHJpYnV0ZSkudG9JbnQo KTsKIAorICAgIGlmIChodHRwU3RhdHVzQ29kZSA9PSAyMDAgJiYgcmVwbHktPmVycm9yKCkgPT0g UU5ldHdvcmtSZXBseTo6UHJvdG9jb2xGYWlsdXJlKQorICAgICAgICByZXR1cm4gdHJ1ZTsKKwog ICAgIGlmIChodHRwU3RhdHVzQ29kZSA9PSA0MDEgfHwgaHR0cFN0YXR1c0NvZGUgPT0gNDA3KQog ICAgICAgICByZXR1cm4gdHJ1ZTsKIAotLSAKMS43LjQuMQoK 95047 2011-05-26 14:50:06 -0700 2011-07-05 06:17:05 -0700 patch 0001-Qt-QWebView-can-not-show-eBay-pages-correctly.patch text/plain 3163 luiz RnJvbSBjODM2MTMzYjMzNDZiY2M4NTY4MTU4MTRiYmY0MTE0MTBjZjQyYmRiIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBMdWl6IEFnb3N0aW5pIDxsdWl6LmFnb3N0aW5pQG9wZW5ib3Nz YS5vcmc+CkRhdGU6IFRodSwgMjYgTWF5IDIwMTEgMTg6MzI6MzQgLTAzMDAKU3ViamVjdDogW1BB VENIXSBbUXRdIFFXZWJWaWV3IGNhbiBub3Qgc2hvdyBlQmF5IHBhZ2VzIGNvcnJlY3RseQogaHR0 cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTU4NzI3CgpSZXZpZXdlZCBieSBO T0JPRFkgKE9PUFMhKS4KClFOQU0gaXMgaGF2aW5nIHByb2JsZW1zIHdoZW4gdW5jb21wcmVzc2lu ZyBzb21lIG9mIHRoZSBjb250ZW50cyByZXR1cm5lZCBieSBlQmF5IGFuZApub3RpZmluZyBlcnJv ciBRTmV0d29ya1JlcGx5OjpQcm90b2NvbEZhaWx1cmUuIEl0IGhhcHBlbnMgdGhhdCB0aGUgSFRU UCBzdGF0dXMgY29kZQpmb3IgdGhlIHNhbWUgbWVzc2FnZSBpcyAyMDAgT0sgYW5kIFFOZXR3b3Jr UmVwbHk6OlByb3RvY29sRmFpbHVyZSBkb2VzIG5vdCBzZWVtIHRvIGJlCnJlbGF0ZWQgdG8gYW55 IHNlY3VyaXR5IGlzc3VlLgoKV2hhdCB0aGlzIHBhdGNoIGRvZXMgaXMgdG8gaWdub3JlIHRoZSBl cnJvciBpZiBpdHMgdHlwZSBpcyBRTmV0d29ya1JlcGx5OjpQcm90b2NvbEZhaWx1cmUKYW5kIEhU VFAgc3RhdHVzIGNvZGUgaXMgMjAwLCBhbmQgdG8gbGV0IFdlYktpdCBoYW5kbGUgcG9zc2libHkg bWFsZm9ybWVkIGNvbnRlbnQuCgoqIHBsYXRmb3JtL25ldHdvcmsvcXQvUU5ldHdvcmtSZXBseUhh bmRsZXIuY3BwOgooV2ViQ29yZTo6c2hvdWxkSWdub3JlSHR0cEVycm9yKToKLS0tCiBTb3VyY2Uv V2ViQ29yZS9DaGFuZ2VMb2cgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgMTggKysrKysr KysrKysrKysrKysrCiAuLi4vcGxhdGZvcm0vbmV0d29yay9xdC9RTmV0d29ya1JlcGx5SGFuZGxl ci5jcHAgICB8ICAgIDcgKysrKysrKwogMiBmaWxlcyBjaGFuZ2VkLCAyNSBpbnNlcnRpb25zKCsp LCAwIGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJDb3JlL0NoYW5nZUxvZyBi L1NvdXJjZS9XZWJDb3JlL0NoYW5nZUxvZwppbmRleCAyMTBkOTE0Li4wZDk2OTViIDEwMDY0NAot LS0gYS9Tb3VyY2UvV2ViQ29yZS9DaGFuZ2VMb2cKKysrIGIvU291cmNlL1dlYkNvcmUvQ2hhbmdl TG9nCkBAIC0xLDMgKzEsMjEgQEAKKzIwMTEtMDUtMDUgIEx1aXogQWdvc3RpbmkgIDxsdWl6LmFn b3N0aW5pQG9wZW5ib3NzYS5vcmc+CisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BT ISkuCisKKyAgICAgICAgW1F0XSBRV2ViVmlldyBjYW4gbm90IHNob3cgZUJheSBwYWdlcyBjb3Jy ZWN0bHkKKyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTU4 NzI3CisKKyAgICAgICAgUU5BTSBpcyBoYXZpbmcgcHJvYmxlbXMgd2hlbiB1bmNvbXByZXNzaW5n IHNvbWUgb2YgdGhlIGNvbnRlbnRzIHJldHVybmVkIGJ5IGVCYXkgYW5kCisgICAgICAgIG5vdGlm aW5nIGVycm9yIFFOZXR3b3JrUmVwbHk6OlByb3RvY29sRmFpbHVyZS4gSXQgaGFwcGVucyB0aGF0 IHRoZSBIVFRQIHN0YXR1cyBjb2RlCisgICAgICAgIGZvciB0aGUgc2FtZSBtZXNzYWdlIGlzIDIw MCBPSyBhbmQgUU5ldHdvcmtSZXBseTo6UHJvdG9jb2xGYWlsdXJlIGRvZXMgbm90IHNlZW0gdG8g YmUKKyAgICAgICAgcmVsYXRlZCB0byBhbnkgc2VjdXJpdHkgaXNzdWUuCisKKyAgICAgICAgV2hh dCB0aGlzIHBhdGNoIGRvZXMgaXMgdG8gaWdub3JlIHRoZSBlcnJvciBpZiBpdHMgdHlwZSBpcyBR TmV0d29ya1JlcGx5OjpQcm90b2NvbEZhaWx1cmUKKyAgICAgICAgYW5kIEhUVFAgc3RhdHVzIGNv ZGUgaXMgMjAwLCBhbmQgdG8gbGV0IFdlYktpdCBoYW5kbGUgcG9zc2libHkgbWFsZm9ybWVkIGNv bnRlbnQuCisKKyAgICAgICAgKiBwbGF0Zm9ybS9uZXR3b3JrL3F0L1FOZXR3b3JrUmVwbHlIYW5k bGVyLmNwcDoKKyAgICAgICAgKFdlYkNvcmU6OnNob3VsZElnbm9yZUh0dHBFcnJvcik6CisKIDIw MTEtMDUtMDIgIFJvYmVydCBIb2dhbiAgPHJvYmVydEB3ZWJraXQub3JnPgogCiAgICAgICAgIFJl dmlld2VkIGJ5IEFkYW0gUm9iZW4uCmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViQ29yZS9wbGF0Zm9y bS9uZXR3b3JrL3F0L1FOZXR3b3JrUmVwbHlIYW5kbGVyLmNwcCBiL1NvdXJjZS9XZWJDb3JlL3Bs YXRmb3JtL25ldHdvcmsvcXQvUU5ldHdvcmtSZXBseUhhbmRsZXIuY3BwCmluZGV4IDU5ZDIyNDUu LjE4MGJhZGEgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XZWJDb3JlL3BsYXRmb3JtL25ldHdvcmsvcXQv UU5ldHdvcmtSZXBseUhhbmRsZXIuY3BwCisrKyBiL1NvdXJjZS9XZWJDb3JlL3BsYXRmb3JtL25l dHdvcmsvcXQvUU5ldHdvcmtSZXBseUhhbmRsZXIuY3BwCkBAIC00MjUsNiArNDI1LDEzIEBAIHN0 YXRpYyBib29sIHNob3VsZElnbm9yZUh0dHBFcnJvcihRTmV0d29ya1JlcGx5KiByZXBseSwgYm9v bCByZWNlaXZlZERhdGEpCiB7CiAgICAgaW50IGh0dHBTdGF0dXNDb2RlID0gcmVwbHktPmF0dHJp YnV0ZShRTmV0d29ya1JlcXVlc3Q6Okh0dHBTdGF0dXNDb2RlQXR0cmlidXRlKS50b0ludCgpOwog CisgICAgLy8gUU5BTSdzIFByb3RvY29sRmFpbHVyZSBlcnJvciBkb2VzIG5vdCBzZWVtIHRvIGJl IHJlbGF0ZWQgdG8gc2VjdXJpdHkgaXNzdWVzLiBQcm90b2NvbEZhaWx1cmUKKyAgICAvLyBpcyBl bW1pdGVkIHdoZW4gUU5BTSBmaW5kcyBwcm9ibGVtcyBsaWtlIHNvY2tldCByZWFkL3dyaXRlIGVy cm9ycywgY29udGVudCB1bmNvbXByZXNzaW5nIGlzc3VlcywgLi4uCisgICAgLy8gV2UgaWdub3Jl IFByb3RvY29sRmFpbHVyZSBoZXJlIGlmIHRoZSBodHRwIHN0YXR1cyBjb2RlIGlzIDIwMCBhbmQg bGV0IFdlYktpdCBoYW5kbGUgcG9zc2libHkKKyAgICAvLyBtYWxmb3JtZWQgY29udGVudC4KKyAg ICBpZiAoaHR0cFN0YXR1c0NvZGUgPT0gMjAwICYmIHJlcGx5LT5lcnJvcigpID09IFFOZXR3b3Jr UmVwbHk6OlByb3RvY29sRmFpbHVyZSkKKyAgICAgICAgcmV0dXJuIHRydWU7CisKICAgICBpZiAo aHR0cFN0YXR1c0NvZGUgPT0gNDAxIHx8IGh0dHBTdGF0dXNDb2RlID09IDQwNykKICAgICAgICAg cmV0dXJuIHRydWU7CiAKLS0gCjEuNy40LjEKCg==