22261 2008-11-14 04:15:14 -0800 Clicking on a non-text input element does not give it focus 2026-04-19 19:28:11 -0700 1 1 1 Unclassified WebKit Forms 525.x (Safari 3.1) PC Windows Server 2003 RESOLVED WONTFIX https://bugs.webkit.org/show_bug.cgi?id=112968 https://bugs.webkit.org/show_bug.cgi?id=18425 https://bugs.webkit.org/show_bug.cgi?id=267569 https://bugs.webkit.org/show_bug.cgi?id=283276 https://bugs.webkit.org/show_bug.cgi?id=281209 https://bugs.webkit.org/show_bug.cgi?id=312692 P2 Normal --- 229895 290463 299087 26856 267449 296989 302673 1 mike.capp webkit-unassigned 04-punch-pinyons aaron adele akeerthi alex.wayfer anantha andrzej.doyle andy.blum.01 ap arne aroben arv browserbugs2 bugs.webkit.org bugzilla bweinstein darin dave.batiste dawagner dieter dohlsen dsuchkov511 emilio eric giovanni.piller hausmann hedgerwang jab_creations jasneet karlcow kenneth kizmarh koivisto laszlo.gombos leviw manish3177 martyn.chamberlin matzew m.goleb+bugzilla mijordan mitz mjs priyajeet.hora proskater55 raphael redux rego rniwa sporter tonikitoo webkit wesleydesouza oldest_to_newest 98769 0 mike.capp 2008-11-14 04:15:14 -0800 Expected behavior: * clicking on a button should give it focus and raise the onfocus event Actual behavior: * clicking on a button DOES NOT give it focus or raise an onfocus event * clicking on a button when another element has focus DOES blur that element * tabbing to a button DOES give it focus Possibly related: * Bug 18425 (similar issue for hyperlinks) * Bug 19104 (similar issue for radio/checkbox inputs) * Bug 20138 (similar issue for file inputs) Issue also present in Google Chrome 0.3.154.9 Demo attachment to follow. 98770 1 25169 mike.capp 2008-11-14 04:19:32 -0800 Created attachment 25169 page demonstrating bug 99154 2 andrzej.doyle 2008-11-18 06:19:09 -0800 Confirming that I can reproduce this in both Safari 3.1.2 (525.21), and Google Chrome 0.3.154.9. 125835 3 browserbugs2 2009-06-14 15:28:42 -0700 I also confirm this bug. It still happens in latest stable release Safari 4.0 build 530.17. Focused <input type="button" ...> with mouse-clicking does not render outline borders. This also affects CSS rules like: input:focus { outline-width: 4px; outline-style: solid; outline-color: red; } A good testcase for this bug is http://www.gtalbot.org/DHTMLSection/AdvancedCSSButtons.html regards, Gérard 138303 4 dawagner 2009-08-08 03:16:44 -0700 Confirm still a problem in Safari 4.0 540.17 and Google Chrome 3.0.197.11 (Official Build 22553)... 150526 5 40241 ostap73 2009-09-28 09:25:11 -0700 Created attachment 40241 Fix for the html elements not focused by mouse It appears that this bug is fixed already for GTK build. I suggest to take this fix into all versions by removing GTK #ifdef. 150542 6 40241 darin 2009-09-28 09:53:58 -0700 Comment on attachment 40241 Fix for the html elements not focused by mouse This is wrong for Mac OS X at least, so please don't check this in without further discussion. This might need to be discussed on the webkit-dev mailing list rather than just in this bug. Also, this patch has no change log or test case, so it needs to be review- in any case. 150560 7 ostap73 2009-09-28 10:51:23 -0700 (In reply to comment #6) > (From update of attachment 40241 [details]) > This is wrong for Mac OS X at least, Have tried it on Mac. Good test page http://testsuite.nokia-boston.com/content/xhtml_forms/text_input/form_input.xhtml 1. Radio buttons and check boxes are not focusable by mouse 2. Radio buttons and check boxes also not focusable through tabbed browsing. Weird! It's different from all other browsers. So, radio buttons and check box lists are some special exceptions? > so please don't check this in without further discussion. Yes, that's what I want. > This might need to be discussed on the webkit-dev mailing > list rather than just in this bug. Could you start this discussion? I hope this way it will attract more attention. > Also, this patch has no change log I never hoped that this will go as it is. It just to start the discussion. > or test case, Isn't it so, that tests attached to the bug are also tests for the fix? In any case, here is good test page: http://testsuite.nokia-boston.com/content/xhtml_forms/text_input/form_input.xhtml > so it needs to be review- in any case. That's Ok. 1st I need to figure out what is correct behavior in this case. My impression now, that #if PLATFORM(GTK) should be changed to #if PLATFORM(MAC) return false; #else return HTMLElement::isMouseFocusable(); #endif 151336 8 40393 ostap73 2009-09-30 13:03:48 -0700 Created attachment 40393 Fix for the html elements not focused by mouse. 151338 9 40394 ostap73 2009-09-30 13:06:52 -0700 Created attachment 40394 Fix for the html elements not focused by mouse. Previous diff is wrong. 151928 10 40394 eric 2009-10-02 12:22:53 -0700 Comment on attachment 40394 Fix for the html elements not focused by mouse. All changes require tests. Otherwise this looks fine. http://webkit.org/coding/contributing.html http://trac.webkit.org/wiki/Writing%20Layout%20Tests%20for%20DumpRenderTree http://trac.webkit.org/wiki/Creating%20and%20Submitting%20Layout%20Tests%20and%20Patches 190671 11 team.dave 2010-02-16 05:17:15 -0800 this is still a bug even today in google chrome 5.0.322.2 dev somebody posted a fix below - any news when it will be implemented? 211878 12 53227 ostap73 2010-04-12 23:50:10 -0700 Created attachment 53227 Fix with layout test. 211952 13 tonikitoo 2010-04-13 07:57:05 -0700 ostapenko, did I missing something or LayoutTests/platform/qt/fast/events/click-focus-control-expected.txt and LayoutTests/fast/events/click-focus-control-expected.txt are equal? if so, you only need the latter. 211989 14 53258 ostap73 2010-04-13 10:07:23 -0700 Created attachment 53258 Fix update 229919 15 56930 ostap73 2010-05-24 14:49:07 -0700 Created attachment 56930 Add comment to Changelog. 230237 16 tonikitoo 2010-05-25 06:03:56 -0700 Patch makes Mac the only port where html elements are non-mouse-focusable, which seems reasonable. So although patch LGTM, I would rather ask in the mailing list first if there are other ports interested in keeping the current behaviour, e.g. Chromium and Qt on Mac (?) for consistency. also, adding ap as a potential reviewer. 231858 17 ap 2010-05-28 12:07:11 -0700 +# Mac shouldn't focus on some control elements +# https://bugs.webkit.org/show_bug.cgi?id=22261 +fast/events/click-focus-control.html The test should have Mac-specific results then, to guarantee that this doesn't regress. I'm not sure how to decide where this is desirable. I'd expect Windows Safari to behave the same as Mac Safari does. And maybe Mac versions of all WebKit-based browsers. Or perhaps all WebKit based browsers should work the same - there is no discussion of actual user facing problems here, so I'm not sure what exactly needs to be fixed. 232894 18 ostap73 2010-06-01 12:11:20 -0700 (In reply to comment #17) > +# Mac shouldn't focus on some control elements > +# https://bugs.webkit.org/show_bug.cgi?id=22261 > +fast/events/click-focus-control.html > > The test should have Mac-specific results then, to guarantee that this doesn't regress. Ok. Do I have to add MAC specific ...-expected.txt to MAC folder? > I'm not sure how to decide where this is desirable. > I'd expect Windows Safari to behave the same as Mac Safari does. Actually, this bug is reported against windows safari ;) And I find somewhat weird, that some UI elements are "more equal" than others on MAC. Why some elements can be focused and some not? There was similar issue with keyboard tab stops on MAC (for all dialogs), but recently it was fixed and now it is possible to enable "Full Keyboard Access". > And maybe Mac versions of all WebKit-based browsers. > Or perhaps all WebKit based browsers should work the same There is an opinion, that html control elements should work the same on all platforms (at least for qtwebkit). > - there is no discussion of actual user facing problems here, so I'm not sure what exactly needs to be fixed. There are several reports about the same issue here, so I think there is an issue. 232902 19 ap 2010-06-01 12:26:50 -0700 > There are several reports about the same issue here, so I think there is an issue. OK, so what the issue is? Is it just being different from other browsers, or causing problems to users? Are there any sites affected? 232918 20 dawagner 2010-06-01 12:54:49 -0700 The problem is just different behaviour to other browsers - affects Chrome and Safari on Windows where this is definitely not the expected behaviour. 232940 21 laszlo.gombos 2010-06-01 13:49:51 -0700 From this comment it seems that the original intention was just to create a different behavior for Safari on the MAC. <<In Safari we don't want to take the focus away from a text field when we click on, say, a form button. But I suspect this could be something specific to Macintosh, so I am leaving this code here inside !APPLE_CHANGES. This will probably change when we do more of the keyboard navigation work.>> This changeset - http://trac.webkit.org/changeset/5345 factored the APPLE_CHANGES guard out and lost the original intention to make this change only for MAC. 237219 22 kenneth 2010-06-11 19:02:28 -0700 Any update on this? Antonio, is this slightly related to what you have been working on? like the editing behaviour that is also different for each platform? 237794 23 tonikitoo 2010-06-14 06:29:51 -0700 (In reply to comment #22) > Any update on this? Antonio, is this slightly related to what you have been working on? like the editing behaviour that is also different for each platform? I think it can be a platform specific editing behavior, yes. Darin, Ojan, what do you think? 238133 24 darin 2010-06-14 16:37:40 -0700 Making this a Mac vs. Windows difference could lead to websites that work only on Mac or only on Windows. So it’s undesirable. But generally speaking, clicking on a button on Mac OS X does not focus that button. 238137 25 ostap73 2010-06-14 16:48:38 -0700 (In reply to comment #24) > Making this a Mac vs. Windows difference could lead to websites that work only on Mac or only on Windows. So it’s undesirable. What about other browsers? Only webkit based browsers have this kind of behavior. > But generally speaking, clicking on a button on Mac OS X does not focus that button. But other platforms do focus. And this was initial behavior here, as I understand, and later #ifdef was lost. 238138 26 darin 2010-06-14 16:50:14 -0700 (In reply to comment #25) > (In reply to comment #24) > > But generally speaking, clicking on a button on Mac OS X does not focus that button. > > But other platforms do focus. Yes. > And this was initial behavior here, as I understand, and later #ifdef was lost. Don’t read too much into the #ifdef. At first, every single WebKit change had APPLE_CHANGES around it. 239012 27 ojan 2010-06-16 12:02:14 -0700 (In reply to comment #24) > Making this a Mac vs. Windows difference could lead to websites that work only on Mac or only on Windows. So it’s undesirable. > > But generally speaking, clicking on a button on Mac OS X does not focus that button. I agree that making this a Mac vs. Win/Linux difference is undesirable. It's not clear to me what conclusion to draw from that though. Every other browser, including Firefox-Mac and Opera-mac, focuses buttons on mousedown. For the sake of compatibility with other browsers, I think we should make buttons mouse focusable. Otherwise, we put a burden on web developers to send WebKit down a different codepath. It's hard to find sites that break due to this because they'll often work around it. For example, Gmail used to have code to work around this before they moved to div-based buttons. I'm sure other sites have the same. Consistency with other browsers seems like a sufficient argument to me. 239128 28 darin 2010-06-16 15:54:40 -0700 (In reply to comment #27) > Every other browser, including Firefox-Mac and Opera-mac, focuses buttons on mousedown. OK, I think we can live with it in future Safari. Now we just need to deal with that other issue, Safari has done it this way for 8 years so there’s a good chance sites have Safari-specific code paths depending on the old behavior. And this goes even more for things like Dashboard. So ... we have to find out if that’s true and figure out what to do about it. This comes up often in the WebKit project, so there is some understanding about how to make changes like this. We need some time and some testing to find out if we can just completely drop the old behavior or if we need it in some places. 247205 29 tonikitoo 2010-07-06 14:01:22 -0700 fwiw, spun off Qt only bug is bug 40641 255037 30 ojan 2010-07-22 16:04:12 -0700 > This comes up often in the WebKit project, so there is some understanding about how to make changes like this. We need some time and some testing to find out if we can just completely drop the old behavior or if we need it in some places. Darin, just checking back in on this. Is this still on someone's TODO list? 255088 31 darin 2010-07-22 17:15:30 -0700 (In reply to comment #30) > Darin, just checking back in on this. Is this still on someone's TODO list? Maybe there’s a misunderstanding. I don’t think I said it was on anyone’s to do list. 255106 32 ojan 2010-07-22 17:41:22 -0700 > Maybe there’s a misunderstanding. I don’t think I said it was on anyone’s to do list. Yup, there is a misunderstanding. :) Can you describe what you had in mind in comment 28 for testing whether we can make this change? I'm just trying to understand how to move this forward. 255149 33 darin 2010-07-22 18:53:31 -0700 (In reply to comment #32) > > Maybe there’s a misunderstanding. I don’t think I said it was on anyone’s to do list. > > Yup, there is a misunderstanding. :) Can you describe what you had in mind in comment 28 for testing whether we can make this change? I'm just trying to understand how to move this forward. Someone working on WebKit needs to do some research to see if Dashboard widgets are affected by the change. And do some additional research to see if there are websites depending on the old behavior. Anyone with a Mac can also get the widgets at <http://www.apple.com/downloads/dashboard/>. Some people may have a way to do research on what sites on the web might be affected. I’ve heard that Google has some tools that might help with this sort of research. 255491 34 ojan 2010-07-23 11:46:42 -0700 > Someone working on WebKit needs to do some research to see if Dashboard widgets are affected by the change. And do some additional research to see if there are websites depending on the old behavior. Is there any documentation on how to test Dashboard widgets with a local WebKit build? > Some people may have a way to do research on what sites on the web might be affected. I’ve heard that Google has some tools that might help with this sort of research. The only tool I know of for this sort of thing is a instrumented Chrome with and without a given patch that loads web pages and looks for "significant" layout differences. I don't think it would work for this since it requires mouse interaction. I'll try and make some time to do this testing (or find someone who can). 292119 35 simon.fraser 2010-10-09 08:29:53 -0700 *** Bug 19104 has been marked as a duplicate of this bug. *** 292328 36 56930 abarth 2010-10-10 11:15:36 -0700 Comment on attachment 56930 Add comment to Changelog. The change to mac/Skipped is wrong. Also this patch is blocked on compat testing. 293384 37 tonikitoo 2010-10-13 06:17:52 -0700 This bug should not block QtWebKit 2.0 tracker bug. 331267 38 ap 2011-01-08 14:03:24 -0800 *** Bug 18425 has been marked as a duplicate of this bug. *** 331269 39 ap 2011-01-08 14:03:31 -0800 *** Bug 52102 has been marked as a duplicate of this bug. *** 331273 40 ap 2011-01-08 14:04:55 -0800 *** Bug 22233 has been marked as a duplicate of this bug. *** 331303 41 priyajeet.hora 2011-01-08 15:23:33 -0800 Any updates on this issue and what has the conclusion been to get this fixed? Since we are in the realm of browsers, isn't it better to be consistent whenever possible with the prevailing majority (assuming logically-correct behavior of course)? Right now I notice that hyperlinks and inputs etc get focus in IE and FF and opera irrespective of the platform, however Chrome and Safari on either platform don't. I just hope this issue is not ignored because Safari on mac had a behavior X that is dictating the same behavior on other platforms and Chrome. As for imapact, I think focusing on hyperlinks (Bug 18425) would be useful and :focus working. As people will notice with CSS3 becoming more popular, lot of website have started using <a> decorated with css as buttons. Events being fired properly will help developers just in case they are doing something when this type of button gets focused. Some other site issues http://code.google.com/p/chromium/issues/detail?id=42157 426735 42 dbates 2011-06-23 22:45:21 -0700 *** Bug 63299 has been marked as a duplicate of this bug. *** 428336 43 leviw 2011-06-27 14:54:25 -0700 FWIW, Bug 38696 is similar, and similarly stalled on testing I'm not sure how exactly to do. 702051 44 rniwa 2012-08-22 10:46:50 -0700 Related issue: http://code.google.com/p/chromium/issues/detail?id=142188 Maybe we need to tie this due to editing behavior. I'm pretty certain we want it be focusable on all non-Mac platforms. 721539 45 mjs 2012-09-15 21:46:29 -0700 (In reply to comment #44) > Related issue: http://code.google.com/p/chromium/issues/detail?id=142188 > > Maybe we need to tie this due to editing behavior. I'm pretty certain we want it be focusable on all non-Mac platforms. Perhaps it should depend on tab-focus policy. My feeling is that this behavior is appropriate if and only if buttons are tab-focusable. In Safari on Mac (and probably other Mac browsers) they are not by default, but can be set to be in the tab cycle (via both System Preferences and Safari Preferences). 734895 46 ojan 2012-10-04 11:47:58 -0700 (In reply to comment #45) > (In reply to comment #44) > > Related issue: http://code.google.com/p/chromium/issues/detail?id=142188 > > > > Maybe we need to tie this due to editing behavior. I'm pretty certain we want it be focusable on all non-Mac platforms. > > Perhaps it should depend on tab-focus policy. My feeling is that this behavior is appropriate if and only if buttons are tab-focusable. In Safari on Mac (and probably other Mac browsers) they are not by default, but can be set to be in the tab cycle (via both System Preferences and Safari Preferences). So, to be clear, you're disagreeing with Darin's preference to avoid Mac vs Windows differences? I'm OK with making this a Setting. I'd rather do that than an editing behavior since Chrome will want to do this on Mac as well. FWIW, here's another bug report we've received about how this causes web developers difficulties: "I have a div which is set to -webkit-user-modify: read-write. When i place my cursor in the div, it gets focus and indeed accepts input. When I tap outside of the div, I get a blur event on the div, and lose focus. So far so good and as expected. If I however tap on a button which is outside of the div, then I do get a blur event, yet my cursor remains on screen and indeed continues to accept input. Even though the div now no longer has focus (it even loses the blue focus border). I've attached a quick demo html to this email. My code had assumed that when my content editable div loses focus (receives a blur), then I stop listening for DOM Mutations. Clearly, if it still can receive input even when it hasn't got focus that means my code is broken. Is this is a bug, or should I somehow use something else than the blur event to determine when my div will stop accepting input ?" 734904 47 rniwa 2012-10-04 11:53:12 -0700 (In reply to comment #46) > If I however tap on a button which is outside of the div, then I do get a blur event, yet my cursor remains on screen and indeed continues to accept input. Even though the div now no longer has focus (it even loses the blue focus border). I've attached a quick demo html to this email. > > My code had assumed that when my content editable div loses focus (receives a blur), then I stop listening for DOM Mutations. Clearly, if it still can receive input even when it hasn't got focus that means my code is broken. Is this is a bug, or should I somehow use something else than the blur event to determine when my div will stop accepting input ?" This is not caused by this bug. The focus has moved. The selection hasn't. See https://bugs.webkit.org/show_bug.cgi?id=38696 and https://bugs.webkit.org/show_bug.cgi?id=61310. 734912 48 ojan 2012-10-04 12:02:27 -0700 (In reply to comment #47) > This is not caused by this bug. The focus has moved. The selection hasn't. See https://bugs.webkit.org/show_bug.cgi?id=38696 and https://bugs.webkit.org/show_bug.cgi?id=61310. I suppose there are multiple bugs here. document.activeElement points to the body, not the button after the click. The focus moved, but not to the button. That said, I agree that fixing the other two bugs would address that issue. 734925 49 mjs 2012-10-04 12:24:02 -0700 (In reply to comment #46) > (In reply to comment #45) > > (In reply to comment #44) > > > Related issue: http://code.google.com/p/chromium/issues/detail?id=142188 > > > > > > Maybe we need to tie this due to editing behavior. I'm pretty certain we want it be focusable on all non-Mac platforms. > > > > Perhaps it should depend on tab-focus policy. My feeling is that this behavior is appropriate if and only if buttons are tab-focusable. In Safari on Mac (and probably other Mac browsers) they are not by default, but can be set to be in the tab cycle (via both System Preferences and Safari Preferences). > > So, to be clear, you're disagreeing with Darin's preference to avoid Mac vs Windows differences? I'm OK with making this a Setting. I'd rather do that than an editing behavior since Chrome will want to do this on Mac as well. My suggestion is not to make it any of a hardcoded Mac vs Windows difference, a Setting, or an editing behavior. My suggestion is that non-text form controls such as buttons should be focusable by click if and only if they are focusable in the tab cycle. And likewise for links. This could be achieved by making HTMLFormControlElement::isMouseFocusable() check document()->frame()->eventHandler()->tabsToAllFormControls(), which has platform-specific implementations, some of which always return true, and others of which (Mac in particular) make it a runtime setting and others which might return always false. For clarity it may make sense to add EventHandler::allFormControlsAcceptMouseFocus() which just calls tabsToAllFormControls. It is true that this will create a web-content-observable difference that is partly a platform difference. However, we already have such a difference for tab-focus. It seems sensible to me to make mouse-focus consistent with tab-focus, even though it slightly expands the scope of the difference. This would also allow removing the hardcoded special case for Gtk and Qt. [...snip specific issue report because I agree with Ryosuke that it's actually a different bug...] 798397 50 ap 2012-12-31 19:16:46 -0800 *** Bug 105690 has been marked as a duplicate of this bug. *** 899246 51 manish3177 2013-06-11 12:03:25 -0700 It's been 4.5 years since this bug was first reported. Presumably the fix is simple (I looked at the patch) but it seems Apple folks (Darian, Alexey, etc.) can't agree to it and the debate is still going on. Let me make another pitch for it: This makes webkit different from everything else on Windows. I don't care about Safari on Mac or Windows but sadly this affects Chrome on Windows, which I do care about. See comment #20 from Daniel. I strongly urge the Apple folks to be a little open minded about this. It DOES affect end users. This was apparently not the behavior in the original webkit but it was inadvertently introduced due to "code cleanup". See comment #21 from Lazlo. Regarding the option to make it configurable (comment #49 from Maciej), that would work as long as the default on Windows is the behavior that is being asked for. Obviously, the Apple group doesn't want that default for Mac, so the default will have to be conditionally compiled. So that would essentially make the configuration choice pointless because no one would bother changing it. 899249 52 ap 2013-06-11 12:11:15 -0700 Chrome has forked WebKit, and they have a separate bug database now. If you only care about Chrome, then WebKit bug database is not the right place for advocacy. 899250 53 arv 2013-06-11 12:13:24 -0700 Manish: We are fixing this in Blink https://code.google.com/p/chromium/issues/detail?id=89708 https://codereview.chromium.org/16194013/ 899610 54 manish3177 2013-06-12 10:21:11 -0700 (In reply to comment #53) > Manish: We are fixing this in Blink > > https://code.google.com/p/chromium/issues/detail?id=89708 > https://codereview.chromium.org/16194013/ That's really good to hear. I look forward to the fix and will keep an eye on it. Thanks for the update, Eric. 1707518 55 bugs.webkit.org 2020-11-14 11:12:25 -0800 I know it has been a while but... any update or clear status for this strange bug? 1712586 56 martyn.chamberlin 2020-12-07 13:40:38 -0800 It's nothing short of bizarre that this bug is more than 12 years old and yet still plagues Safari. This is resulting in places that we would prefer using `display: flex` to instead be obliged to use `display: grid`. Someone please tell me that they're working on fixing this. 1744780 57 dave.batiste 2021-03-29 10:56:21 -0700 Adding my vote that it's pretty terrible that this behavior is different than the rest of the browsers, going on 13 years. It would seem that this bug makes the recent for for ":focus-visible" pointless in Safari. Having to find work-arounds for components that rely on the focus not arbitrarily moving to the body when a user clicks a button. This bug is forcing people to do hacky things. Is their any intention of fixing this? 1750567 58 rego 2021-04-15 04:15:45 -0700 (In reply to Dave from comment #57) > Adding my vote that it's pretty terrible that this behavior is different > than the rest of the browsers, going on 13 years. It would seem that this > bug makes the recent for for ":focus-visible" pointless in Safari. Having to > find work-arounds for components that rely on the focus not arbitrarily > moving to the body when a user clicks a button. This bug is forcing people > to do hacky things. Is their any intention of fixing this? I believe that if we use :focus-visible in the default UA stylesheet, then we could make buttons focusable even on Mac platform, as they won't be showing any focus ring (which I understand it's something people want to avoid). This will differ from the general Mac platform behavior somehow, but will align us with other browsers (Firefox has recently changed this in Mac too). Also current WebKit behavior on Mac (e.g. an <input> loses focus when you click a <button>) doesn't match exactly what happens in the Mac platform (see https://bugzilla.mozilla.org/show_bug.cgi?id=1699570#c1). 1750796 59 rniwa 2021-04-15 15:27:35 -0700 (In reply to Manuel Rego Casasnovas from comment #58) > (In reply to Dave from comment #57) > > Adding my vote that it's pretty terrible that this behavior is different > > than the rest of the browsers, going on 13 years. It would seem that this > > bug makes the recent for for ":focus-visible" pointless in Safari. Having to > > find work-arounds for components that rely on the focus not arbitrarily > > moving to the body when a user clicks a button. This bug is forcing people > > to do hacky things. Is their any intention of fixing this? > > I believe that if we use :focus-visible in the default UA stylesheet, then > we could make buttons focusable even on Mac platform, as they won't be > showing any focus ring (which I understand it's something people want to > avoid). Not really. Buttons can't be focused via keyboard by default, for example, and it's non-sensical for a button to have a focus. That's not really a thing on macOS unless you change the system preferences. 1760701 60 gsnedders 2021-05-17 02:18:34 -0700 *** Bug 20138 has been marked as a duplicate of this bug. *** 1760704 61 gsnedders 2021-05-17 02:52:07 -0700 *** Bug 118043 has been marked as a duplicate of this bug. *** 1760986 62 rniwa 2021-05-17 18:21:30 -0700 This is behaving as intended. 1762955 63 rniwa 2021-05-23 13:48:47 -0700 *** Bug 26856 has been marked as a duplicate of this bug. *** 1763265 64 ap 2021-05-24 15:02:45 -0700 *** Bug 226148 has been marked as a duplicate of this bug. *** 1763291 65 jab_creations 2021-05-24 15:48:41 -0700 I recently came across this bug and posted report: https://bugs.webkit.org/show_bug.cgi?id=226148 It seems that the prevailing gate keepers attitude is that Safari is an operating system, not a browser that must adhere to consistent behavior and standards. There was another browser like that though I can't seem to remember it's name... The primary point is that a successful product or service does what it's users need. When people in leadership positions fail to comprehend that most fundamental aspect of usability those products and services fail. 1763293 66 darin 2021-05-24 15:50:54 -0700 (In reply to John A. Bilicki III from comment #65) > It seems that the prevailing gate keepers attitude is that Safari is an > operating system What? No. > When people in leadership positions fail to comprehend that most > fundamental aspect of usability those products and services fail. Could you be more specific? I think you are saying that you don’t agree that Safari should match how focus works on Mac and instead needs to match how focus works on Windows? How does that makes Safari an operating system? 1763312 67 jab_creations 2021-05-24 16:24:21 -0700 > When people in leadership positions fail to comprehend that most > fundamental aspect of usability those products and services fail. >Could you be more specific? Safari is not accessible; most designers and developers who don't own one to simply test Safari (I do, though I still don't have text labels on the GUI buttons or even a Reload button that I could at least have to go out of my way to enable for crying out loud so why would I willingly use it). They're wildly expensive considering not only the markup on the hardware though also the inability to customize the GUI or to be more precise without spending even more money. This removes incentives for many designers and developers to buy Apple products. So when those websites break those designers and developers do not care because if they do care about something it's about creating consistent behavior with the hardware and software that they do have access to. And that is for those trying to build websites don't just give up, abandon their customers and go in to something unrelated like selling insurance. That isn't how you create brand loyalty, that is how you create a cult, one that will one day be very easily convertible. > How does that makes Safari an operating system? No, Safari is a browser - the attitude of the gatekeepers here is to treat Safari like the operating system with it's limiting attitudes. In this situation the only proper thing to do is make the browser consistent in behavior, that is the point of cross-browser consistency. The attitudes could be constructively channeled in to creating an opt-in option to make Safari non-consistent with other browsers though consistent with the operating system. Besides, most importantly - what is the benefit of not focusing a button? That is literal anti-accessibility. The point of my bug report was to make my web platform extremely accessible to my users. The example was having 50 out of 100 email messages test messages that I just want to delete and obviously the check-all checkbox isn't a viable option in such a scenario. I wrote a script that when you press the up or down array key after clicking a checkbox would navigate to the next checkbox above or below and change it's checked state to that of the previous checkbox - absolutely genius as it's much faster, accurate and most importantly saves time! Most people don't want to have to battle their computer to do something simple in their minds, they have lives or are at least battling to get their lives on track. There are literally groups of people dedicated towards accessibility and usability literally telling whoever the gatekeepers are here for the past 13+ years at this point that the end user who actually uses products or services is more important than some snob's attitude who presumes that because they wouldn't use it that no one would. If you drive then you know that most other people are idiots. So yes, other people DO things that you wouldn't, though you might be the fool with five lanes though still blocking incoming traffic from on-ramps doing 15 slower than everyone else creating dangerous scenarios all in the name of driving "slow is safe". I've only had my success not by being wrong though by becoming aware of when I'm wrong. When someone wants to do something that I don't understand on my platform I resolve to know if it ultimately serves a use to someone that allows them to accomplish something even if I would never personally find any use for such a scenario. My goal is to make other people's lives better and the idea that I know all or that my personal preferences are somehow the end-all-be-all is not an attitude I tolerate, most especially in myself. So the choice is simple: either do what people need and want or continue to enforce the ivory tower attitude. 1763396 68 darin 2021-05-24 19:56:15 -0700 (In reply to John A. Bilicki III from comment #67) > what is the benefit of not focusing a button? This is the benefit: Mac users expect the focus to remain in the text field if you click on a button. That’s what happens everywhere else on their computer in all the Mac applications. It’s a benefit that buttons work as expected, consistent with other buttons on the Mac, and don't pull the focus away from the text field you are already typing in. I understand that if you’ve never used a Mac you might not be aware that this is a benefit, but I assure you that it is. If I understand your argument correctly, reading through and trying not to be offended by the repeated accusations of bad faith, bad intentions, and insufficient empathy for our fellow human beings, you are saying that this choice makes it impossible to make websites work accessibly, and is simply an expression of arrogance and bad decision making and a lack of care for other people. That’s not our intent. We’d like this to fit in well with other Mac software. 1763413 69 jab_creations 2021-05-24 20:27:34 -0700 > I understand that if you’ve never used a Mac you might not be aware that this is a benefit, but I assure you that it is. Please share an easy to comprehend example of how having the focus remain on a previous element after clicking on another is somehow beneficial, especially when it creates an inconsistent behavior between browsers when the topic if explicitly NOT about operating systems. I have an overpriced two-core 8GB under-powered Mac Mini from 2014 (released after they had already released quad cores as the lowest cost Mac Mini previously) that still did not include an SSD while costing minimally twice the price of better equipped PCs that I can test everything on though can not physically upgrade. Also, please tell me how (if when my mouse stops working and I only have a keyboard at my immediate disposal) that not being able to activate buttons because buttons can't be focused somehow helps me? > That’s not our intent. We’d like this to fit in well with other Mac software. I get wanting to have things fit well as an overall platform - I'm the solo-founder of an entire platform myself. The problem: we're talking about browser consistency, not operating systems. Your platform isn't easily accessible due to it's high cost and low compatibility - I don't have the option to operate a Mac the way *I* need to operate the Mac and therefore at best I simply use it to test Safari. Most people don't start out with a Mac just laying around and these inconsistencies will Microsoft's near-monopolist market share reduce the overall user experience on Macs. I absolutely get the seething hatred towards Microsoft and their ... antics however if you believe in creating a successful product or service that competes with counterparts such as other browsers it needs to have meet standards and have consistent behavior. 1763477 70 browserbugs2 2021-05-25 05:07:24 -0700 (In reply to Darin Adler from comment #68) > Mac users expect the focus to remain in the text field if you click on a > button. That’s what happens everywhere else on their computer in all the Mac > applications. It’s a benefit that buttons work as expected, consistent with > other buttons on the Mac, and don't pull the focus away from the text field > you are already typing in. Thank you for explaining this. I had no idea about this. What about button-type input or HTML buttons which are not related to a textfield? Epiphany 3.32.1.2 (which uses WebKitGTK+ 2.30.6) under Linux focuses button-type input: http://www.gtalbot.org/DHTMLSection/AdvancedCSSButtons.html What about radio buttons and check boxes? from #c7: > 1. Radio buttons and check boxes are not focusable by mouse > 2. Radio buttons and check boxes also not focusable through tabbed browsing. from #c24 > generally speaking, clicking on a button on Mac OS X does not focus that button. " The focus event occurs when an element receives focus either via a pointing device or by tabbing navigation. This event is valid for the following elements: LABEL, INPUT, SELECT, TEXTAREA, and BUTTON. " coming from https://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-eventgroupings-htmlevents I have tried to see if this is still true in latest www.w3.org/TR/uievents/ and my attempt was inconclusive. Disclaimer: Unfortunately, I do not use MacOS; so, I do not use Safari. I do not have access to a Mac or Safari (like in an Internet Cafe or have a friend living nearby who uses a Mac). I do not want anyone to presume that I imply or infer bad faith or bad intent or lack of empathy toward Safari developers or MacOS engineers. I do not want people to think that my questions are trying to annoy or contradict MacOS or Safari developers. 1763490 71 dave.batiste 2021-05-25 06:02:29 -0700 (In reply to Darin Adler from comment #68) > (In reply to John A. Bilicki III from comment #67) > > what is the benefit of not focusing a button? > > This is the benefit: > > Mac users expect the focus to remain in the text field if you click on a > button. That’s what happens everywhere else on their computer in all the Mac > applications. It’s a benefit that buttons work as expected, consistent with > other buttons on the Mac, and don't pull the focus away from the text field > you are already typing in. > > I understand that if you’ve never used a Mac you might not be aware that > this is a benefit, but I assure you that it is. > > If I understand your argument correctly, reading through and trying not to > be offended by the repeated accusations of bad faith, bad intentions, and > insufficient empathy for our fellow human beings, you are saying that this > choice makes it impossible to make websites work accessibly, and is simply > an expression of arrogance and bad decision making and a lack of care for > other people. > > That’s not our intent. We’d like this to fit in well with other Mac software. I fully appreciate that Apple has the best intentions in making buttons in Safari behave the same as buttons in MacOS apps, but web developers require browser consistency in order to deliver applications and features to those users. Without that consistency, developers are relegated to conditional code and terrible work-arounds to accommodate those differences in behavior, or worse, those features don't work properly in Safari (which is the case that prompted my previous reply). If web apps break because of browser inconsistencies, users are certainly worse off. While I am sure Apple has (or at had) some use cases to justify this behavior, as a long-time Mac users I'm not sure what the benefits are, and that ought to make designers think twice. 1763497 72 browserbugs2 2021-05-25 06:44:55 -0700 (In reply to Maciej Stachowiak from comment #49) > (...) should be focusable by click if and > only if they are focusable in the tab cycle. And likewise for links. Bug 18425: Link doesn't receive focus when clicked https://bugs.webkit.org/show_bug.cgi?id=18425 1763556 73 darin 2021-05-25 10:13:37 -0700 (In reply to Dave from comment #71) > web developers require browser consistency in order to deliver applications and features to those users I think this is the crux of the matter. People are strongly encouraging Safari to adopt Windows-style focus on buttons, check boxes, etc., even though this is not natural for most macOS users, because the other browsers, all of which have more users on Windows than Mac, have chosen to make the browser world a world of Windows-style within a window, even on Mac. Perhaps in the end the Safari will be *forced* to do this, because we simply can’t resist the tide of all those website developers who are relying on this aspect of how Windows works, perhaps without even being aware of that, within webpages. The webpages that are theoretically and aspirationally platform-independent, but in the end strongly depend on this specific behavior from Windows. I do see these impassioned arguments, and I really don’t think the Safari team resistance comes from arrogance: We’re looking out for the many Mac users that find the web browser easier to use when it matches the rest of software on the Mac. Some of these arguments start with the bizarre claim that Apple and Mac are intrinsically "elitist". I really don’t know what to do with that claim; I have no intention of debating it. But I do understand the claim that the Safari team must prioritize the ease of making a website work across browsers by people who will never test that website in Safari, and the strong request that we accept the Windows model on Mac to make that easier. And the related claim that some, or even many, Mac users don’t even care about the inconsistency between the browser and the rest of the Mac software, and those people are happy to accept that in Mac Chrome, for example. On Mac, *nothing* except a text field focuses just because you click on it, unless you turn on accessibility options that allow you to use the keyboard to cycle through everything. Pushing a button does not focus the button. Clicking a check box does not focus the check box. On Windows, keyboard focus is a concept that’s on by default, and all of those things *do* happen. This difference has been around as long as Windows has; it’s one of a few key things that Microsoft changed when implementing concepts that were first on Mac. And these accessibility options that change the focus rules need to affect focus even in web browsers. Thus, it is possible, perhaps even likely, websites that depend sensitively on exactly what is focused are effectively choosing to work only for certain people based on their accessibility options! I suppose it may be too late to change the approach of the web platform. I’m a little sad that it seems "you must match Windows; please drop things that are different about the Mac because it is too difficult to accommodate them and keep websites compatible" is the strongly encouraged approach to cross-browser compatibility. 1769254 74 bugzilla 2021-06-13 02:46:50 -0700 (In reply to Darin Adler from comment #73) > Perhaps in the end the Safari will be *forced* to do this, because we simply can’t resist the tide of all those website developers who are relying on this aspect of how Windows works [The HTML spec](https://html.spec.whatwg.org/multipage/interaction.html) actually calls out that: > the user agent might determine that an element is not click focusable even if it is focusable. For example, in some user agents, clicking on a non-editable form control does not focus it, i.e. the user agent has determined that such controls are not click focusable So the behaviour of Safari on Mac in this case is perfectly fine, and standards-compliant. However, the spec also states that: > User agents should consider focusable areas with non-null tabindex values to be click focusable. Which I interpret as if a button has `tabindex="0"` (or a positive integer) then it should always be focused after being clicked. Currently Safari will treat buttons with non-null tabindex values just the same as buttons with null tabindex values, so this is a bug as it's a violation of the HTML spec. IMO making buttons click focusable if they have a non-null tabindex value is an excellent compromise; it allows the user agent to behave in the system-default way for most situations whilst giving authors the ability to explicitly instruct the user agent that they require a particular button to be focused when clicked. 1769257 75 redux 2021-06-13 05:23:33 -0700 "The webpages that are theoretically and aspirationally platform-independent, but in the end strongly depend on this specific behavior from Windows." Two points here: - it's not just Windows. The same also happens on most (all?) Linux distros and their window managers (and then browsers that run on them). - for the web to work as a platform/host environment agnostic platform in its own right, it needs consistent paradigms. otherwise, you end up exactly back where this started with platform-specific quirks/differences in behaviors. " I’m a little sad that it seems "you must match Windows; please drop things that are different about the Mac because it is too difficult to accommodate them and keep websites compatible" is the strongly encouraged approach to cross-browser compatibility." It's sad, yes, but that's the way cross-browser compatibility has worked for a while. Once certain patterns/approaches get entrenched and are widely relied on, other browsers usually have to grudgingly adapt. There have been plenty of cases where browsers have had to adopt things that were Safari/WebKit specific (e.g. all those prefixed CSS properties, that other browsers had to end up aliasing/emulating) in order to make sites work correctly. "making buttons click focusable if they have a non-null tabindex value is an excellent compromise; it allows the user agent to behave in the system-default way for most situations whilst giving authors the ability to explicitly instruct the user agent that they require a particular button to be focused when clicked." not a big fan of requiring authors to once again add extra markup/putting the onus on them to fix sites to accommodate for an idiosyncratic quirk of one particular user agent... 1769258 76 browserbugs2 2021-06-13 06:14:16 -0700 > 1. Radio buttons and check boxes are not focusable by mouse > 2. Radio buttons and check boxes also not focusable through tabbed browsing. Does latest Safari passes these 2 :checked pseudo-class tests? http://wpt.live/css/selectors/old-tests/css3-modsel-25.xml http://wpt.live/css/selectors/old-tests/css3-modsel-70.xml Epiphany 3.32.1.2 (which uses WebKitGTK+ 2.32.1) under Linux passes those 2 tests. https://www.w3.org/TR/selectors-3/#checked - - - - > User agents *should consider* focusable areas with non-null tabindex values to be click focusable. (...) > so this is a bug as it's a violation of the HTML spec. Generally speaking, when reading a spec, "SHOULD" means recommended but not required. https://www.ietf.org/rfc/rfc2119.txt Along with "consider" verb, this means very little. So, this is not a violation of the HTML5 spec. Safari could still claim compliance with the HTML5 spec. 1769262 77 bugzilla 2021-06-13 07:00:15 -0700 (In reply to Gérard Talbot from comment #76) > > User agents *should consider* focusable areas with non-null tabindex values to be click focusable. > (...) > > so this is a bug as it's a violation of the HTML spec. > > Generally speaking, when reading a spec, "SHOULD" means recommended but not > required. > https://www.ietf.org/rfc/rfc2119.txt > Along with "consider" verb, this means very little. So, this is not a > violation of the HTML5 spec. Safari could still claim compliance with the > HTML5 spec. Yes, agreed that 'should' is a recommendation rather than a requirement, but nonetheless recommendations should not be so easily dismissed. It's reasonable for content authors to expect user agents to adhering to the non-null tabindex recommendation from the spec, just as it's reasonable for Safari to choose not to focus on click by default. I think you're misunderstanding the meaning of the verb 'consider' in this context. 'Consider X to be Y' means that you should think of X as Y. E.g., 'you should consider the case closed' does not mean you should think about whether or not the case is closed, it means you should think _that_ the case is closed. Therefore this sentence in the spec is not an instruction for UA authors _to think about whether they want to_ make such elements click focusable, it's an instruction for UA authors to _explicitly treat_ such elements as click focusable. This is quite clear when reading the sentence in the context of the whole section of text in which it appears in the spec. 1769263 78 bugzilla 2021-06-13 07:06:17 -0700 (In reply to Patrick H. Lauke from comment #75) > not a big fan of requiring authors to once again add extra markup/putting > the onus on them to fix sites to accommodate for an idiosyncratic quirk of > one particular user agent... Just like any other part of the spec, the onus is absolutely on content authors to understand it and accommodate it. The spec explicitly states that focus-on-click is not a required behaviour for user agents, and content authors should therefore not take it for granted. Equally the onus is on UA authors to adhere to the spec; which is why I think Safari should adopt the behaviour of treating focusable elements with a non-null tabindex as click-focusable, just as the spec says it should. 1769301 79 jab_creations 2021-06-13 14:46:32 -0700 >> the user agent might determine that an element is not click focusable even if it is focusable. For example, in some user agents, clicking on a non-editable form control does not focus it, i.e. the user agent has determined that such controls are not click focusable >So the behavior of Safari on Mac in this case is perfectly fine, and standards-compliant. Those are elements with the disabled attribute or are hidden by elements with greater z-index layers. >not a big fan of requiring authors to once again add extra markup/putting the onus on them to fix sites to accommodate for an idiosyncratic quirk of one particular user agent... The more quirks we have to deal with the less time we get to spend with our families or on non-work related activities. >Generally speaking, when reading a spec, "SHOULD" means recommended but not required. The point of having a specification or standard is to ELIMINATE the quirks between browsers; the word "SHOULD" has ZERO justification to be in any specification or standard. When someone argues "but..." then THEY are required to distinguish scenarios one and two and clarify any other scenarios requiring clarification. I've personally encountered alarming amounts of incompetence in "standards" such as scrollbar-width. The entire Git conversation was monopolized by people arguing over literal absolute ambiguities. The word 'thin' has zero absolute definition, it was useless because obviously what a Linux die-hard think is "thin" will differ from a Windows die-hard's version of "thin". Therefore the "standard" is pseudo (not really) because it "officialized" ambiguity and ruins forward-compatibility. Therefore when work on my own browser engine begins my team will adhere to proper standards and ignore anything ambiguous. Will people be upset? Yes, though they aren't the ones stuck working until 4AM dealing with who have to be awake to help their families at 8AM. I understand why there is a lot of animosity towards behavior associated with Microsoft products however a good idea is a good idea period. If Mao, Hitler or Stalin say 2 + 2 = 4 and then further clarify that they are explicitly using the decimal system (versus 1 + 1 (spoken) = three and not clarifying binary) the fact that those were absolute evil marxist dictators does not change the fact that the sentence they spoke is true. At the end of the day work on browser engines is either done in the context of helping humans or enforcing some arbitrary notion because of some completely unrelated hatred. Competence and good behavior of a rendering engine is in absolute more important in the context of helping your fellow human beings. 1785283 80 ap 2021-08-18 17:07:21 -0700 *** Bug 229245 has been marked as a duplicate of this bug. *** 1790348 81 andy.blum.01 2021-09-03 13:52:42 -0700 Hi there! Sorry to stir up old discussions, but I think there's got to be some sort of better behavior that safari could do than the status quo. The main issue I have here is with this assertion: > Mac users expect the focus to remain in the text field if you click on a button. That’s what happens everywhere else on their computer in all the Mac applications. It’s a benefit that buttons work as expected, consistent with other buttons on the Mac, and don't pull the focus away from the text field you are already typing in. If this were the standard behavior and that clicking a button didn't pull focus from the item that currently had it - well, I could live with that. But that's not what happens in Safari. Interacting with a button in safari drops focus entirely. It's not left on the previously focused element, it doesn't go to button, nothing gets focus. Focus just ceases to exist. I've made a codepen to hopefully illustrate my point: https://codepen.io/andy-blum/pen/ExXgxWO Clicking into a text input raises the following events: - mousedown - focus - focusin - mouseup - click Then, clicking into a directly adjacent button: - mousedown (button) - blur (input) - focusout (input) - mouseup (button) - click (button) So... where is the focus? The tabbing order is maintained, but the focus leaves both the input and button. The reason I came across this bug recently was an issue for a search component listening for focusout events to close the type-ahead suggestions. Clicking the search button on this form closes the results and interrupts the submission of the form because the entire component loses focus before the button can even be clicked. I understand the arguments of intention presented here, but the implementation in Safari simply does not align with those intentions and breaks intuitive behavior web developers anticipate and experience in other browsers - regardless of OS. 1790350 82 darin 2021-09-03 13:56:00 -0700 Good point about dropping the focus. Not the same as the bug reported here; might be helpful to file a new more specific bug report about that problem. 1790358 83 andy.blum.01 2021-09-03 14:07:05 -0700 Thanks for the response, Darin. I've opened a new ticket here: https://bugs.webkit.org/show_bug.cgi?id=229895 1790359 84 andy.blum.01 2021-09-03 14:07:44 -0700 Thanks for the response, Darin. I've opened a new ticket here: https://bugs.webkit.org/show_bug.cgi?id=229895 1790363 85 rniwa 2021-09-03 14:21:40 -0700 (In reply to Andy Blum from comment #84) > Thanks for the response, Darin. I've opened a new ticket here: > https://bugs.webkit.org/show_bug.cgi?id=229895 Yeah, I think this is a good bug to fix assuming that it's web compatible. 1790463 86 jab_creations 2021-09-03 19:15:55 -0700 Are you two serious? Instead of advocating to fix this bug you go out of your way to post another bug report to advocate the devs to dig in their heels?! How about standardizing some devastating needed questions in the technology industry: 1. How does this help productive members of society? 2. Does this serve a useful purpose? 3. Should I be doing this? 4. Have I had a full, non-interrupted, rational conversation with multiple people who disagrees to help determine if I have objectively determined my answers to the first three questions? 1800043 87 aaron 2021-10-04 07:07:38 -0700 While working around this non web-standard behavior, I notice that Safari Developer Tools lets you apply focus to a selected element at the top of the styles pane This magically displays what it the element would look like if it could be focused i.e. Developer Tools has already addressed this bug - shame it didn't make it into the main browser window. 1833771 88 ap 2022-01-25 10:37:06 -0800 *** Bug 235471 has been marked as a duplicate of this bug. *** 1843254 89 ap 2022-02-17 19:46:36 -0800 *** Bug 236725 has been marked as a duplicate of this bug. *** 1892574 90 ap 2022-08-19 17:56:49 -0700 *** Bug 28630 has been marked as a duplicate of this bug. *** 1895059 91 akeerthi 2022-08-30 22:03:24 -0700 *** Bug 13724 has been marked as a duplicate of this bug. *** 2075741 92 karlcow 2024-11-17 20:50:48 -0800 *** Bug 267449 has been marked as a duplicate of this bug. *** 25169 2008-11-14 04:19:32 -0800 2008-11-14 04:19:32 -0800 page demonstrating bug webkit_button_focus.html application/xhtml+xml 1036 mike.capp 77u/PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBYSFRNTCAxLjAgVHJhbnNpdGlv bmFsLy9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL3hodG1sMS9EVEQveGh0bWwxLXRyYW5zaXRp b25hbC5kdGQiPg0KPGh0bWwgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkveGh0bWwiPg0K IDxoZWFkPg0KICA8dGl0bGU+V2ViS2l0IGJ1dHRvbiBmb2N1cyBpc3N1ZXM8L3RpdGxlPg0KICA8 c2NyaXB0IHR5cGU9InRleHQvZWNtYXNjcmlwdCI+DQogICBmdW5jdGlvbiBsb2cocykgeyBkb2N1 bWVudC5nZXRFbGVtZW50QnlJZCgibG9nIikuaW5uZXJIVE1MID0gczsgfQ0KICA8L3NjcmlwdD4N CiA8L2hlYWQ+DQogPGJvZHk+DQogIDxwPjxpbnB1dCBpZD0icHJpbWFyeSIgdHlwZT0iYnV0dG9u IiB2YWx1ZT0iUHJpbWFyeSIgb25mb2N1cz0ibG9nKCdQcmltYXJ5IGJ1dHRvbiByZWNlaXZlZCBm b2N1cyBldmVudCcpOyIgb25ibHVyPSJsb2coJ1ByaW1hcnkgYnV0dG9uIHJlY2VpdmVkIGJsdXIg ZXZlbnQnKTsiIC8+PC9wPg0KICA8cD48aW5wdXQgdHlwZT0idGV4dCIgdmFsdWU9ImZvY3VzIGhl cmUgYW5kIHNoaWZ0LXRhYiIgLz48L3A+DQogIDxwPjxpbnB1dCB0eXBlPSJidXR0b24iIHZhbHVl PSJPdGhlciBidXR0b24iIC8+PC9wPg0KICA8cD48YSBocmVmPSIjIiBvbmNsaWNrPSJkb2N1bWVu dC5nZXRFbGVtZW50QnlJZCgncHJpbWFyeScpLmZvY3VzKCk7Ij5TZXQgZm9jdXMgdG8gcHJpbWFy eSBidXR0b248L2E+PC9wPg0KICA8dWw+DQogICA8bGk+Q2xpY2sgcHJpbWFyeSA9PiBubyBmb2N1 czwvbGk+DQogICA8bGk+Q2xpY2sgdGV4dGJveCB0aGVuIFNoaWZ0LVRhYiA9PiBwcmltYXJ5IGJ1 dHRvbiBnZXRzIGZvY3VzPC9saT4NCiAgIDxsaT5TZXQgZm9jdXMgdG8gcHJpbWFyeSAodmlhIGxp bmspIHRoZW4gY2xpY2sgb3RoZXIgYnV0dG9uID0+IHByaW1hcnkgbG9zZXMgZm9jdXM8L2xpPg0K ICA8L3VsPg0KICA8cCBpZD0ibG9nIiBzdHlsZT0iY29sb3I6cmVkOyI+PC9wPg0KIDwvYm9keT4N CjwvaHRtbD4NCg== 40241 2009-09-28 09:25:11 -0700 2009-09-30 13:03:48 -0700 Fix for the html elements not focused by mouse focus_bug.diff text/plain 467 ostap73 SW5kZXg6IFdlYkNvcmUvaHRtbC9IVE1MRm9ybUNvbnRyb2xFbGVtZW50LmNwcAo9PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 Ci0tLSBXZWJDb3JlL2h0bWwvSFRNTEZvcm1Db250cm9sRWxlbWVudC5jcHAJKHJldmlzaW9uIDQ4 MjYyKQorKysgV2ViQ29yZS9odG1sL0hUTUxGb3JtQ29udHJvbEVsZW1lbnQuY3BwCSh3b3JraW5n IGNvcHkpCkBAIC0yNTcsMTEgKzI1Nyw3IEBACiAKIGJvb2wgSFRNTEZvcm1Db250cm9sRWxlbWVu dDo6aXNNb3VzZUZvY3VzYWJsZSgpIGNvbnN0CiB7Ci0jaWYgUExBVEZPUk0oR1RLKQogICAgIHJl dHVybiBIVE1MRWxlbWVudDo6aXNNb3VzZUZvY3VzYWJsZSgpOwotI2Vsc2UKLSAgICByZXR1cm4g ZmFsc2U7Ci0jZW5kaWYKIH0KIAogc2hvcnQgSFRNTEZvcm1Db250cm9sRWxlbWVudDo6dGFiSW5k ZXgoKSBjb25zdAo= 40393 2009-09-30 13:03:48 -0700 2009-09-30 13:06:52 -0700 Fix for the html elements not focused by mouse. scrollfix.diff text/plain 717 ostap73 SW5kZXg6IHdydC9ydW50aW1lY29yZS93ZWJjYW52YXMuY3BwCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHdydC9y dW50aW1lY29yZS93ZWJjYW52YXMuY3BwCShyZXZpc2lvbiAxODYyMykKKysrIHdydC9ydW50aW1l Y29yZS93ZWJjYW52YXMuY3BwCSh3b3JraW5nIGNvcHkpCkBAIC02NzYsOSArNjc2LDE2IEBACiB7 CiAgICAgV2ViQ2FudmFzUHJpdmF0ZSogcCA9IG1fd2ViQ2FudmFzLT5kOwogCisgICAgLy8gU3Vi bWl0IGFsbCBwZW5kaW5nIHBhaW50cyBiZWZvcmUgc2Nyb2xsCisgICAgaWYoIXAtPm1fZGlydHlS ZWdpb24uaXNFbXB0eSgpKQorICAgICAgICB1cGRhdGVSZXF1ZXN0ZWQodHJ1ZSk7CisKICAgICBz Y3JvbGwoZHgsIGR5KTsKIAotICAgIHAtPm1fZGlydHlSZWdpb24gPSBRUmVnaW9uKCk7CisgICAg Ly8gRm9yY2UgcmVwYWludCBvZiBzY3JvbGxlZCBhcmVhcyBpbW1lZGlhdGVseSwgYmVjYXVzZQor ICAgIC8vIGlmIGRlbGF5ZWQgYnkgc2NyZWVuIHVwZGF0ZSBvcHRpbWl6YXRpb25zIGRpcnR5IGFy ZWFzIAorICAgIC8vIGJlY29tZSB1bnN5bmMgd2l0aCB3ZWJraXQgc2Nyb2xsIHN0YXRlCisgICAg UUFwcGxpY2F0aW9uOjpzZW5kUG9zdGVkRXZlbnRzKCk7CiB9CiAKIHZvaWQgV2ViQ2FudmFzV2lk Z2V0OjpwYWludEV2ZW50KFFQYWludEV2ZW50ICpldikK 40394 2009-09-30 13:06:52 -0700 2010-04-12 23:50:10 -0700 Fix for the html elements not focused by mouse. focusingfix.diff text/plain 1164 ostap73 SW5kZXg6IFdlYkNvcmUvQ2hhbmdlTG9nCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFdlYkNvcmUvQ2hhbmdlTG9n CShyZXZpc2lvbiA0ODk0NCkKKysrIFdlYkNvcmUvQ2hhbmdlTG9nCSh3b3JraW5nIGNvcHkpCkBA IC0xLDMgKzEsMTMgQEAKKzIwMDktMDktMzAgIFZpYXRjaGVzbGF2IE9zdGFwZW5rbyAgPG9zdGFw ZW5rby52aWF0Y2hlc2xhdkBub2tpYS5jb20+CisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZ IChPT1BTISkuCisKKyAgICAgICAgRml4IGZvY3VzaW5nIG9mIGNvbnRyb2wgZWxlbWVudHMgb24g bW91c2UgY2xpY2suCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNn aT9pZD0yMjI2MQorCisgICAgICAgICogaHRtbC9IVE1MRm9ybUNvbnRyb2xFbGVtZW50LmNwcDoK KyAgICAgICAgKFdlYkNvcmU6OkhUTUxGb3JtQ29udHJvbEVsZW1lbnQ6OmlzTW91c2VGb2N1c2Fi bGUpOgorCiAyMDA5LTA5LTMwICBKZXJlbXkgT3Jsb3cgIDxqb3Jsb3dAY2hyb21pdW0ub3JnPgog CiAgICAgICAgIEJ1aWxkIGZpeCBmb3IgUVQuICBEaWRuJ3Qga25vdyBXZWJDb3JlLnBybyBleGlz dGVkLgpJbmRleDogV2ViQ29yZS9odG1sL0hUTUxGb3JtQ29udHJvbEVsZW1lbnQuY3BwCj09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT0KLS0tIFdlYkNvcmUvaHRtbC9IVE1MRm9ybUNvbnRyb2xFbGVtZW50LmNwcAkocmV2aXNp b24gNDg5MDkpCisrKyBXZWJDb3JlL2h0bWwvSFRNTEZvcm1Db250cm9sRWxlbWVudC5jcHAJKHdv cmtpbmcgY29weSkKQEAgLTI1OSwxMCArMjU5LDEwIEBAIGJvb2wgSFRNTEZvcm1Db250cm9sRWxl bWVudDo6aXNLZXlib2FyZEYKIAogYm9vbCBIVE1MRm9ybUNvbnRyb2xFbGVtZW50Ojppc01vdXNl Rm9jdXNhYmxlKCkgY29uc3QKIHsKLSNpZiBQTEFURk9STShHVEspCi0gICAgcmV0dXJuIEhUTUxF bGVtZW50Ojppc01vdXNlRm9jdXNhYmxlKCk7Ci0jZWxzZQorI2lmIFBMQVRGT1JNKE1BQykKICAg ICByZXR1cm4gZmFsc2U7CisjZWxzZQorICAgIHJldHVybiBIVE1MRWxlbWVudDo6aXNNb3VzZUZv Y3VzYWJsZSgpOwogI2VuZGlmCiB9CiAK 53227 2010-04-12 23:50:10 -0700 2010-04-13 10:07:23 -0700 Fix with layout test. control_mouse_focusing_fix.diff text/plain 5952 ostap73 SW5kZXg6IFdlYkNvcmUvQ2hhbmdlTG9nCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFdlYkNvcmUvQ2hhbmdlTG9n CShyZXZpc2lvbiA1NzUwMikKKysrIFdlYkNvcmUvQ2hhbmdlTG9nCSh3b3JraW5nIGNvcHkpCkBA IC0xLDMgKzEsMTUgQEAKKzIwMTAtMDQtMTIgIFZpYXRjaGVzbGF2IE9zdGFwZW5rbyAgPG9zdGFw ZW5rby52aWF0Y2hlc2xhdkBub2tpYS5jb20+CisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZ IChPT1BTISkuCisKKyAgICAgICAgRml4IGZvY3VzaW5nIG9mIGNvbnRyb2wgZWxlbWVudHMgb24g bW91c2UgY2xpY2suCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNn aT9pZD0yMjI2MQorCisgICAgICAgIFRlc3Q6IGZhc3QvZXZlbnRzL2NsaWNrLWZvY3VzLWNvbnRy b2wuaHRtbAorCisgICAgICAgICogaHRtbC9IVE1MRm9ybUNvbnRyb2xFbGVtZW50LmNwcDoKKyAg ICAgICAgKFdlYkNvcmU6OkhUTUxGb3JtQ29udHJvbEVsZW1lbnQ6OmlzTW91c2VGb2N1c2FibGUp OgorCiAyMDEwLTA0LTEyICBBbnRvbmlvIEdvbWVzICA8dG9uaWtpdG9vQHdlYmtpdC5vcmc+CiAK ICAgICAgICAgUmV2aWV3ZWQgYnkgU2ltb24gRnJhc2VyLgpJbmRleDogV2ViQ29yZS9odG1sL0hU TUxGb3JtQ29udHJvbEVsZW1lbnQuY3BwCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFdlYkNvcmUvaHRtbC9IVE1M Rm9ybUNvbnRyb2xFbGVtZW50LmNwcAkocmV2aXNpb24gNTY0NjEpCisrKyBXZWJDb3JlL2h0bWwv SFRNTEZvcm1Db250cm9sRWxlbWVudC5jcHAJKHdvcmtpbmcgY29weSkKQEAgLTI4OCwxMCArMjg4 LDEwIEBACiAKIGJvb2wgSFRNTEZvcm1Db250cm9sRWxlbWVudDo6aXNNb3VzZUZvY3VzYWJsZSgp IGNvbnN0CiB7Ci0jaWYgUExBVEZPUk0oR1RLKQorI2lmIFBMQVRGT1JNKE1BQykKKyAgICByZXR1 cm4gZmFsc2U7CisjZWxzZQogICAgIHJldHVybiBIVE1MRWxlbWVudDo6aXNNb3VzZUZvY3VzYWJs ZSgpOwotI2Vsc2UKLSAgICByZXR1cm4gZmFsc2U7CiAjZW5kaWYKIH0KIApJbmRleDogTGF5b3V0 VGVzdHMvcGxhdGZvcm0vcXQvZmFzdC9ldmVudHMvY2xpY2stZm9jdXMtY29udHJvbC1leHBlY3Rl ZC50eHQKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQotLS0gTGF5b3V0VGVzdHMvcGxhdGZvcm0vcXQvZmFzdC9ldmVudHMv Y2xpY2stZm9jdXMtY29udHJvbC1leHBlY3RlZC50eHQJKHJldmlzaW9uIDApCisrKyBMYXlvdXRU ZXN0cy9wbGF0Zm9ybS9xdC9mYXN0L2V2ZW50cy9jbGljay1mb2N1cy1jb250cm9sLWV4cGVjdGVk LnR4dAkocmV2aXNpb24gMCkKQEAgLTAsMCArMSwxMiBAQAorVGhpcyB0ZXN0IGVuc3VyZXMgdGhh dCB3ZSBjYW4gY2xpY2sgdG8gZm9jdXMgYW4gYSBlbGVtZW50LiBDbGljayBvbiB0aGUgZWxlbWVu dCBiZWxvdy4KKworVGhlIGV4cGVjdGVkIHJlc3VsdCBpcyBwbGF0Zm9ybSBzcGVjaWZpYy4gTWFj IGRvZXNuJ3QgYWxsb3cgc29tZSBmb3JtIGNvbnRyb2xzIHRvIGJlIG1vdXNlIGZvY3VzYWJsZS4K KworUmVzdWx0CisKKworYTEgcmVjZWl2ZWQgZm9jdXMgKCkKK2EyIHJlY2VpdmVkIGZvY3VzICgp CithMyByZWNlaXZlZCBmb2N1cyAoKQorYTQgcmVjZWl2ZWQgZm9jdXMgKCkKK2E1IHJlY2VpdmVk IGZvY3VzICgpCkluZGV4OiBMYXlvdXRUZXN0cy9wbGF0Zm9ybS9tYWMvU2tpcHBlZAo9PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09Ci0tLSBMYXlvdXRUZXN0cy9wbGF0Zm9ybS9tYWMvU2tpcHBlZAkocmV2aXNpb24gNTY0NjEp CisrKyBMYXlvdXRUZXN0cy9wbGF0Zm9ybS9tYWMvU2tpcHBlZAkod29ya2luZyBjb3B5KQpAQCAt MTQyLDMgKzE0Miw3IEBACiAKICMgTWlzc2VzIHNldE1lZGlhVHlwZSgpIGFuZCBpbXBsZW1lbnRh dGlvbgogZmFzdC9tZWRpYS9wcmludC1yZXN0b3Jlcy1wcmV2aW91cy1tZWRpYXR5cGUuaHRtbAor CisjIE1hYyBzaG91bGRuJ3QgZm9jdXMgb24gc29tZSBjb250cm9sIGVsZW1lbnRzCisjIGh0dHBz Oi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0yMjI2MQorZmFzdC9ldmVudHMvY2xp Y2stZm9jdXMtY29udHJvbC5odG1sCkluZGV4OiBMYXlvdXRUZXN0cy9mYXN0L2V2ZW50cy9jbGlj ay1mb2N1cy1jb250cm9sLmh0bWwKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gTGF5b3V0VGVzdHMvZmFzdC9ldmVu dHMvY2xpY2stZm9jdXMtY29udHJvbC5odG1sCShyZXZpc2lvbiAwKQorKysgTGF5b3V0VGVzdHMv ZmFzdC9ldmVudHMvY2xpY2stZm9jdXMtY29udHJvbC5odG1sCShyZXZpc2lvbiAwKQpAQCAtMCww ICsxLDg2IEBACis8IURPQ1RZUEUgaHRtbD4KKzxodG1sPgorPGhlYWQ+Cis8L2hlYWQ+Cis8Ym9k eT4KKworPHA+VGhpcyB0ZXN0IGVuc3VyZXMgdGhhdCB3ZSBjYW4gY2xpY2sgdG8gZm9jdXMgYW4g YSBlbGVtZW50LgorQ2xpY2sgb24gdGhlIGVsZW1lbnQgYmVsb3cuCisKKzxwPlRoZSBleHBlY3Rl ZCByZXN1bHQgaXMgcGxhdGZvcm0gc3BlY2lmaWMuIE1hYyBkb2Vzbid0IGFsbG93IHNvbWUgZm9y bSBjb250cm9scyB0byBiZQorbW91c2UgZm9jdXNhYmxlLgorCis8ZGl2IGlkPXRlc3QtY29udGFp bmVyPgorPGZvcm0gaWQ9ImZvcm0xIj4KKzxwPgorPHN0cm9uZz5UaGlzIGlzIGZvcm0xPC9zdHJv bmc+PGJyLz4KKworRmlyc3QgbmFtZSBoZXJlPGJyLz4KKzxpbnB1dCB0eXBlPSJ0ZXh0IiBuYW1l PSJuYW1lIiB0aXRsZT0iaW5wdXQgbmFtZSIgc2l6ZT0iNiIgbWF4bGVuZ3RoPSIxMCIvPjxici8+ CisKK1Bhc3N3b3JkOjxici8+Cis8aW5wdXQgdHlwZT0icGFzc3dvcmQiIG5hbWU9InBhc3N3b3Jk IiBzaXplPSI2IiBtYXhsZW5ndGg9IjEwIi8+PGJyLz4KKworY29tbWVudHM6PGJyLz4KKzx0ZXh0 YXJlYSBuYW1lPSJjb21tZW50cyIgdGl0bGU9InRleHRhcmVhIGNvbW1lbnRzIiByb3dzPSIyIiBj b2xzPSIyMCI+YW55dGhpbmcgZm9ybTEgZ29lcyBoZXJlPC90ZXh0YXJlYT48YnIvPgorCitTZWxl Y3QgMTo8YnIvPgorPGlucHV0IGlkPWExIHR5cGU9InJhZGlvIiBuYW1lPSJyYWRpbzEiIHZhbHVl PSJyYWRpbzFhIi8+PGJyLz4KKzxpbnB1dCBpZD1hMiB0eXBlPSJyYWRpbyIgbmFtZT0icmFkaW8x IiB2YWx1ZT0icmFkaW8xYiIvPjxici8+CisKK0NoZWNrIGl0Ojxici8+Cis8aW5wdXQgaWQ9YTMg dHlwZT0iY2hlY2tib3giIG5hbWU9ImNoZWNrYm94MSIgdmFsdWU9ImNoZWNrYm94MSIvPjxici8+ CisKK1NlbGVjdCAxOjxici8+CisgIDxzZWxlY3QgaWQ9YTQgbmFtZT0iU2VsZWN0IiBzaXplPSIy Ij4KKyAgICA8b3B0aW9uPjE8L29wdGlvbj4KKyAgICA8b3B0aW9uPjI8L29wdGlvbj4KKyAgICA8 b3B0aW9uIHNlbGVjdGVkPSJzZWxlY3RlZCI+Mzwvb3B0aW9uPgorICAgIDxvcHRpb24+NDwvb3B0 aW9uPgorICA8L3NlbGVjdD48YnIvPgorPGlucHV0IGlkPWE1IHR5cGU9ImJ1dHRvbiIgbmFtZT0i YnV0dG9uIiB2YWx1ZT0iQnV0dG9uIDEiLz4KKzwvcD48L2Zvcm0+PHA+PHN0cm9uZz5FbmQgZm9y bTE8L3N0cm9uZz48L3A+Cis8L2Rpdj4KKworPHA+UmVzdWx0CisKKzxwcmUgaWQ9b3V0PjwvcHJl PgorCis8c2NyaXB0PgorCitmdW5jdGlvbiBsb2cocykKK3sKKyAgICB2YXIgZWwgPSBkb2N1bWVu dC5nZXRFbGVtZW50QnlJZCgnb3V0Jyk7CisgICAgZWwudGV4dENvbnRlbnQgKz0gJ1xuJyArIHM7 Cit9CisKK2Z1bmN0aW9uIGhhbmRsZUZvY3VzKGUpCit7CisgICAgdmFyIGVsID0gZS50YXJnZXQ7 CisgICAgbG9nKGVsLmlkICsgJyByZWNlaXZlZCBmb2N1cyAoJyArIGVsLnRpdGxlICsgJyknKTsK K30KKworaWYgKHdpbmRvdy5sYXlvdXRUZXN0Q29udHJvbGxlcikgeworICAgIGxheW91dFRlc3RD b250cm9sbGVyLmR1bXBBc1RleHQoKTsKK30KKword2luZG93Lm9ubG9hZCA9IGZ1bmN0aW9uKCkK K3sKKyAgICBpZiAoIXdpbmRvdy5sYXlvdXRUZXN0Q29udHJvbGxlcikKKyAgICAgICAgcmV0dXJu OworCisgICAgZm9yICh2YXIgaSA9IDE7IGkgPD0gNTsgaSsrKSB7CisgICAgICAgIHZhciBhRWxl bWVudCA9IGRvY3VtZW50LmdldEVsZW1lbnRCeUlkKCdhJyArIGkpOworICAgICAgICBhRWxlbWVu dC5vbmZvY3VzID0gaGFuZGxlRm9jdXM7CisgICAgICAgIGV2ZW50U2VuZGVyLm1vdXNlTW92ZVRv KGFFbGVtZW50Lm9mZnNldExlZnQgKyAyLCBhRWxlbWVudC5vZmZzZXRUb3AgKyAyKTsKKyAgICAg ICAgZXZlbnRTZW5kZXIubW91c2VEb3duKCk7CisgICAgICAgIGV2ZW50U2VuZGVyLm1vdXNlVXAo KTsKKyAgICB9CisKKyAgICB2YXIgdGMgPSBkb2N1bWVudC5nZXRFbGVtZW50QnlJZCgndGVzdC1j b250YWluZXInKTsKKyAgICB0Yy5wYXJlbnROb2RlLnJlbW92ZUNoaWxkKHRjKTsKK307CisKKzwv c2NyaXB0PgorPC9ib2R5PgorPC9odG1sPgpJbmRleDogTGF5b3V0VGVzdHMvZmFzdC9ldmVudHMv Y2xpY2stZm9jdXMtY29udHJvbC1leHBlY3RlZC50eHQKPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gTGF5b3V0VGVz dHMvZmFzdC9ldmVudHMvY2xpY2stZm9jdXMtY29udHJvbC1leHBlY3RlZC50eHQJKHJldmlzaW9u IDApCisrKyBMYXlvdXRUZXN0cy9mYXN0L2V2ZW50cy9jbGljay1mb2N1cy1jb250cm9sLWV4cGVj dGVkLnR4dAkocmV2aXNpb24gMCkKQEAgLTAsMCArMSwxMiBAQAorVGhpcyB0ZXN0IGVuc3VyZXMg dGhhdCB3ZSBjYW4gY2xpY2sgdG8gZm9jdXMgYW4gYSBlbGVtZW50LiBDbGljayBvbiB0aGUgZWxl bWVudCBiZWxvdy4KKworVGhlIGV4cGVjdGVkIHJlc3VsdCBpcyBwbGF0Zm9ybSBzcGVjaWZpYy4g TWFjIGRvZXNuJ3QgYWxsb3cgc29tZSBmb3JtIGNvbnRyb2xzIHRvIGJlIG1vdXNlIGZvY3VzYWJs ZS4KKworUmVzdWx0CisKKworYTEgcmVjZWl2ZWQgZm9jdXMgKCkKK2EyIHJlY2VpdmVkIGZvY3Vz ICgpCithMyByZWNlaXZlZCBmb2N1cyAoKQorYTQgcmVjZWl2ZWQgZm9jdXMgKCkKK2E1IHJlY2Vp dmVkIGZvY3VzICgpCkluZGV4OiBMYXlvdXRUZXN0cy9DaGFuZ2VMb2cKPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0g TGF5b3V0VGVzdHMvQ2hhbmdlTG9nCShyZXZpc2lvbiA1NzUwMikKKysrIExheW91dFRlc3RzL0No YW5nZUxvZwkod29ya2luZyBjb3B5KQpAQCAtMSwzICsxLDE1IEBACisyMDEwLTA0LTEyICBWaWF0 Y2hlc2xhdiBPc3RhcGVua28gIDxvc3RhcGVua28udmlhdGNoZXNsYXZAbm9raWEuY29tPgorCisg ICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAgIExheW91dCB0ZXN0 cyBmb3IgZml4IGZvY3VzaW5nIG9mIGNvbnRyb2wgZWxlbWVudHMgb24gbW91c2UgY2xpY2suCisg ICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0yMjI2MS4KKwor ICAgICAgICAqIGZhc3QvZXZlbnRzL2NsaWNrLWZvY3VzLWNvbnRyb2wtZXhwZWN0ZWQudHh0OiBB ZGRlZC4KKyAgICAgICAgKiBmYXN0L2V2ZW50cy9jbGljay1mb2N1cy1jb250cm9sLmh0bWw6IEFk ZGVkLgorICAgICAgICAqIHBsYXRmb3JtL21hYy9Ta2lwcGVkOgorICAgICAgICAqIHBsYXRmb3Jt L3F0L2Zhc3QvZXZlbnRzL2NsaWNrLWZvY3VzLWNvbnRyb2wtZXhwZWN0ZWQudHh0OiBBZGRlZC4K KwogMjAxMC0wNC0xMiAgRGFuaWVsIEJhdGVzICA8ZGJhdGVzQHJpbS5jb20+CiAKICAgICAgICAg UmV2aWV3ZWQgYnkgQWRhbSBCYXJ0aC4K 53258 2010-04-13 10:07:23 -0700 2010-05-24 14:49:07 -0700 Fix update control_mouse_focusing_fix.diff text/plain 5226 ostap73 SW5kZXg6IFdlYkNvcmUvQ2hhbmdlTG9nCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFdlYkNvcmUvQ2hhbmdlTG9n CShyZXZpc2lvbiA1NzUwMikKKysrIFdlYkNvcmUvQ2hhbmdlTG9nCSh3b3JraW5nIGNvcHkpCkBA IC0xLDMgKzEsMTUgQEAKKzIwMTAtMDQtMTIgIFZpYXRjaGVzbGF2IE9zdGFwZW5rbyAgPG9zdGFw ZW5rby52aWF0Y2hlc2xhdkBub2tpYS5jb20+CisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZ IChPT1BTISkuCisKKyAgICAgICAgRml4IGZvY3VzaW5nIG9mIGNvbnRyb2wgZWxlbWVudHMgb24g bW91c2UgY2xpY2suCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNn aT9pZD0yMjI2MQorCisgICAgICAgIFRlc3Q6IGZhc3QvZXZlbnRzL2NsaWNrLWZvY3VzLWNvbnRy b2wuaHRtbAorCisgICAgICAgICogaHRtbC9IVE1MRm9ybUNvbnRyb2xFbGVtZW50LmNwcDoKKyAg ICAgICAgKFdlYkNvcmU6OkhUTUxGb3JtQ29udHJvbEVsZW1lbnQ6OmlzTW91c2VGb2N1c2FibGUp OgorCiAyMDEwLTA0LTEyICBBbnRvbmlvIEdvbWVzICA8dG9uaWtpdG9vQHdlYmtpdC5vcmc+CiAK ICAgICAgICAgUmV2aWV3ZWQgYnkgU2ltb24gRnJhc2VyLgpJbmRleDogV2ViQ29yZS9odG1sL0hU TUxGb3JtQ29udHJvbEVsZW1lbnQuY3BwCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFdlYkNvcmUvaHRtbC9IVE1M Rm9ybUNvbnRyb2xFbGVtZW50LmNwcAkocmV2aXNpb24gNTY0NjEpCisrKyBXZWJDb3JlL2h0bWwv SFRNTEZvcm1Db250cm9sRWxlbWVudC5jcHAJKHdvcmtpbmcgY29weSkKQEAgLTI4OCwxMCArMjg4 LDEwIEBACiAKIGJvb2wgSFRNTEZvcm1Db250cm9sRWxlbWVudDo6aXNNb3VzZUZvY3VzYWJsZSgp IGNvbnN0CiB7Ci0jaWYgUExBVEZPUk0oR1RLKQorI2lmIFBMQVRGT1JNKE1BQykKKyAgICByZXR1 cm4gZmFsc2U7CisjZWxzZQogICAgIHJldHVybiBIVE1MRWxlbWVudDo6aXNNb3VzZUZvY3VzYWJs ZSgpOwotI2Vsc2UKLSAgICByZXR1cm4gZmFsc2U7CiAjZW5kaWYKIH0KIApJbmRleDogTGF5b3V0 VGVzdHMvcGxhdGZvcm0vbWFjL1NraXBwZWQKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gTGF5b3V0VGVzdHMvcGxh dGZvcm0vbWFjL1NraXBwZWQJKHJldmlzaW9uIDU2NDYxKQorKysgTGF5b3V0VGVzdHMvcGxhdGZv cm0vbWFjL1NraXBwZWQJKHdvcmtpbmcgY29weSkKQEAgLTE0MiwzICsxNDIsNyBAQAogCiAjIE1p c3NlcyBzZXRNZWRpYVR5cGUoKSBhbmQgaW1wbGVtZW50YXRpb24KIGZhc3QvbWVkaWEvcHJpbnQt cmVzdG9yZXMtcHJldmlvdXMtbWVkaWF0eXBlLmh0bWwKKworIyBNYWMgc2hvdWxkbid0IGZvY3Vz IG9uIHNvbWUgY29udHJvbCBlbGVtZW50cworIyBodHRwczovL2J1Z3Mud2Via2l0Lm9yZy9zaG93 X2J1Zy5jZ2k/aWQ9MjIyNjEKK2Zhc3QvZXZlbnRzL2NsaWNrLWZvY3VzLWNvbnRyb2wuaHRtbApJ bmRleDogTGF5b3V0VGVzdHMvZmFzdC9ldmVudHMvY2xpY2stZm9jdXMtY29udHJvbC5odG1sCj09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT0KLS0tIExheW91dFRlc3RzL2Zhc3QvZXZlbnRzL2NsaWNrLWZvY3VzLWNvbnRyb2wu aHRtbAkocmV2aXNpb24gMCkKKysrIExheW91dFRlc3RzL2Zhc3QvZXZlbnRzL2NsaWNrLWZvY3Vz LWNvbnRyb2wuaHRtbAkocmV2aXNpb24gMCkKQEAgLTAsMCArMSw4NiBAQAorPCFET0NUWVBFIGh0 bWw+Cis8aHRtbD4KKzxoZWFkPgorPC9oZWFkPgorPGJvZHk+CisKKzxwPlRoaXMgdGVzdCBlbnN1 cmVzIHRoYXQgd2UgY2FuIGNsaWNrIHRvIGZvY3VzIGFuIGEgZWxlbWVudC4KK0NsaWNrIG9uIHRo ZSBlbGVtZW50IGJlbG93LgorCis8cD5UaGUgZXhwZWN0ZWQgcmVzdWx0IGlzIHBsYXRmb3JtIHNw ZWNpZmljLiBNYWMgZG9lc24ndCBhbGxvdyBzb21lIGZvcm0gY29udHJvbHMgdG8gYmUKK21vdXNl IGZvY3VzYWJsZS4KKworPGRpdiBpZD10ZXN0LWNvbnRhaW5lcj4KKzxmb3JtIGlkPSJmb3JtMSI+ Cis8cD4KKzxzdHJvbmc+VGhpcyBpcyBmb3JtMTwvc3Ryb25nPjxici8+CisKK0ZpcnN0IG5hbWUg aGVyZTxici8+Cis8aW5wdXQgdHlwZT0idGV4dCIgbmFtZT0ibmFtZSIgdGl0bGU9ImlucHV0IG5h bWUiIHNpemU9IjYiIG1heGxlbmd0aD0iMTAiLz48YnIvPgorCitQYXNzd29yZDo8YnIvPgorPGlu cHV0IHR5cGU9InBhc3N3b3JkIiBuYW1lPSJwYXNzd29yZCIgc2l6ZT0iNiIgbWF4bGVuZ3RoPSIx MCIvPjxici8+CisKK2NvbW1lbnRzOjxici8+Cis8dGV4dGFyZWEgbmFtZT0iY29tbWVudHMiIHRp dGxlPSJ0ZXh0YXJlYSBjb21tZW50cyIgcm93cz0iMiIgY29scz0iMjAiPmFueXRoaW5nIGZvcm0x IGdvZXMgaGVyZTwvdGV4dGFyZWE+PGJyLz4KKworU2VsZWN0IDE6PGJyLz4KKzxpbnB1dCBpZD1h MSB0eXBlPSJyYWRpbyIgbmFtZT0icmFkaW8xIiB2YWx1ZT0icmFkaW8xYSIvPjxici8+Cis8aW5w dXQgaWQ9YTIgdHlwZT0icmFkaW8iIG5hbWU9InJhZGlvMSIgdmFsdWU9InJhZGlvMWIiLz48YnIv PgorCitDaGVjayBpdDo8YnIvPgorPGlucHV0IGlkPWEzIHR5cGU9ImNoZWNrYm94IiBuYW1lPSJj aGVja2JveDEiIHZhbHVlPSJjaGVja2JveDEiLz48YnIvPgorCitTZWxlY3QgMTo8YnIvPgorICA8 c2VsZWN0IGlkPWE0IG5hbWU9IlNlbGVjdCIgc2l6ZT0iMiI+CisgICAgPG9wdGlvbj4xPC9vcHRp b24+CisgICAgPG9wdGlvbj4yPC9vcHRpb24+CisgICAgPG9wdGlvbiBzZWxlY3RlZD0ic2VsZWN0 ZWQiPjM8L29wdGlvbj4KKyAgICA8b3B0aW9uPjQ8L29wdGlvbj4KKyAgPC9zZWxlY3Q+PGJyLz4K KzxpbnB1dCBpZD1hNSB0eXBlPSJidXR0b24iIG5hbWU9ImJ1dHRvbiIgdmFsdWU9IkJ1dHRvbiAx Ii8+Cis8L3A+PC9mb3JtPjxwPjxzdHJvbmc+RW5kIGZvcm0xPC9zdHJvbmc+PC9wPgorPC9kaXY+ CisKKzxwPlJlc3VsdAorCis8cHJlIGlkPW91dD48L3ByZT4KKworPHNjcmlwdD4KKworZnVuY3Rp b24gbG9nKHMpCit7CisgICAgdmFyIGVsID0gZG9jdW1lbnQuZ2V0RWxlbWVudEJ5SWQoJ291dCcp OworICAgIGVsLnRleHRDb250ZW50ICs9ICdcbicgKyBzOworfQorCitmdW5jdGlvbiBoYW5kbGVG b2N1cyhlKQoreworICAgIHZhciBlbCA9IGUudGFyZ2V0OworICAgIGxvZyhlbC5pZCArICcgcmVj ZWl2ZWQgZm9jdXMgKCcgKyBlbC50aXRsZSArICcpJyk7Cit9CisKK2lmICh3aW5kb3cubGF5b3V0 VGVzdENvbnRyb2xsZXIpIHsKKyAgICBsYXlvdXRUZXN0Q29udHJvbGxlci5kdW1wQXNUZXh0KCk7 Cit9CisKK3dpbmRvdy5vbmxvYWQgPSBmdW5jdGlvbigpCit7CisgICAgaWYgKCF3aW5kb3cubGF5 b3V0VGVzdENvbnRyb2xsZXIpCisgICAgICAgIHJldHVybjsKKworICAgIGZvciAodmFyIGkgPSAx OyBpIDw9IDU7IGkrKykgeworICAgICAgICB2YXIgYUVsZW1lbnQgPSBkb2N1bWVudC5nZXRFbGVt ZW50QnlJZCgnYScgKyBpKTsKKyAgICAgICAgYUVsZW1lbnQub25mb2N1cyA9IGhhbmRsZUZvY3Vz OworICAgICAgICBldmVudFNlbmRlci5tb3VzZU1vdmVUbyhhRWxlbWVudC5vZmZzZXRMZWZ0ICsg MiwgYUVsZW1lbnQub2Zmc2V0VG9wICsgMik7CisgICAgICAgIGV2ZW50U2VuZGVyLm1vdXNlRG93 bigpOworICAgICAgICBldmVudFNlbmRlci5tb3VzZVVwKCk7CisgICAgfQorCisgICAgdmFyIHRj ID0gZG9jdW1lbnQuZ2V0RWxlbWVudEJ5SWQoJ3Rlc3QtY29udGFpbmVyJyk7CisgICAgdGMucGFy ZW50Tm9kZS5yZW1vdmVDaGlsZCh0Yyk7Cit9OworCis8L3NjcmlwdD4KKzwvYm9keT4KKzwvaHRt bD4KSW5kZXg6IExheW91dFRlc3RzL2Zhc3QvZXZlbnRzL2NsaWNrLWZvY3VzLWNvbnRyb2wtZXhw ZWN0ZWQudHh0Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT0KLS0tIExheW91dFRlc3RzL2Zhc3QvZXZlbnRzL2NsaWNrLWZv Y3VzLWNvbnRyb2wtZXhwZWN0ZWQudHh0CShyZXZpc2lvbiAwKQorKysgTGF5b3V0VGVzdHMvZmFz dC9ldmVudHMvY2xpY2stZm9jdXMtY29udHJvbC1leHBlY3RlZC50eHQJKHJldmlzaW9uIDApCkBA IC0wLDAgKzEsMTIgQEAKK1RoaXMgdGVzdCBlbnN1cmVzIHRoYXQgd2UgY2FuIGNsaWNrIHRvIGZv Y3VzIGFuIGEgZWxlbWVudC4gQ2xpY2sgb24gdGhlIGVsZW1lbnQgYmVsb3cuCisKK1RoZSBleHBl Y3RlZCByZXN1bHQgaXMgcGxhdGZvcm0gc3BlY2lmaWMuIE1hYyBkb2Vzbid0IGFsbG93IHNvbWUg Zm9ybSBjb250cm9scyB0byBiZSBtb3VzZSBmb2N1c2FibGUuCisKK1Jlc3VsdAorCisKK2ExIHJl Y2VpdmVkIGZvY3VzICgpCithMiByZWNlaXZlZCBmb2N1cyAoKQorYTMgcmVjZWl2ZWQgZm9jdXMg KCkKK2E0IHJlY2VpdmVkIGZvY3VzICgpCithNSByZWNlaXZlZCBmb2N1cyAoKQpJbmRleDogTGF5 b3V0VGVzdHMvQ2hhbmdlTG9nCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIExheW91dFRlc3RzL0NoYW5nZUxvZwko cmV2aXNpb24gNTc1MDIpCisrKyBMYXlvdXRUZXN0cy9DaGFuZ2VMb2cJKHdvcmtpbmcgY29weSkK QEAgLTEsMyArMSwxNCBAQAorMjAxMC0wNC0xMiAgVmlhdGNoZXNsYXYgT3N0YXBlbmtvICA8b3N0 YXBlbmtvLnZpYXRjaGVzbGF2QG5va2lhLmNvbT4KKworICAgICAgICBSZXZpZXdlZCBieSBOT0JP RFkgKE9PUFMhKS4KKworICAgICAgICBMYXlvdXQgdGVzdHMgZm9yIGZpeCBmb2N1c2luZyBvZiBj b250cm9sIGVsZW1lbnRzIG9uIG1vdXNlIGNsaWNrLgorICAgICAgICBodHRwczovL2J1Z3Mud2Vi a2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MjIyNjEuCisKKyAgICAgICAgKiBmYXN0L2V2ZW50cy9j bGljay1mb2N1cy1jb250cm9sLWV4cGVjdGVkLnR4dDogQWRkZWQuCisgICAgICAgICogZmFzdC9l dmVudHMvY2xpY2stZm9jdXMtY29udHJvbC5odG1sOiBBZGRlZC4KKyAgICAgICAgKiBwbGF0Zm9y bS9tYWMvU2tpcHBlZDoKKwogMjAxMC0wNC0xMiAgRGFuaWVsIEJhdGVzICA8ZGJhdGVzQHJpbS5j b20+CiAKICAgICAgICAgUmV2aWV3ZWQgYnkgQWRhbSBCYXJ0aC4K 56930 2010-05-24 14:49:07 -0700 2010-10-10 11:15:36 -0700 Add comment to Changelog. control_mouse_focusing_fix_03.diff text/plain 5358 ostap73 SW5kZXg6IFdlYkNvcmUvQ2hhbmdlTG9nCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFdlYkNvcmUvQ2hhbmdlTG9n CShyZXZpc2lvbiA1OTc3NykKKysrIFdlYkNvcmUvQ2hhbmdlTG9nCSh3b3JraW5nIGNvcHkpCkBA IC0xLDMgKzEsMTYgQEAKKzIwMTAtMDUtMjQgIFZpYXRjaGVzbGF2IE9zdGFwZW5rbyAgPG9zdGFw ZW5rby52aWF0Y2hlc2xhdkBub2tpYS5jb20+CisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZ IChPT1BTISkuCisKKyAgICAgICAgRml4IGZvY3VzaW5nIG9mIGNvbnRyb2wgZWxlbWVudHMgb24g bW91c2UgY2xpY2suCisgICAgICAgIEJyaW5ncyBHVEsgZml4IHRvIGFsbCBwbGF0Zm9ybXMgZXhj ZXB0IE1hYy4KKyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lk PTIyMjYxCisKKyAgICAgICAgVGVzdDogZmFzdC9ldmVudHMvY2xpY2stZm9jdXMtY29udHJvbC5o dG1sCisKKyAgICAgICAgKiBodG1sL0hUTUxGb3JtQ29udHJvbEVsZW1lbnQuY3BwOgorICAgICAg ICAoV2ViQ29yZTo6SFRNTEZvcm1Db250cm9sRWxlbWVudDo6aXNNb3VzZUZvY3VzYWJsZSk6CisK IDIwMTAtMDUtMTkgIEFuZGVycyBDYXJsc3NvbiAgPGFuZGVyc2NhQGFwcGxlLmNvbT4KIAogICAg ICAgICBSZXZpZXdlZCBieSBTYW0gV2VpbmlnLgpJbmRleDogV2ViQ29yZS9odG1sL0hUTUxGb3Jt Q29udHJvbEVsZW1lbnQuY3BwCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFdlYkNvcmUvaHRtbC9IVE1MRm9ybUNv bnRyb2xFbGVtZW50LmNwcAkocmV2aXNpb24gNTk3MTEpCisrKyBXZWJDb3JlL2h0bWwvSFRNTEZv cm1Db250cm9sRWxlbWVudC5jcHAJKHdvcmtpbmcgY29weSkKQEAgLTI3OSwxMCArMjc5LDEwIEBA IGJvb2wgSFRNTEZvcm1Db250cm9sRWxlbWVudDo6aXNLZXlib2FyZEYKIAogYm9vbCBIVE1MRm9y bUNvbnRyb2xFbGVtZW50Ojppc01vdXNlRm9jdXNhYmxlKCkgY29uc3QKIHsKLSNpZiBQTEFURk9S TShHVEspCi0gICAgcmV0dXJuIEhUTUxFbGVtZW50Ojppc01vdXNlRm9jdXNhYmxlKCk7Ci0jZWxz ZQorI2lmIFBMQVRGT1JNKE1BQykKICAgICByZXR1cm4gZmFsc2U7CisjZWxzZQorICAgIHJldHVy biBIVE1MRWxlbWVudDo6aXNNb3VzZUZvY3VzYWJsZSgpOwogI2VuZGlmCiB9CiAKSW5kZXg6IExh eW91dFRlc3RzL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBMYXlvdXRUZXN0cy9DaGFuZ2VMb2cJ KHJldmlzaW9uIDU5NzExKQorKysgTGF5b3V0VGVzdHMvQ2hhbmdlTG9nCSh3b3JraW5nIGNvcHkp CkBAIC0xLDMgKzEsMTQgQEAKKzIwMTAtMDUtMjQgIFZpYXRjaGVzbGF2IE9zdGFwZW5rbyAgPG9z dGFwZW5rby52aWF0Y2hlc2xhdkBub2tpYS5jb20+CisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9C T0RZIChPT1BTISkuCisKKyAgICAgICAgTGF5b3V0IHRlc3RzIGZvciBmaXggZm9jdXNpbmcgb2Yg Y29udHJvbCBlbGVtZW50cyBvbiBtb3VzZSBjbGljay4KKyAgICAgICAgaHR0cHM6Ly9idWdzLndl YmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTIyMjYxLgorCisgICAgICAgICogZmFzdC9ldmVudHMv Y2xpY2stZm9jdXMtY29udHJvbC1leHBlY3RlZC50eHQ6IEFkZGVkLgorICAgICAgICAqIGZhc3Qv ZXZlbnRzL2NsaWNrLWZvY3VzLWNvbnRyb2wuaHRtbDogQWRkZWQuCisgICAgICAgICogcGxhdGZv cm0vbWFjL1NraXBwZWQ6CisKIDIwMTAtMDUtMTggIEp1c3RpbiBTY2h1aCAgPGpzY2h1aEBjaHJv bWl1bS5vcmc+CiAKICAgICAgICAgUmV2aWV3ZWQgYnkgQWRhbSBCYXJ0aC4KSW5kZXg6IExheW91 dFRlc3RzL2Zhc3QvZXZlbnRzL2NsaWNrLWZvY3VzLWNvbnRyb2wtZXhwZWN0ZWQudHh0Cj09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT0KLS0tIExheW91dFRlc3RzL2Zhc3QvZXZlbnRzL2NsaWNrLWZvY3VzLWNvbnRyb2wtZXhw ZWN0ZWQudHh0CShyZXZpc2lvbiAwKQorKysgTGF5b3V0VGVzdHMvZmFzdC9ldmVudHMvY2xpY2st Zm9jdXMtY29udHJvbC1leHBlY3RlZC50eHQJKHJldmlzaW9uIDApCkBAIC0wLDAgKzEsMTIgQEAK K1RoaXMgdGVzdCBlbnN1cmVzIHRoYXQgd2UgY2FuIGNsaWNrIHRvIGZvY3VzIGFuIGEgZWxlbWVu dC4gQ2xpY2sgb24gdGhlIGVsZW1lbnQgYmVsb3cuCisKK1RoZSBleHBlY3RlZCByZXN1bHQgaXMg cGxhdGZvcm0gc3BlY2lmaWMuIE1hYyBkb2Vzbid0IGFsbG93IHNvbWUgZm9ybSBjb250cm9scyB0 byBiZSBtb3VzZSBmb2N1c2FibGUuCisKK1Jlc3VsdAorCisKK2ExIHJlY2VpdmVkIGZvY3VzICgp CithMiByZWNlaXZlZCBmb2N1cyAoKQorYTMgcmVjZWl2ZWQgZm9jdXMgKCkKK2E0IHJlY2VpdmVk IGZvY3VzICgpCithNSByZWNlaXZlZCBmb2N1cyAoKQpJbmRleDogTGF5b3V0VGVzdHMvZmFzdC9l dmVudHMvY2xpY2stZm9jdXMtY29udHJvbC5odG1sCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIExheW91dFRlc3Rz L2Zhc3QvZXZlbnRzL2NsaWNrLWZvY3VzLWNvbnRyb2wuaHRtbAkocmV2aXNpb24gMCkKKysrIExh eW91dFRlc3RzL2Zhc3QvZXZlbnRzL2NsaWNrLWZvY3VzLWNvbnRyb2wuaHRtbAkocmV2aXNpb24g MCkKQEAgLTAsMCArMSw4NiBAQAorPCFET0NUWVBFIGh0bWw+Cis8aHRtbD4KKzxoZWFkPgorPC9o ZWFkPgorPGJvZHk+CisKKzxwPlRoaXMgdGVzdCBlbnN1cmVzIHRoYXQgd2UgY2FuIGNsaWNrIHRv IGZvY3VzIGFuIGEgZWxlbWVudC4KK0NsaWNrIG9uIHRoZSBlbGVtZW50IGJlbG93LgorCis8cD5U aGUgZXhwZWN0ZWQgcmVzdWx0IGlzIHBsYXRmb3JtIHNwZWNpZmljLiBNYWMgZG9lc24ndCBhbGxv dyBzb21lIGZvcm0gY29udHJvbHMgdG8gYmUKK21vdXNlIGZvY3VzYWJsZS4KKworPGRpdiBpZD10 ZXN0LWNvbnRhaW5lcj4KKzxmb3JtIGlkPSJmb3JtMSI+Cis8cD4KKzxzdHJvbmc+VGhpcyBpcyBm b3JtMTwvc3Ryb25nPjxici8+CisKK0ZpcnN0IG5hbWUgaGVyZTxici8+Cis8aW5wdXQgdHlwZT0i dGV4dCIgbmFtZT0ibmFtZSIgdGl0bGU9ImlucHV0IG5hbWUiIHNpemU9IjYiIG1heGxlbmd0aD0i MTAiLz48YnIvPgorCitQYXNzd29yZDo8YnIvPgorPGlucHV0IHR5cGU9InBhc3N3b3JkIiBuYW1l PSJwYXNzd29yZCIgc2l6ZT0iNiIgbWF4bGVuZ3RoPSIxMCIvPjxici8+CisKK2NvbW1lbnRzOjxi ci8+Cis8dGV4dGFyZWEgbmFtZT0iY29tbWVudHMiIHRpdGxlPSJ0ZXh0YXJlYSBjb21tZW50cyIg cm93cz0iMiIgY29scz0iMjAiPmFueXRoaW5nIGZvcm0xIGdvZXMgaGVyZTwvdGV4dGFyZWE+PGJy Lz4KKworU2VsZWN0IDE6PGJyLz4KKzxpbnB1dCBpZD1hMSB0eXBlPSJyYWRpbyIgbmFtZT0icmFk aW8xIiB2YWx1ZT0icmFkaW8xYSIvPjxici8+Cis8aW5wdXQgaWQ9YTIgdHlwZT0icmFkaW8iIG5h bWU9InJhZGlvMSIgdmFsdWU9InJhZGlvMWIiLz48YnIvPgorCitDaGVjayBpdDo8YnIvPgorPGlu cHV0IGlkPWEzIHR5cGU9ImNoZWNrYm94IiBuYW1lPSJjaGVja2JveDEiIHZhbHVlPSJjaGVja2Jv eDEiLz48YnIvPgorCitTZWxlY3QgMTo8YnIvPgorICA8c2VsZWN0IGlkPWE0IG5hbWU9IlNlbGVj dCIgc2l6ZT0iMiI+CisgICAgPG9wdGlvbj4xPC9vcHRpb24+CisgICAgPG9wdGlvbj4yPC9vcHRp b24+CisgICAgPG9wdGlvbiBzZWxlY3RlZD0ic2VsZWN0ZWQiPjM8L29wdGlvbj4KKyAgICA8b3B0 aW9uPjQ8L29wdGlvbj4KKyAgPC9zZWxlY3Q+PGJyLz4KKzxpbnB1dCBpZD1hNSB0eXBlPSJidXR0 b24iIG5hbWU9ImJ1dHRvbiIgdmFsdWU9IkJ1dHRvbiAxIi8+Cis8L3A+PC9mb3JtPjxwPjxzdHJv bmc+RW5kIGZvcm0xPC9zdHJvbmc+PC9wPgorPC9kaXY+CisKKzxwPlJlc3VsdAorCis8cHJlIGlk PW91dD48L3ByZT4KKworPHNjcmlwdD4KKworZnVuY3Rpb24gbG9nKHMpCit7CisgICAgdmFyIGVs ID0gZG9jdW1lbnQuZ2V0RWxlbWVudEJ5SWQoJ291dCcpOworICAgIGVsLnRleHRDb250ZW50ICs9 ICdcbicgKyBzOworfQorCitmdW5jdGlvbiBoYW5kbGVGb2N1cyhlKQoreworICAgIHZhciBlbCA9 IGUudGFyZ2V0OworICAgIGxvZyhlbC5pZCArICcgcmVjZWl2ZWQgZm9jdXMgKCcgKyBlbC50aXRs ZSArICcpJyk7Cit9CisKK2lmICh3aW5kb3cubGF5b3V0VGVzdENvbnRyb2xsZXIpIHsKKyAgICBs YXlvdXRUZXN0Q29udHJvbGxlci5kdW1wQXNUZXh0KCk7Cit9CisKK3dpbmRvdy5vbmxvYWQgPSBm dW5jdGlvbigpCit7CisgICAgaWYgKCF3aW5kb3cubGF5b3V0VGVzdENvbnRyb2xsZXIpCisgICAg ICAgIHJldHVybjsKKworICAgIGZvciAodmFyIGkgPSAxOyBpIDw9IDU7IGkrKykgeworICAgICAg ICB2YXIgYUVsZW1lbnQgPSBkb2N1bWVudC5nZXRFbGVtZW50QnlJZCgnYScgKyBpKTsKKyAgICAg ICAgYUVsZW1lbnQub25mb2N1cyA9IGhhbmRsZUZvY3VzOworICAgICAgICBldmVudFNlbmRlci5t b3VzZU1vdmVUbyhhRWxlbWVudC5vZmZzZXRMZWZ0ICsgMiwgYUVsZW1lbnQub2Zmc2V0VG9wICsg Mik7CisgICAgICAgIGV2ZW50U2VuZGVyLm1vdXNlRG93bigpOworICAgICAgICBldmVudFNlbmRl ci5tb3VzZVVwKCk7CisgICAgfQorCisgICAgdmFyIHRjID0gZG9jdW1lbnQuZ2V0RWxlbWVudEJ5 SWQoJ3Rlc3QtY29udGFpbmVyJyk7CisgICAgdGMucGFyZW50Tm9kZS5yZW1vdmVDaGlsZCh0Yyk7 Cit9OworCis8L3NjcmlwdD4KKzwvYm9keT4KKzwvaHRtbD4KSW5kZXg6IExheW91dFRlc3RzL3Bs YXRmb3JtL21hYy9Ta2lwcGVkCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIExheW91dFRlc3RzL3BsYXRmb3JtL21h Yy9Ta2lwcGVkCShyZXZpc2lvbiA1OTcxMSkKKysrIExheW91dFRlc3RzL3BsYXRmb3JtL21hYy9T a2lwcGVkCSh3b3JraW5nIGNvcHkpCkBAIC0xOTEsMyArMTkxLDcgQEAgc3RvcmFnZS9pbmRleGVk ZGIKIAogIyBOZWVkIHRvIGludmVzdGlnYXRlIHdoeSBpdCB0aW1lcyBvdXQgaW4gTWFjIGJvdHMu CiBmYXN0L2ZpbGVzL2ZpbGUtcmVhZGVyLmh0bWwKKyAKKyMgTWFjIHNob3VsZG4ndCBmb2N1cyBv biBzb21lIGNvbnRyb2wgZWxlbWVudHMgCisjIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3df YnVnLmNnaT9pZD0yMjI2MSAKK2Zhc3QvZXZlbnRzL2NsaWNrLWZvY3VzLWNvbnRyb2wuaHRtbCAK