arni2033 Reporter
	Description • 8 years ago

>>>   My Info:   Win7_64, Nightly 52, 32bit, ID 20161028030204 (2016-10-28)
STR_1:
1. Open url   data:text/html,<style>body{transition: all 1s linear;color:white;filter:none;
2. Open devtools -> inspector -> ruleview
3. Click on circle in any rule to edit timing-function/color/filter
4. Wait 3 seconds, then click on the same circle again

AR:  Panel briefly disappears, but then appears again
ER:  Either X or Y.  X is better, because that's how it worked before bug 1310957.
 X) Panel should disappear
 Y) Panel should stay opened and don't blink

This is regression from bug 1310957. Regression range:
> https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=b50520db14601df2cc29d23f211000a309b62026&tochange=9ee4fd380512cd8e307f20626c03996dadf714f5@ Julian Descottes [:jdescottes]:
It seems that this is a regresion caused by your change. Please have a look.

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)
	Comment 1 • 8 years ago

Hmm, Julian, how should we handle this one?  Should we address it before it reaches beta, or move it to the backlog?

	Julian Descottes [:jdescottes] Assignee
	Comment 2 • 8 years ago

Will take a look, would be nice to get it fixed before beta.

	Julian Descottes [:jdescottes] Assignee
	Comment 3 • 8 years ago

Bug 1310957 makes the HTMLTooltip use the XUL panel "popuphidden" event to hide itself. This occurs at "mousedown" when triggered by a mouse event, while we usually listen to "click" for tooltips that don't rely on a XUL panel wrapper.

So after opening the tooltip once, when clicking on the swatch: 
- mousedown first hides the tooltip
- click opens the tooltip again

It is actually a bit more complicated in this case, as text-property-editor implements a mechanism to re-trigger click events missed when recreating the markup, but the root cause is the same.

The main reason we want to use the XUL panel "popuphidden" event is for situations where our usual event handlers won't hide the tooltip programmatically (such as alt-tabbing the window). In case of a click, we already have a event handler able to catch this.

I can't find a clean way to differentiate between a popuphidden event triggered by a click and one coming from another reason. As a workaround, we could delay hiding the tooltip when receiving the popuphidden event. If it should be closed by a click, our regular event listener will hide it when receiving the "click" event. Otherwise (alt-tabbing), a small delay should not be noticeable.

	Julian Descottes [:jdescottes] Assignee
	Comment 7 • 8 years ago

I should mention that I could not add a test for this. Simulating clicks/mousedown/mouseup does not trigger the hiding of the XUL panel, so I'm unable to reproduce the "race" between the popuphidden event and the click event.

	Patrick Brosset <:pbro>
	Comment 8 • 8 years ago
mozreview-review

Comment on attachment 8824551 [details]
Bug 1327979 - add delay before hiding HTMLTooltip after receiving popuphidden;

https://reviewboard.mozilla.org/r/103008/#review105124

Thanks Julian for this patch.
I would normally want to discuss other solutions more, because this one uses a timeout (not always a great idea), and because if you mousedown long enougn on the circle, the tooltip disappears and then re-appears. But: it's specifically only for XUL wrappers, which are eventually going away, and reading the comments on this bug, it doesn't look like we have much choice anyway.
So R+.

	Julian Descottes [:jdescottes] Assignee
	Comment 9 • 8 years ago

Thanks for the review! 

After discussing with both Sole and Patrick, it's not clear that this behavior is perceived as a bug by end users. 
It is a regression compared to what we used to do, but there are plenty of other ways to close the tooltip, and some users actually find the current behavior more logical.

Given that the fix for this is quite dirty and could potentially introduce other issues (timeouts are never nice), I will WONTFIX this bug for now. Let's wait and see if we get similar complaints.