14427 – Investigate if click()'s click-in-progress should apply to user and/or script initiated clicks

This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 14427 - Investigate if click()'s click-in-progress should apply to user and/or script initiated clicks

Summary: Investigate if click()'s click-in-progress should apply to user and/or script...

Status:	RESOLVED FIXED

Alias:	None

Product:	HTML WG
Classification:	Unclassified
Component:	HTML5 spec (show other bugs)
Version:	unspecified
Hardware:	PC Linux

Importance:	P2 normal
Target Milestone:	---
Assignee:	Ian 'Hixie' Hickson
QA Contact:	HTML WG Bugzilla archive list

URL:
Whiteboard:
Keywords:

Depends on:	14471
Blocks:
	Show dependency tree / graph

Reported:	2011-10-11 11:37 UTC by Olli Pettay
Modified:	2011-11-04 17:39 UTC (History)
CC List:	6 users (show)

See Also:

Attachments

Description Olli Pettay 2011-10-11 11:37:25 UTC

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())

Comment 1 Olli Pettay 2011-10-11 11:43:14 UTC

If the spec is changed, it should be defined if script initiated event
(document.createEvent("mouseevent"), .initMouseEvent(...), dispatchEvent) should
set the flag.

Comment 2 Olli Pettay 2011-10-13 23:15:22 UTC

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.

Comment 3 Ian 'Hixie' Hickson 2011-10-14 18:36:58 UTC

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.

Comment 4 Boris Zbarsky 2011-10-14 18:39:36 UTC

> 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?

Comment 5 Olli Pettay 2011-10-14 19:18:08 UTC

(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.

Comment 6 Ian 'Hixie' Hickson 2011-10-24 23:22:56 UTC

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?

Comment 7 Ian 'Hixie' Hickson 2011-10-26 23:30:18 UTC

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

Comment 8 Olli Pettay 2011-10-27 10:16:03 UTC

(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.

Comment 9 Ian 'Hixie' Hickson 2011-10-28 19:46:15 UTC

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?

Comment 10 Olli Pettay 2011-10-28 21:48:07 UTC

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.

Comment 11 Ian 'Hixie' Hickson 2011-10-30 18:17:33 UTC

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!

Comment 12 Olli Pettay 2011-10-30 18:34:40 UTC

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.

Comment 13 Ian 'Hixie' Hickson 2011-11-03 16:02:17 UTC

That seems reasonable.

Comment 14 Ian 'Hixie' Hickson 2011-11-04 17:30:05 UTC

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.

Comment 15 contributor 2011-11-04 17:31:01 UTC

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

Comment 16 contributor 2011-11-04 17:39:47 UTC

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