47182 2010-10-05 08:34:56 -0700 Focus remains on hidden element 2017-04-24 17:24:01 -0700 1 1 1 Unclassified WebKit WebCore Misc. 528+ (Nightly build) All All NEW https://bugs.chromium.org/p/chromium/issues/detail?id=491828 https://bugzilla.mozilla.org/show_bug.cgi?id=559561 http://xirc.chez.com/ie9-focus-display-none.html InRadar P2 Normal --- 1 duke_the_killer webkit-unassigned ap cdumez code.vineet darin kaustubh.ra manian m.goleb+bugzilla rego rniwa webkit-bug-importer oldest_to_newest 289628 0 69791 duke_the_killer 2010-10-05 08:34:56 -0700 Created attachment 69791 Demo Focus remains on element after its parent container is styled with display:none. Wait a second until element is hidden. Press any key. You will receive a message, proving now-hidden element still has focus. 289816 1 ap 2010-10-05 12:53:51 -0700 This is a difference with Firefox, but I don't see why this is necessarily a bad behavior. 290047 2 duke_the_killer 2010-10-05 19:48:21 -0700 Inconsistency is bad An element keeps its focus after being hidden But a hidden element cannot gain focus In fact, Internet Explorer is like Firefox when you set style.display="none" (I was reporting the bug with that demo) To recap: http://xirc.chez.com/ie9-focus-1.html (focus then style.display) Allowed by Opera / Safari http://xirc.chez.com/ie9-focus-2.html (focus then className) Allowed by Opera / Safari / Internet Explorer http://xirc.chez.com/ie9-focus-3.html (style.display then focus) Allowed by Opera http://xirc.chez.com/ie9-focus-4.html (className then focus) Allowed by Opera 290073 3 ap 2010-10-05 20:47:07 -0700 Yes, we should be different if IE and Firefox both do the same thing. 463935 4 kaustubh.ra 2011-09-08 00:14:12 -0700 here the issue seems to be cancelFocusAppearenceUpdate() call. Which does remove the focus appearance but does not set the focus back to 0. The current usage of this call is only in focus() & detach() calls in Element.cpp. We can add setFocus(0) in this function definition to avoid retaining of the focus after display:none. Element::blur() does the same thing, which we might able to use here. 479881 5 kaustubh.ra 2011-10-07 02:11:29 -0700 Is this issue to be fixed? Seems to be inconsistent on different platforms. 479929 6 code.vineet 2011-10-07 04:16:52 -0700 I think we have similar issue https://bugs.webkit.org/show_bug.cgi?id=40338 . 480518 7 rniwa 2011-10-08 00:46:56 -0700 (In reply to comment #5) > Is this issue to be fixed? Seems to be inconsistent on different platforms. I think we should fix it. But it'll be nice to bring it up on whatwg to specify this behavior if it hasn't been done so already. 480522 8 rniwa 2011-10-08 00:53:25 -0700 One tricky part of fixing this bug will be that we must fire blur event before removing the focus. Since we wouldn't know whether an element is visible or not until style recalc, it might have a weird side effects. For example, we had decided to remove the focus when at the end of style-recalc, we might have a trouble dealing with situations like: var element = ... element.focus(); element.style.display = 'none'; element.title = 'hello'; // blur hasn't fired yet here var x = element.offsetTop; // blur fires here Because style recalc doesn't happen until offsetTop is obtained in the last line. 480536 9 kaustubh.ra 2011-10-08 02:18:42 -0700 Right, so if we fire the blur event and then call blur instead of cancelFocusApperance() will be right way to do it? Also, i tried with blur replacing cancelFocusApperance, but its causing few layout tests to be failed. Need to look in more detail. 480571 10 ap 2011-10-08 09:59:04 -0700 We should be very careful when considering changes in this area. Accepting key events on an invisible element is a fairly common technique - my understanding is that even Google Docs does something similar. 480576 11 rniwa 2011-10-08 10:43:21 -0700 (In reply to comment #9) > Right, so if we fire the blur event and then call blur instead of cancelFocusApperance() will be right way to do it? Also, i tried with blur replacing cancelFocusApperance, but its causing few layout tests to be failed. Need to look in more detail. The real question is when to call those functions. Checking the computed value of display property of the focused node every time style changes is prohibitively inefficient and expensive. On the other hand, if we wait until style recalc happens, then there will be a noticeable delay between the time the element was hidden and blur is fired. 573604 12 kaustubh.ra 2012-03-07 22:12:22 -0800 The whatwg mailing list thread for the issue - http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-February/034929.html 593103 13 rniwa 2012-04-01 17:21:51 -0700 To paraphrase Ian's response, the spec requires the focus be dropped in this case. 593107 14 rniwa 2012-04-01 17:32:22 -0700 Also see https://bugs.webkit.org/show_bug.cgi?id=40338. 1295936 15 rego 2017-04-10 02:22:43 -0700 It seems only Chrome behaves like this, and the spec text seems to support that behavior: https://bugs.chromium.org/p/chromium/issues/detail?id=491828 Issues in other bugtrackers: * Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=559561 * Edge: https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/1308960/ 1300753 16 webkit-bug-importer 2017-04-24 17:24:01 -0700 <rdar://problem/31801261> 69791 2010-10-05 08:34:56 -0700 2010-10-05 08:34:56 -0700 Demo ie9-focus-display-none.html text/html 944 duke_the_killer PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBYSFRNTCAxLjAgVHJhbnNpdGlvbmFs Ly9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL3hodG1sMS9EVEQveGh0bWwxLXRyYW5zaXRpb25h bC5kdGQiPg0KPGh0bWwgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkveGh0bWwiIGxhbmc9 ImVuIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0 ZXh0L2h0bWw7IGNoYXJzZXQ9VVRGLTgiIC8+DQo8dGl0bGU+Rm9jdXMgcmVtYWlucyBvbiBoaWRk ZW4gZWxlbWVudDwvdGl0bGU+DQoNCjxzY3JpcHQgdHlwZT0idGV4dC9qYXZhc2NyaXB0Ij4NCndp bmRvdy5zZXRUaW1lb3V0KGZ1bmN0aW9uICgpIHsNCglkb2N1bWVudC5nZXRFbGVtZW50QnlJZCgi dHN0X2kiKS5vbmtleWRvd24gPSBmdW5jdGlvbiAoKSB7IGFsZXJ0KCJrZXlkb3duIG9uIGludmlz aWJsZSBlbGVtZW50ISIpOyB9Ow0KCWRvY3VtZW50LmdldEVsZW1lbnRCeUlkKCJ0c3RfaSIpLmZv Y3VzKCk7DQoNCgkvL3dpbmRvdy5mb2N1cygpOw0KDQoJZG9jdW1lbnQuZ2V0RWxlbWVudEJ5SWQo InRzdF9kIikuY2xhc3NOYW1lID0gImhpZGRlbiI7DQp9LCAxMDAwKTsNCjwvc2NyaXB0Pg0KDQo8 c3R5bGUgdHlwZT0idGV4dC9jc3MiPg0KLmhpZGRlbiB7IGRpc3BsYXk6bm9uZTsgfQ0KPC9zdHls ZT4NCg0KPC9oZWFkPg0KPGJvZHk+DQoNCjxoMz5XYWl0IGEgc2Vjb25kIGFuZCBwcmVzcyBhbnkg a2V5PC9oMz4NCjxkaXYgaWQ9InRzdF9kIj4NCjxpbnB1dCB0eXBlPSJ0ZXh0IiBpZD0idHN0X2ki IC8+DQo8IS0tPHRleHRhcmVhIGNvbHM9IjEwIiByb3dzPSIxMCIgaWQ9InRzdF9pIj48L3RleHRh cmVhPi0tPg0KPCEtLTxkaXYgaWQ9InRzdF9pIiBjb250ZW50ZWRpdGFibGU9InRydWUiPjwvZGl2 Pi0tPg0KPC9kaXY+DQoNCjwvYm9keT4NCjwvaHRtbD4=