1195587 - DoubleClicking Event Listeners button (ev) should respect the number of clicks

Status: RESOLVED FIXED

(DevTools :: Inspector, defect, P3)

Description

[arni2033]

Attachment: DoubleClicking Event Listeners button (ev) should respect the number of clicks.webm

STR: (Win7, Nightly 43.0a1 (2015-08-16))
1. Open page   data:text/html,<a oncut>
2. Open devtools->Inspector
3. DoubleClick (ev) button near closing tag </a>

Result:       [watch video] Event listeners popup is opened
Expectations: It should work as if I clicked (ev), then clicked it again. So, popup should be closed

Comment 1

[Patrick Brosset <:pbro>]

Tempted to close this as WONTFIX because of bug 1259834. Also because I don't feel like this is really an issue. As a user, if I double click on the ev icon, it's probably because I actually meant to single click but made a mistake. In any case, I wanted to see the tooltip.
Julian, can you check how this behaves with the new HTML tooltip API? And please take the final decision as to whether or not we need to fix or close this.

Comment 2

[arni2033]

(In reply to Patrick Brosset <:pbro> from comment #1)
> In any case, I wanted to see the tooltip.
After _one_ click. If a user is fast enough to click twice, the button should work as a normal toggle: to change state. Clicking on the same place is preferable, because clicking in other places may focus unwanted stuff, open link, twitch content, etc. I filed several cases of that. 

Anyway, even if handling doubleclick differently from "click+click" is an intentional bug, current behavior is still incorrect. I don't want to report the same issue twice, so I modified expectations:

AR:  Event listener blinks and stays open [watch video]
ER:  Either A or B
 A) Tooltip should hide, i.e. the (ev) button should act like a normal toggle   [preferable]
 B) Tooltip should stay open w/o blinking

Comment 3

[Julian Descottes [:jdescottes]]

Attachment: markupview-eventbutton-toggle-demo.gif

Event before trying to double-click, the "ev" button is not a toggle at all. If you click on it when the tooltip is already opened, it will blink and reopen. I tried on several FF version? anyone seeing something different?

I think we should fix this first.

The HTML tooltip will behave the same in this situation. We have a property called "consumeOutsideClick" which is available in both Tooltip and HTMLTooltip. 

Here it is "false", which means that when you click, the tooltip is closed, but the "click" event will fire other listeners. Setting it to "true" seems to fix the issue here.

Arni: you said you had other bugs logged for the same issue, do you have one for the root issue I mentioned above?

Helen: Do you agree that the "ev" button should act as a toggle here (as in the attachment I upload here).

Comment 4

[Patrick Brosset <:pbro>]

(In reply to Julian Descottes [:jdescottes] from comment #3)
> If you click on it when the tooltip is already opened, it will blink and
> reopen. I tried on several FF version? anyone seeing something different?
I see something different on windows 10/FF48. When I click on the (ev) button while the tooltip is already opened, the tooltip just closes.
On Mac/FF48 though, it does blink and reopen.
I tried something else: open a tooltip and then click on *another* (ev) button. When I do this, the tooltip closes and the other tooltip opens, on both Windows and Mac, in the same way.

Comment 5

[Julian Descottes [:jdescottes]]

(In reply to Patrick Brosset <:pbro> from comment #4)
> (In reply to Julian Descottes [:jdescottes] from comment #3)
> > If you click on it when the tooltip is already opened, it will blink and
> > reopen. I tried on several FF version? anyone seeing something different?
> I see something different on windows 10/FF48. When I click on the (ev)
> button while the tooltip is already opened, the tooltip just closes.
> On Mac/FF48 though, it does blink and reopen.

Thanks for the info Patrick. What I described is a separate OSX-only issue then. 

From my investigation, even with consumeOutsideClicks=false, the click on the anchor is consumed when the panel is hidden. 
Looking at the code, while consumeOutsideClicks is documented as a boolean, it actually supports 3 states:
- true : consume all outside clicks
- parentOnly : consume clicks only on the anchor
- never : never consume clicks

(see https://dxr.mozilla.org/mozilla-central/source/layout/xul/nsMenuPopupFrame.cpp#1622 for an entry point)

It seems on Windows, parentOnly is used when setting "false"
- <panel consumeoutsideclicks=false> => uses "parentOnly"
- <panel consumeoutsideclicks=never> => uses "never"
- * anything else => uses true 

I don't really understand why the behavior is different on OSX here, if I have more time I'll try to isolate the issue. I also could not find any attribute value to force parentOnly on OSX. (maybe it's actually on but doesn't work in this particular case?)

Sadly using consumeOutsideClick=true on Windows does not fix the double click issue described in this bug.

Let's block this bug on Bug 1266450 for now because we will have more control over this after it lands. We will probably have to implement the "parentonly" behavior for the HTMLTooltip. We will either handle this in Bug 1266450 or in another bug.

> I tried something else: open a tooltip and then click on *another* (ev)
> button. When I do this, the tooltip closes and the other tooltip opens, on
> both Windows and Mac, in the same way.

That's what is expected given the tooltip configuration.

Comment 7

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

This is fixed by bug 1315639