14427 2011-10-11 11:37:25 +0000 Investigate if click()'s click-in-progress should apply to user and/or script initiated clicks 2011-11-04 17:39:47 +0000 1 1 1 Unclassified HTML WG HTML5 spec unspecified PC Linux RESOLVED FIXED P2 normal --- 14471 1 bugs ian annevk bzbarsky ian mike public-html-admin public-html-wg-issue-tracking public-html-bugzilla oldest_to_newest 58043 0 bugs 2011-10-11 11:37:25 +0000 Currently if user clicks <a href="http://www.w3c.org" target="_blank" onclick="this.click()">foo</a> that will per spec open two new browsing contexts. That is how Gecko works. IE9 and Opera have different behavior. They seems to set click-in-progress flag also when user clicks. But they don't handle that in the same way. https://bugzilla.mozilla.org/show_bug.cgi?id=679566#c17 IE sets the flag only to event target, Opera also to ancestors, or something like that. IE's behavior is very error prone, so either the spec should stay as it is, or it should follow what Opera does. (Webkit doesn't have a.click()) 58044 1 bugs 2011-10-11 11:43:14 +0000 If the spec is changed, it should be defined if script initiated event (document.createEvent("mouseevent"), .initMouseEvent(...), dispatchEvent) should set the flag. 58206 2 bugs 2011-10-13 23:15:22 +0000 Actually IE's behavior could be the right one. Script should be able to initiate some other click, and even in the same event target chain as the original one. It is just that the same event target shouldn't be triggered. 58241 3 ian 2011-10-14 18:36:58 +0000 Per the spec, there'll be only one window open, but the reason is a bit weird: it's because the event fired for the click() method is not trusted, so that window is popup-blocked (popups in the spec are only allowed if all the current click events are trusted). The 'onclick' event handler does trigger twice; the second time it triggers, the click() method does nothing, because the element's click-in-progress flag is set. As far as I can tell, what the spec says here seems reasonable. 58242 4 bzbarsky 2011-10-14 18:39:36 +0000 > popups in the spec are only allowed if all the current click events are trusted Why? This makes it so that a user triggering a keyboard event that calls click() to open a popup would fail. Is that web-compatible? 58248 5 bugs 2011-10-14 19:18:08 +0000 (In reply to comment #3) > Per the spec, there'll be only one window open, but the reason is a bit weird: > it's because the event fired for the click() method is not trusted, so that > window is popup-blocked (popups in the spec are only allowed if all the current > click events are trusted). That makes no sense. I'll file a spec bug about that. 58795 6 ian 2011-10-24 23:22:56 +0000 Keyboard events can directly cause the link to be followed (hitting enter triggers a trusted click event). I don't mind changing this stuff, it's not been carefully reviewed as far as I know. In any case, I'll address this in bug 14471. As far as this bug is concerned, I don't see anything that needs to change. Any objections to closing the bug? 59023 7 ian 2011-10-26 23:30:18 +0000 EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: see comment 6 59063 8 bugs 2011-10-27 10:16:03 +0000 (In reply to comment #6) > Keyboard events can directly cause the link to be followed (hitting enter > triggers a trusted click event). I don't mind changing this stuff, it's not > been carefully reviewed as far as I know. In any case, I'll address this in bug > 14471. > > As far as this bug is concerned, I don't see anything that needs to change. Any > objections to closing the bug? It is just that there are apparently some scripts which end up calling .click() in the element which user activated. IE and Opera open the link just once, but per spec it should be opened twice. Gecko follows the spec and that has lead to at least one bug in Mozilla's bugzilla. 59145 9 ian 2011-10-28 19:46:15 +0000 Ah, that's good to know. Ok. What would you like the spec to say, then? You describe IE's behaviour as "error-prone" in comment 0, so I presume you're not a fan of that one? I'm not sure what to do here. It would be rather messy to add this flag around all activation behaviours, but I suppose we could do that? 59154 10 bugs 2011-10-28 21:48:07 +0000 As I say in comment 2, I changed my mind and prefer what IE does. But I'd like to know why Opera has implemented the click flag handling differently. 59237 11 ian 2011-10-30 18:17:33 +0000 I don't understand what IE does, so if you want the spec to say that, please describe it in sufficient detail that I can specify it! 59239 12 bugs 2011-10-30 18:34:40 +0000 IE seems to set the flag to event target whenever click is dispatched. So, not only during click() but also when user clicks some element etc. 59556 13 ian 2011-11-03 16:02:17 +0000 That seems reasonable. 59630 14 ian 2011-11-04 17:30:05 +0000 EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Accepted Change Description: see diff given below Rationale: Concurred with reporter's comments. 59631 15 contributor 2011-11-04 17:31:01 +0000 Checked in as WHATWG revision r6817. Check-in comment: Change how nested clicks are prevented to also prevent click() inside a regular onclick=''. http://html5.org/tools/web-apps-tracker?from=6816&to=6817 59632 16 contributor 2011-11-04 17:39:47 +0000 Checked in as WHATWG revision r6818. Check-in comment: Change how nested clicks are prevented to also prevent click() inside a regular onclick=''. (part 2) http://html5.org/tools/web-apps-tracker?from=6817&to=6818