33962 2010-01-21 11:39:45 -0800 'blur' event fired while modal dialog box is up 2010-02-24 15:18:15 -0800 1 1 1 Unclassified WebKit New Bugs 528+ (Nightly build) All All RESOLVED FIXED P2 Normal --- 1 jamesr webkit-unassigned ap creis dglazkov dimich eric fishd oldest_to_newest 183260 0 jamesr 2010-01-21 11:39:45 -0800 WebKit fires the 'blur' event, and runs associated handlers, while modal dialog boxes (like window.confirm() and window.alert()) are up. This breaks assumptions in the page and in WebKit. Test page: http://livedom.validator.nu/?<!DOCTYPE%20html>%0A<div%20id%3D'log'></div>%0A<input%20type%3D'text'%20id%3D'foo'>lalala</input>%0A<script>%0Afunction%20$(s)%20{return%20document.getElementById(s);}%0Afunction%20l(s)%20{%20$('log').innerHTML%20%2B%3D%20"<br>"%20%2B%20s;%20}%0A%0A$('foo').onmouseup%20%3D%20function()%20{%0A%20%20l('mouseup,%20about%20to%20confirm');%0A%20%20window.confirm("hi");%0A%20%20l('mouseup,%20did%20confirm');%0A}%0A$('foo').onblur%20%3D%20function()%20{%0A%20%20l('blur');%0A%20%20window.setTimeout(function()%20{l('timer%20fired');},%205000);%0A};%0A</script> On WebKit ToT, clicking inside the input area (and leaving the dialog up for >5 seconds) causes the following output: mouseup, about to confirm blur timer fired mouseup, did confirm blur timer fired In debug mode, if the dialog is dismissed in less than 5 seconds WebKit crashes with this assertion: ASSERTION FAILED: m_suspended (/usr/local/home/jamesr/WebKit/WebCore/page/DOMTimer.cpp:192 virtual void WebCore::DOMTimer::resume()) The reason is that the PageGroupLoadDeferrer suspends all active DOM objects when the modal dialog box is posted. When the dialog is dismissed, it iterates over all active DOM objects and tries to resume them. However, since the onblur handler fired while the dialog was up and set a new timer, it is not suspended when the resume() call is made. Safari 4.0.4 doesn't fire the blur event at all while the modal dialog box is up. On windows once the dialog box is dismissed the input area does not seem focused (it doesn't have a focus ring or a blinking cursor), but clicking outside of it does fire a blur event. On OS X the dialog has a focus ring and blinking cursor after the dialog is dimissed. Firefox 3.5.7 fires the blur handler while the dialog is up, but it doesn't run the body of the setTimeout() until the dialog box is dismissed regardless of how long the dialog is up. 183807 1 47227 jamesr 2010-01-22 14:27:11 -0800 Created attachment 47227 Testcase using window.alert 183812 2 47229 jamesr 2010-01-22 14:45:48 -0800 Created attachment 47229 Does not fire focus/blur events while a modal dialog is up This patch suppresses firing all focus events while a modal dialog is up (using Page::defersLoading() to detect this case). This is consistent with Safari 4.0.4 behavior, although it is a change compared to ToT WebKit. Here is a summary of what other browsers do when an <input> has a mouseup handler that opens a modal dialog (window.alert/window.confirm) and a blur handler that sets a timer (window.setTimeout): Firefox 3.5.7 executes the 'onblur' handler when the modal dialog appears. The timer is set, but it does not fire until the time has elapsed _and_ the dialog is dismissed. While the dialog is up, the input area does not appear to be focused (there is no blinking carrot or focus ring on OS X). When the dialog is dismissed, the input area is focused and looks focused (blinking carrot, focus ring on OS X). IE8 executes the 'onblur' handler when the modal dialog appears. The timer is set, but it does not start 'counting' until the dialog is dismissed (so on this test page it does not fire until 5 seconds after the dialog is dismissed). While the dialog is up, the input area doesn't visibly appear focused. Safari 4.0.4 on Windows does not execute the 'onblur' handler at all. The input area does not appear visually focused while the modal dialog is up. Once the dialog is dismissed, the input area still does not look visually focused and does not receive text input, but when the user clicks anywhere else on the page the 'blur' event still fires at the <input>. This seems really buggy. Safari 4.0.4 on OS X does not execute the 'onblur' handler at all. The input area does not appear visually focused while the modal dialog is up. Once the dialog is dismissed, the input area does look visually focused and does receive text input (unlike on Windows). WebKit ToT executes the 'onblur' handler while the dialog is up and fires the timer while the dialog is up. It also crashes with an assertion failure in debug mode if the dialog is dismissed while the timer is still pending. I do not think that website authors typically expect their code to execute while another piece of code is blocked on a modal dialog. This patch brings behavior back to roughly the Safari 4.0.4 behavior. Alternatively, we could still fire focus/blur events while modal dialogs are up but ensure that all timers created are created in the suspended state. Then they would be resumed by the PageGroupLoadDeferrer when the dialog is dismissed. This would be closer to the Firefox/IE8 behavior, which is still pretty odd IMHO. 184776 3 eric 2010-01-26 15:02:53 -0800 I think we have a blur of death bug on file as well. I remember running into it while writing test cases for wave bugs. 184777 4 eric 2010-01-26 15:03:24 -0800 Yes, bug 18315. 184786 5 jamesr 2010-01-26 15:17:49 -0800 Bug 18315 looks like exactly the same issue. 184799 6 47229 eric 2010-01-26 15:48:45 -0800 Comment on attachment 47229 Does not fire focus/blur events while a modal dialog is up Makes sense to me. Seems the code should have a comment next to it explaining why the if check is made. And can we test this? If we can't, we should explain why not in the ChagneLog. 184963 7 fishd 2010-01-26 23:27:41 -0800 I wonder if we can leverage showModalDialog somehow to test this. window.alert() just logs text in the layout tests, but showModalDialog actually functions. 185235 8 jamesr 2010-01-27 15:06:34 -0800 showModalDialog() support in DRT and test_shell seems really bad. It's off by default in test_shell and can be enabled with a command-line flag, but the nested loop for the opened windows does not spin down when window.close() is invoked inside the popup so it's not very useful. I couldn't get the dialog to show at all using DRT - I suspect that this behavior is also behind some flag or setting and may not be fully baked. I'll upload another patch with explanatory comments in the code and ChangeLog that Eric suggested, but I don't think a new test is entirely feasible here, as sad as that is. 185242 9 47567 jamesr 2010-01-27 15:22:09 -0800 Created attachment 47567 patch 185243 10 47567 darin 2010-01-27 15:25:25 -0800 Comment on attachment 47567 patch Is it OK to never fire these events? Do we need to fire them after the modal dialog goes back down? 185244 11 jamesr 2010-01-27 15:31:37 -0800 The focused state is the same when the dialog is dismissed as it was when the dialog went up, so it doesn't make sense to fire any events at the page. In particular, with the following snippet: <input id='i'></input> <script> var inElem = document.getElementById('i'); inElem.focus(); window.alert('hi'); </script> Once the alert is dismissed, the input area is still focused. 185254 12 jamesr 2010-01-27 15:47:14 -0800 FYI, html5 dictates the following: window.alert(), window.pause(), and window.prompt() all require the user agent to 'pause' which is defined at http://dev.w3.org/html5/spec/Overview.html#pause as: Some of the algorithms in this specification, for historical reasons, require the user agent to pause while running a task until some condition has been met. While a user agent has a paused task, the corresponding event loop must not run further tasks, and any script in the currently running task must block. User agents should remain responsive to user input while paused, however, albeit in a reduced capacity since the event loop will not be doing anything. window.showModalDialog() has a slightly different behavior in the spec: Disable the user interface for all the browsing contexts in the list of background browsing contexts. This should prevent the user from navigating those browsing contexts, causing events to be sent to those browsing context, or editing any content in those browsing contexts. However, it does not prevent those browsing contexts from receiving events from sources other than the user, from running scripts, from running animations, and so forth. http://dev.w3.org/html5/spec/Overview.html#dom-showmodaldialog Both seem to prohibit firing any events at the page opening the dialog. 186775 13 dimich 2010-02-01 20:08:22 -0800 It seems the question here is "why only focus events need special treatment?" I was easily able to reproduce the ASSERT in timers by creating a timer from Worker's onmessage callback while showing alert() from the main page. So either we should define what happens when a timer is created while modal UI is up (fire it after modal UI is gone?), or we should 'pause' the page showing modal UI in a more generic way. 187136 14 jamesr 2010-02-02 14:09:42 -0800 I agree in principle, Dmitry. Ideally we would not fire any events at a page behind a modal dialog. However, it makes sense to change this in smaller, isolated changes just in case there's a web compat issue. In particular special casing focus/blur makes sense in the short term for the following reasons: - This case is causing ASSERT failures on a very popular webpage (gmail). I don't know of any popular sites that trigger ASSERT failures on other events (like onmessage). - The blur event always fires when a modal dialog is opened up since the modal dialog will gain focus. This makes it much more likely to trigger bugs than things like onmessage which are racy. - The behavior in this patch matches a released browser (Safari 4.0.4), which reduces the change of introducing new compat bugs. Also this patch is quite tiny and doesn't touch anything as sensitive as the core event handling logic. 187157 15 ap 2010-02-02 14:34:13 -0800 > Ideally we would not fire any events at a page behind a modal dialog. Note that Firefox will fire an image onload event behind a modal dialog when the image load finishes. I'm not sure it's a bad thing - the concept of modality is about user input, not about something that happens programmatically. 187546 16 dimich 2010-02-03 16:30:07 -0800 After some looking around I think the ASSERT in timer code is a red herring here. Firing events on a page that is already in a modal UI means more JS reentrancy. Very few JS developers are prepared to handle reentrancy, that's a good reason to 'freeze' the page behind the modal UI. It seems the good analogy is Cocoa NSApplication's runModalForWindow - it stops all events (including timers) on other windows. One reason why innocently-looking JS can easily shoot itself in the foot in presence of JS reentrancy is bug 18315 which pop ups alerts on top of each other and prevents the page from being closed (in ToT). That bug will be fixed with the proposed patch too. If FF loads images and fires load events behind the modal UI, then they probably have some code in place to deal with an HTTP Auth or "bad cert" dialogs that may pop up while loading images, or perhaps there is some way to 'defer' another alert() that JS code in the event handler may want to pop up. This can be done but it adds complexity and additional code and queues, etc. For example, the network layer of the embedder may continue to pull the bits off the network while events may be deferred (or blocked on the attempt to nest another modal UI, which seems to require more support). This behavior likely needs case-by-case consideration. Since in modal UI case the focus remains on the same element after modal UI is dismissed, I can see a reason not to fire focus events at all in this scenario (no 'blur' and no 'focus'). As James noted, the risk of compat issue is mitigated by the fact that shipping Safari does not fire those. It might be deemed necessary to prevent/defer other sources of events (worker.onmessage for example) from being dispatched while modal UI is up, or deal with effects of those in some other way, but it likely would require separate patches anyways. So I'm negating my previous remark, and think the patch is reasonable. 188781 17 47229 eric 2010-02-08 15:11:37 -0800 Comment on attachment 47229 Does not fire focus/blur events while a modal dialog is up Cleared Eric Seidel's review+ from obsolete attachment 47229 so that this bug does not appear in http://webkit.org/pending-commit. 189155 18 fishd 2010-02-09 15:00:40 -0800 (In reply to comment #15) > > Ideally we would not fire any events at a page behind a modal dialog. > > Note that Firefox will fire an image onload event behind a modal dialog when > the image load finishes. I'm not sure it's a bad thing - the concept of > modality is about user input, not about something that happens > programmatically. I believe that's a bug in Firefox. JavaScript is supposed to run to completion without any interleaving threads. If events fire during a JavaScript call, then that single threaded, run to completion rule is violated. 189183 19 dimich 2010-02-09 17:41:16 -0800 It can be a good idea to try to find what changed this behavior, since by fixing it we might 'revert' some effects of that change. Also, this really needs a test. This 'regressed' relative to Safari 4.0.4 because there is no tests for the modal UI. Without a test, it can be broken again the next day. Currently DRT does not implement [UIDelegate webViewRunModal]. Interestingly, custom property getter for DOMWindow even hides the showModalDialog() if that method is not implemented... Perhaps simply by implementing this method we could test modal behavior using showModalDialog()? Even one port's DRT is way better then nothing, since this is platform-independent code. It can be a separate patch - or perhaps combined, considering this is a 1-line fix. 192711 20 49249 jamesr 2010-02-22 17:11:48 -0800 Created attachment 49249 patch with manual tests This patch adds manual tests to WebCore/manual-tests/ 192727 21 jamesr 2010-02-22 17:45:29 -0800 The behavior changed from Safari 4.0.4 at http://trac.webkit.org/changeset/48257 which was a fix to bug https://bugs.webkit.org/show_bug.cgi?id=27105 "Blur and focus events are not fired when window is blurred and focused". This makes sense, the modal dialog was causing the window to get blurred/focused. However the blurred/focused window still shouldn't fire blur/focus events if it is hidden behind a modal dialog. 193256 22 jamesr 2010-02-23 23:03:11 -0800 Hey everyone, Is there consensus on this patch? I think most of the concerns have been addressed (there is a test, we know when the behavior changed, the new behavior is in line with the spec and Safari 4). The current behavior is pretty unfortunate. A coworker reported that he couldn't use a WebKit browser with debug assertions enabled without having the check fail extremely rapidly on gmail or google calendar. 193414 23 49249 dimich 2010-02-24 10:50:19 -0800 Comment on attachment 49249 patch with manual tests Looking at the patch that regressed this, it looks very reasonable. r=me. It's ok to add manual test for now but please create a bug for DRT to support testing modal dialogs and consider to investigate implementation! 193427 24 jamesr 2010-02-24 11:14:23 -0800 Filed https://bugs.webkit.org/show_bug.cgi?id=35350 to improve DRT. 193544 25 jamesr 2010-02-24 15:18:15 -0800 Committed r55205: <http://trac.webkit.org/changeset/55205> 47227 2010-01-22 14:27:11 -0800 2010-01-22 14:27:11 -0800 Testcase using window.alert alert_timeout.html text/html 445 jamesr PCFET0NUWVBFIGh0bWw+DQo8ZGl2IGlkPSdsb2cnPjwvZGl2Pg0KPGlucHV0IHR5cGU9J3RleHQn IGlkPSdmb28nPmxhbGFsYTwvaW5wdXQ+DQo8c2NyaXB0Pg0KZnVuY3Rpb24gJChzKSB7cmV0dXJu IGRvY3VtZW50LmdldEVsZW1lbnRCeUlkKHMpO30NCmZ1bmN0aW9uIGwocykgeyAkKCdsb2cnKS5p bm5lckhUTUwgKz0gIjxicj4iICsgczsgfQ0KDQokKCdmb28nKS5vbm1vdXNldXAgPSBmdW5jdGlv bigpIHsNCiAgbCgnbW91c2V1cCwgYWJvdXQgdG8gYWxlcnQnKTsNCiAgd2luZG93LmFsZXJ0KCJo aSIpOw0KICBsKCdtb3VzZXVwLCBkaWQgYWxlcnQnKTsNCn0NCiQoJ2ZvbycpLm9uYmx1ciA9IGZ1 bmN0aW9uKCkgew0KICBsKCdibHVyJyk7DQogIHdpbmRvdy5zZXRUaW1lb3V0KGZ1bmN0aW9uKCkg e2woJ3RpbWVyIGZpcmVkJyk7fSwgNTAwMCk7DQp9Ow0KPC9zY3JpcHQ+DQoNCg== 47229 2010-01-22 14:45:48 -0800 2010-02-08 15:11:36 -0800 Does not fire focus/blur events while a modal dialog is up blur_patch.diff text/plain 1541 jamesr ZGlmZiAtLWdpdCBhL1dlYkNvcmUvQ2hhbmdlTG9nIGIvV2ViQ29yZS9DaGFuZ2VMb2cKaW5kZXgg OTFjMGJmYS4uMzk4ZjQ5OCAxMDA2NDQKLS0tIGEvV2ViQ29yZS9DaGFuZ2VMb2cKKysrIGIvV2Vi Q29yZS9DaGFuZ2VMb2cKQEAgLTEsMyArMSwyMCBAQAorMjAxMC0wMS0yMiAgSmFtZXMgUm9iaW5z b24gIDxqYW1lc3JAY2hyb21pdW0ub3JnPgorCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAo T09QUyEpLgorCisgICAgICAgIERvIG5vdCBmaXJlIGZvY3VzIGV2ZW50cyB3aGlsZSBhIG1vZGFs IGRpYWxvZyBpcyB1cC4KKyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcu Y2dpP2lkPTMzOTYyCisKKyAgICAgICAgTW9kaWZpZXMgdGhlIEZvY3VzQ29udHJvbGxlciB0byBj aGVjayB0aGUgZnJhbWUncyBwYWdlJ3MgZGVmZXJzTG9hZGluZygpIGZsYWcgYmVmb3JlIGZpcmlu ZyBibHVyL2ZvY3VzIGV2ZW50cy4KKyAgICAgICAgVGhpcyBmbGFnIGlzIHNldCB3aGlsZSBhIG1v ZGFsIGRpYWxvZyAobGlrZSBhIHdpbmRvdy5hbGVydCBvciB3aW5kb3cuY29uZmlybSkgaXMgdXAu ICBGaXJpbmcgdGhlIGV2ZW50cyBjYXVzZXMKKyAgICAgICAgYXNzZXJ0aW9uIGZhaWx1cmVzLCBz aW5jZSB3aGVuIHRoZSBkaWFsb2cgaXMgZGlzbWlzc2VkIHRoZSBQYWdlR3JvdXBMb2FkRGVmZXJy ZXIgYXNzdW1lcyB0aGF0IG5vIHNjcmlwdAorICAgICAgICBoYXMgcnVuLgorCisgICAgICAgIE5v IG5ldyB0ZXN0cy4KKworICAgICAgICAqIHBhZ2UvRm9jdXNDb250cm9sbGVyLmNwcDoKKyAgICAg ICAgKFdlYkNvcmU6OkZvY3VzQ29udHJvbGxlcjo6c2V0Rm9jdXNlZCk6CisKIDIwMTAtMDEtMjEg IEFsZXhleSBQcm9za3VyeWFrb3YgIDxhcEBhcHBsZS5jb20+CiAKICAgICAgICAgUmV2aWV3ZWQg YnkgRGFyaW4gQWRsZXIuCmRpZmYgLS1naXQgYS9XZWJDb3JlL3BhZ2UvRm9jdXNDb250cm9sbGVy LmNwcCBiL1dlYkNvcmUvcGFnZS9Gb2N1c0NvbnRyb2xsZXIuY3BwCmluZGV4IDVlNzhjN2QuLjUy OGM5ODYgMTAwNjQ0Ci0tLSBhL1dlYkNvcmUvcGFnZS9Gb2N1c0NvbnRyb2xsZXIuY3BwCisrKyBi L1dlYkNvcmUvcGFnZS9Gb2N1c0NvbnRyb2xsZXIuY3BwCkBAIC0xMTMsNyArMTEzLDggQEAgdm9p ZCBGb2N1c0NvbnRyb2xsZXI6OnNldEZvY3VzZWQoYm9vbCBmb2N1c2VkKQogICAgIAogICAgIGlm IChtX2ZvY3VzZWRGcmFtZSAmJiBtX2ZvY3VzZWRGcmFtZS0+dmlldygpKSB7CiAgICAgICAgIG1f Zm9jdXNlZEZyYW1lLT5zZWxlY3Rpb24oKS0+c2V0Rm9jdXNlZChmb2N1c2VkKTsKLSAgICAgICAg ZGlzcGF0Y2hFdmVudHNPbldpbmRvd0FuZEZvY3VzZWROb2RlKG1fZm9jdXNlZEZyYW1lLT5kb2N1 bWVudCgpLCBmb2N1c2VkKTsKKyAgICAgICAgaWYgKCFtX2ZvY3VzZWRGcmFtZS0+cGFnZSgpLT5k ZWZlcnNMb2FkaW5nKCkpCisgICAgICAgICAgICBkaXNwYXRjaEV2ZW50c09uV2luZG93QW5kRm9j dXNlZE5vZGUobV9mb2N1c2VkRnJhbWUtPmRvY3VtZW50KCksIGZvY3VzZWQpOwogICAgIH0KIH0K IAo= 47567 2010-01-27 15:22:09 -0800 2010-02-22 17:11:48 -0800 patch b_33962.diff text/plain 1724 jamesr ZGlmZiAtLWdpdCBhL1dlYkNvcmUvQ2hhbmdlTG9nIGIvV2ViQ29yZS9DaGFuZ2VMb2cKaW5kZXgg NTNkZmQ1MC4uMTFjNjgwMSAxMDA2NDQKLS0tIGEvV2ViQ29yZS9DaGFuZ2VMb2cKKysrIGIvV2Vi Q29yZS9DaGFuZ2VMb2cKQEAgLTEsMyArMSwyMCBAQAorMjAxMC0wMS0yMiAgSmFtZXMgUm9iaW5z b24gIDxqYW1lc3JAY2hyb21pdW0ub3JnPgorCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAo T09QUyEpLgorCisgICAgICAgIERvIG5vdCBmaXJlIGZvY3VzIGV2ZW50cyB3aGlsZSBhIG1vZGFs IGRpYWxvZyBpcyB1cC4KKyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcu Y2dpP2lkPTMzOTYyCisKKyAgICAgICAgTW9kaWZpZXMgdGhlIEZvY3VzQ29udHJvbGxlciB0byBj aGVjayB0aGUgZnJhbWUncyBwYWdlJ3MgZGVmZXJzTG9hZGluZygpIGZsYWcgYmVmb3JlIGZpcmlu ZyBibHVyL2ZvY3VzIGV2ZW50cy4KKyAgICAgICAgVGhpcyBmbGFnIGlzIHNldCB3aGlsZSBhIG1v ZGFsIGRpYWxvZyAobGlrZSBhIHdpbmRvdy5hbGVydCBvciB3aW5kb3cuY29uZmlybSkgaXMgdXAu ICBGaXJpbmcgdGhlIGV2ZW50cyBjYXVzZXMKKyAgICAgICAgYXNzZXJ0aW9uIGZhaWx1cmVzLCBz aW5jZSB3aGVuIHRoZSBkaWFsb2cgaXMgZGlzbWlzc2VkIHRoZSBQYWdlR3JvdXBMb2FkRGVmZXJy ZXIgYXNzdW1lcyB0aGF0IG5vIHNjcmlwdAorICAgICAgICBoYXMgcnVuLgorCisgICAgICAgIE5v IG5ldyB0ZXN0cywgdGhlIHRlc3QgaW5mcmFzdHJ1Y3R1cmUgZG9lc24ndCBzdXBwb3J0IHRlc3Rz IHdpdGggbW9kYWwgZGlhbG9ncy4KKworICAgICAgICAqIHBhZ2UvRm9jdXNDb250cm9sbGVyLmNw cDoKKyAgICAgICAgKFdlYkNvcmU6OkZvY3VzQ29udHJvbGxlcjo6c2V0Rm9jdXNlZCk6CisKIDIw MTAtMDEtMjcgIFBhdmVsIEZlbGRtYW4gIDxwZmVsZG1hbkBjaHJvbWl1bS5vcmc+CiAKICAgICAg ICAgUmV2aWV3ZWQgYnkgVGltb3RoeSBIYXRjaGVyLgpkaWZmIC0tZ2l0IGEvV2ViQ29yZS9wYWdl L0ZvY3VzQ29udHJvbGxlci5jcHAgYi9XZWJDb3JlL3BhZ2UvRm9jdXNDb250cm9sbGVyLmNwcApp bmRleCA1ZTc4YzdkLi4yYmUxNzAwIDEwMDY0NAotLS0gYS9XZWJDb3JlL3BhZ2UvRm9jdXNDb250 cm9sbGVyLmNwcAorKysgYi9XZWJDb3JlL3BhZ2UvRm9jdXNDb250cm9sbGVyLmNwcApAQCAtMTEz LDcgKzExMyw5IEBAIHZvaWQgRm9jdXNDb250cm9sbGVyOjpzZXRGb2N1c2VkKGJvb2wgZm9jdXNl ZCkKICAgICAKICAgICBpZiAobV9mb2N1c2VkRnJhbWUgJiYgbV9mb2N1c2VkRnJhbWUtPnZpZXco KSkgewogICAgICAgICBtX2ZvY3VzZWRGcmFtZS0+c2VsZWN0aW9uKCktPnNldEZvY3VzZWQoZm9j dXNlZCk7Ci0gICAgICAgIGRpc3BhdGNoRXZlbnRzT25XaW5kb3dBbmRGb2N1c2VkTm9kZShtX2Zv Y3VzZWRGcmFtZS0+ZG9jdW1lbnQoKSwgZm9jdXNlZCk7CisgICAgICAgIC8vIERvIG5vdCBmaXJl IGV2ZW50cyB3aGlsZSBtb2RhbCBkaWFsb2dzIGFyZSB1cC4gIFNlZSBodHRwczovL2J1Z3Mud2Vi a2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MzM5NjIKKyAgICAgICAgaWYgKCFtX2ZvY3VzZWRGcmFt ZS0+cGFnZSgpLT5kZWZlcnNMb2FkaW5nKCkpCisgICAgICAgICAgICBkaXNwYXRjaEV2ZW50c09u V2luZG93QW5kRm9jdXNlZE5vZGUobV9mb2N1c2VkRnJhbWUtPmRvY3VtZW50KCksIGZvY3VzZWQp OwogICAgIH0KIH0KIAo= 49249 2010-02-22 17:11:48 -0800 2010-02-24 10:50:18 -0800 patch with manual tests b_33962_2.diff text/plain 3343 jamesr ZGlmZiAtLWdpdCBhL1dlYkNvcmUvQ2hhbmdlTG9nIGIvV2ViQ29yZS9DaGFuZ2VMb2cKaW5kZXgg OWFiOTFiOS4uM2M0ZDBjMiAxMDA2NDQKLS0tIGEvV2ViQ29yZS9DaGFuZ2VMb2cKKysrIGIvV2Vi Q29yZS9DaGFuZ2VMb2cKQEAgLTEsMyArMSwyMSBAQAorMjAxMC0wMi0yMiAgSmFtZXMgUm9iaW5z b24gIDxqYW1lc3JAY2hyb21pdW0ub3JnPgorCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAo T09QUyEpLgorCisgICAgICAgIERvIG5vdCBmaXJlIGZvY3VzIGV2ZW50cyB3aGlsZSBhIG1vZGFs IGRpYWxvZyBpcyB1cC4KKyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcu Y2dpP2lkPTMzOTYyCisKKyAgICAgICAgTW9kaWZpZXMgdGhlIEZvY3VzQ29udHJvbGxlciB0byBj aGVjayB0aGUgZnJhbWUncyBwYWdlJ3MgZGVmZXJzTG9hZGluZygpIGZsYWcgYmVmb3JlIGZpcmlu ZyBibHVyL2ZvY3VzIGV2ZW50cy4KKyAgICAgICAgVGhpcyBmbGFnIGlzIHNldCB3aGlsZSBhIG1v ZGFsIGRpYWxvZyAobGlrZSBhIHdpbmRvdy5hbGVydCBvciB3aW5kb3cuY29uZmlybSkgaXMgdXAu ICBGaXJpbmcgdGhlIGV2ZW50cyBjYXVzZXMKKyAgICAgICAgYXNzZXJ0aW9uIGZhaWx1cmVzLCBz aW5jZSB3aGVuIHRoZSBkaWFsb2cgaXMgZGlzbWlzc2VkIHRoZSBQYWdlR3JvdXBMb2FkRGVmZXJy ZXIgYXNzdW1lcyB0aGF0IG5vIHNjcmlwdCBoYXMgcnVuLgorCisgICAgICAgIE1hbnVhbCB0ZXN0 cyBvbmx5IGFzIER1bXBSZW5kZXJUcmVlIGRvZXMgbm90IHN1cHBvcnQgbW9kYWwgZGlhbG9ncwor CisgICAgICAgICogbWFudWFsLXRlc3RzL21vZGFsLWRpYWxvZy1ibHVyLXNlbGZjbG9zZS5odG1s OiBBZGRlZC4KKyAgICAgICAgKiBtYW51YWwtdGVzdHMvbW9kYWwtZGlhbG9nLWJsdXIuaHRtbDog QWRkZWQuCisgICAgICAgICogcGFnZS9Gb2N1c0NvbnRyb2xsZXIuY3BwOgorICAgICAgICAoV2Vi Q29yZTo6ZGlzcGF0Y2hFdmVudHNPbldpbmRvd0FuZEZvY3VzZWROb2RlKToKKwogMjAwOS0wMi0y MiAgQWRhbSBMYW5nbGV5ICA8YWdsQGdvb2dsZS5jb20+CiAKICAgICAgICAgUmV2aWV3ZWQgYnkg RGFyaW4gRmlzaGVyLgpkaWZmIC0tZ2l0IGEvV2ViQ29yZS9tYW51YWwtdGVzdHMvbW9kYWwtZGlh bG9nLWJsdXItc2VsZmNsb3NlLmh0bWwgYi9XZWJDb3JlL21hbnVhbC10ZXN0cy9tb2RhbC1kaWFs b2ctYmx1ci1zZWxmY2xvc2UuaHRtbApuZXcgZmlsZSBtb2RlIDEwMDY0NAppbmRleCAwMDAwMDAw Li5jNmIyZGE4Ci0tLSAvZGV2L251bGwKKysrIGIvV2ViQ29yZS9tYW51YWwtdGVzdHMvbW9kYWwt ZGlhbG9nLWJsdXItc2VsZmNsb3NlLmh0bWwKQEAgLTAsMCArMSwzIEBACis8c2NyaXB0Pgord2lu ZG93LmNsb3NlKCkKKzwvc2NyaXB0PgpkaWZmIC0tZ2l0IGEvV2ViQ29yZS9tYW51YWwtdGVzdHMv bW9kYWwtZGlhbG9nLWJsdXIuaHRtbCBiL1dlYkNvcmUvbWFudWFsLXRlc3RzL21vZGFsLWRpYWxv Zy1ibHVyLmh0bWwKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXggMDAwMDAwMC4uYmQ3MmFhNQot LS0gL2Rldi9udWxsCisrKyBiL1dlYkNvcmUvbWFudWFsLXRlc3RzL21vZGFsLWRpYWxvZy1ibHVy Lmh0bWwKQEAgLTAsMCArMSwzNCBAQAorPCFET0NUWVBFIGh0bWw+Cis8aHRtbD4KKzxoZWFkPjx0 aXRsZT4KK1Rlc3RzIGJsdXIvZm9jdXMgZXZlbnRzIHdpdGggbW9kYWwgZGlhbG9ncworPC90aXRs ZT48L2hlYWQ+Cis8c2NyaXB0PgordmFyIGZhaWxlZCA9ICIiOworZnVuY3Rpb24gZmFpbEJsdXIo KSB7CisgIGZhaWxlZCA9ICJibHVyIjsKK30KK2Z1bmN0aW9uIGZhaWxGb2N1cygpIHsKKyAgZmFp bGVkID0gImZvY3VzIjsKK30KKwordmFyIGlucHV0RWxlbWVudDsKKworZnVuY3Rpb24gdGVzdCgp IHsKKyAgaW5wdXRFbGVtZW50ID0gZG9jdW1lbnQuZ2V0RWxlbWVudEJ5SWQoImkiKQorICBpbnB1 dEVsZW1lbnQuZm9jdXMoKTsKKyAgaW5wdXRFbGVtZW50LmFkZEV2ZW50TGlzdGVuZXIoImJsdXIi LCBmYWlsQmx1ciwgZmFsc2UpOworICBpbnB1dEVsZW1lbnQuYWRkRXZlbnRMaXN0ZW5lcigiZm9j dXMiLCBmYWlsRm9jdXMsIGZhbHNlKTsKKyAgd2luZG93LnNob3dNb2RhbERpYWxvZygibW9kYWwt ZGlhbG9nLWJsdXItc2VsZmNsb3NlLmh0bWwiKTsKKyAgaWYgKGZhaWxlZCkgeworICAgIGRvY3Vt ZW50LmdldEVsZW1lbnRCeUlkKCJzdGF0dXMiKS5pbm5lckhUTUwgPSAiRkFJTCwgIiArIGZhaWxl ZDsKKyAgfSBlbHNlIHsKKyAgICBkb2N1bWVudC5nZXRFbGVtZW50QnlJZCgic3RhdHVzIikuaW5u ZXJIVE1MID0gIlNVQ0NFU1MiOworICB9Cit9Cis8L3NjcmlwdD4KKzxib2R5IG9ubG9hZD0idGVz dCgpIj4KKzxpbnB1dCBpZD0iaSI+PC9pbnB1dD4KKzxkaXYgaWQ9InN0YXR1cyI+UlVOTklORy4u LjwvZGl2PgorPC9ib2R5PgorPC9odG1sPgpkaWZmIC0tZ2l0IGEvV2ViQ29yZS9wYWdlL0ZvY3Vz Q29udHJvbGxlci5jcHAgYi9XZWJDb3JlL3BhZ2UvRm9jdXNDb250cm9sbGVyLmNwcAppbmRleCBi ZGQzMTUxLi4yMTc3OWY5IDEwMDY0NAotLS0gYS9XZWJDb3JlL3BhZ2UvRm9jdXNDb250cm9sbGVy LmNwcAorKysgYi9XZWJDb3JlL3BhZ2UvRm9jdXNDb250cm9sbGVyLmNwcApAQCAtNjEsNiArNjEs MTAgQEAgc3RhdGljIGlubGluZSB2b2lkIGRpc3BhdGNoRXZlbnRzT25XaW5kb3dBbmRGb2N1c2Vk Tm9kZShEb2N1bWVudCogZG9jdW1lbnQsIGJvb2wKICAgICAvLyBJZiB3ZSBoYXZlIGEgZm9jdXNl ZCBub2RlIHdlIHNob3VsZCBkaXNwYXRjaCBibHVyIG9uIGl0IGJlZm9yZSB3ZSBibHVyIHRoZSB3 aW5kb3cuCiAgICAgLy8gSWYgd2UgaGF2ZSBhIGZvY3VzZWQgbm9kZSB3ZSBzaG91bGQgZGlzcGF0 Y2ggZm9jdXMgb24gaXQgYWZ0ZXIgd2UgZm9jdXMgdGhlIHdpbmRvdy4KICAgICAvLyBodHRwczov L2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MjcxMDUKKyAgCisgICAgLy8gRG8gbm90 IGZpcmUgZXZlbnRzIHdoaWxlIG1vZGFsIGRpYWxvZ3MgYXJlIHVwLiAgU2VlIGh0dHBzOi8vYnVn cy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0zMzk2MgorICAgIGlmIChkb2N1bWVudC0+cGFn ZSgpLT5kZWZlcnNMb2FkaW5nKCkpCisgICAgICAgIHJldHVybjsKICAgICBpZiAoIWZvY3VzZWQg JiYgZG9jdW1lbnQtPmZvY3VzZWROb2RlKCkpCiAgICAgICAgIGRvY3VtZW50LT5mb2N1c2VkTm9k ZSgpLT5kaXNwYXRjaEJsdXJFdmVudCgpOwogICAgIGRvY3VtZW50LT5kaXNwYXRjaFdpbmRvd0V2 ZW50KEV2ZW50OjpjcmVhdGUoZm9jdXNlZCA/IGV2ZW50TmFtZXMoKS5mb2N1c0V2ZW50IDogZXZl bnROYW1lcygpLmJsdXJFdmVudCwgZmFsc2UsIGZhbHNlKSk7Cg==