Closed Bug 943341 Opened 11 years ago Closed 8 years ago

Investigate making the variables view inspection popup more transient

Categories

(DevTools :: Debugger, defect, P3)

Product:
DevTools
Component:
Debugger
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: vporof, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [lang=js])

Attachments

(1 file)

wip 1
4.27 KB, patch
Details | Diff | Splinter Review
Depends on: 725235
So, I've been thinking to this overnight.

How about:
* when hovering more than XXX ms, the popup is displayed in "transient mode"
  + in that case, it's moved as soon as the user hovers another variable or out of the current variable (with a delay), my mind is not made on this yet
  + if the user clicks on the popup, the popup goes in "permanent mode" (see next point)
* when clicking on the var, the popup is displayed asap The click event should not be "preventDefaulted" to allow selection. It's in "permanent mode":
  + the popup is not dismissed automatically
  + it's dismissed if the user clicks elsewhere
  + I don't know yet if it should show another popup on the other var, probably not
(In reply to Julien Wajsberg [:julienw] from comment #1)
> * when clicking on the var, the popup is displayed asap The click event
> should not be "preventDefaulted" to allow selection. It's in "permanent
> mode":
>   + the popup is not dismissed automatically
>   + it's dismissed if the user clicks elsewhere
>   + I don't know yet if it should show another popup on the other var,
> probably not

At some point in the not too distant future the debugger will stop being read-only, in which case such behavior would interfere with regular editing.
(In reply to Panos Astithas [:past] from comment #2)
> (In reply to Julien Wajsberg [:julienw] from comment #1)
> > * when clicking on the var, the popup is displayed asap The click event
> > should not be "preventDefaulted" to allow selection. It's in "permanent
> > mode":
> >   + the popup is not dismissed automatically
> >   + it's dismissed if the user clicks elsewhere
> >   + I don't know yet if it should show another popup on the other var,
> > probably not
> 
> At some point in the not too distant future the debugger will stop being
> read-only, in which case such behavior would interfere with regular editing.

Wouldn't we want to use dblclick for this?
Use dblclick for what, to start editing a file? No, I don't think so. No other editor does it.
I was thinking it would be like the inspector: dbl click to trigger editing. But now I understand what you're talking about: the whole file is in edit mode already.
Huge +1. I often accidentally trigger the pop up and intuitively try to just move the mouse away to make the pop up go away. You have to move it away and click, which is annoying.
(In reply to Nick Fitzgerald [:fitzgen] from comment #6)
> Huge +1. I often accidentally trigger the pop up and intuitively try to just
> move the mouse away to make the pop up go away. You have to move it away and
> click, which is annoying.

In that case maybe we should just increase the hover timeout.
(In reply to Victor Porof [:vp] from comment #7)
> (In reply to Nick Fitzgerald [:fitzgen] from comment #6)
> > Huge +1. I often accidentally trigger the pop up and intuitively try to just
> > move the mouse away to make the pop up go away. You have to move it away and
> > click, which is annoying.
> 
> In that case maybe we should just increase the hover timeout.

I think that will just solve partial problem. Most of the time, I just tend to leave my mouse untouched while I try to do something else. I assume many users will be doing this.

I am also hugely inclined towards making the popup transient.
Not to mention that every other debugger that I have worked with goes with a transient approach:
 - Eclipse
 - Chrome
 - IntelliJ
 - Firebug
 - Safari
 - IE
 - Visual Studio
(In reply to Victor Porof [:vp] from comment #7)
> (In reply to Nick Fitzgerald [:fitzgen] from comment #6)
> > Huge +1. I often accidentally trigger the pop up and intuitively try to just
> > move the mouse away to make the pop up go away. You have to move it away and
> > click, which is annoying.
> 
> In that case maybe we should just increase the hover timeout.

Sure, but having to click is an annoyance; we should be able to just move the mouse away. Hover in, hover out.
Attached patch wip 1 — — Splinter Review 
No tests yet, but this behavior feels a lot more natural to me.
Assignee: nobody → nfitzgerald
Status: NEW → ASSIGNED
(In reply to Nick Fitzgerald [:fitzgen] from comment #11)
> Created attachment 8345394 [details] [diff] [review]
> wip 1
> 

You can't interact with the panel's content now.
(In reply to Victor Porof [:vp] from comment #12)
> (In reply to Nick Fitzgerald [:fitzgen] from comment #11)
> > Created attachment 8345394 [details] [diff] [review]
> > wip 1
> > 
> 
> You can't interact with the panel's content now.

Ah good catch, need to clear the timeout when you enter the popup, and call hideContents when you mouse out of the popup.
I don't have time for this at the moment. Maybe someone else can clean this up and land it.
Assignee: nfitzgerald → nobody
Status: ASSIGNED → NEW
Priority: -- → P3
Whiteboard: [mentor=nfitzgerald@mozilla.com][lang=js]
Whiteboard: [mentor=nfitzgerald@mozilla.com][lang=js] → [good first bug][mentor=nfitzgerald@mozilla.com][lang=js]
Thinking about it some more, I assume you probably meant to mark this as just a mentored bug.
Whiteboard: [good first bug][mentor=nfitzgerald@mozilla.com][lang=js] → [mentor=nfitzgerald@mozilla.com][lang=js]
(In reply to Panos Astithas [:past] from comment #15)
> Thinking about it some more, I assume you probably meant to mark this as
> just a mentored bug.

Yup :)
See Also: → 967853
Mentor: nfitzgerald
Whiteboard: [mentor=nfitzgerald@mozilla.com][lang=js] → [lang=js]
Panos pointed out this bug to me, I didn't know it existed and made a comment in the original bug: https://bugzilla.mozilla.org/show_bug.cgi?id=725235#c94 which I'm repeating here:

"
I know this is an old discussion, but after a long time using the debugger and the variables popup, I still find this annoying most of the times, so I thought I would report it here and maybe we can get a discussion started to eventually end up on a bug being filed.
I think:
- it takes too long for the popup to appear
- it should go away when you move your mouse out of the expression but:
  - it should do so only after a delay that allows the user to quickly move back the mouse to the expression if needed
  - it shouldn't occur if the mouse goes over the bubble itself.
I think this is pretty much what Chrome does. Also, beside my point of view, I've also had several reports of our implementation being a little annoying.
I'd like to hear what other people think about this.
"
In comment 1, I also outlined something about the "permanent mode"; for example, if you click inside the bubble to open a tree, it would be a PITA if the bubble is undisplayed. So my proposal was that as soon as we click inside the bubble, it becomes non-transient.

But yeah, it should be transient until something triggers "permanent mode".
(In reply to Julien Wajsberg [:julienw] from comment #18)
> In comment 1, I also outlined something about the "permanent mode"; for
> example, if you click inside the bubble to open a tree, it would be a PITA
> if the bubble is undisplayed. So my proposal was that as soon as we click
> inside the bubble, it becomes non-transient.
> 
> But yeah, it should be transient until something triggers "permanent mode".
Yeah, that sounds like a good idea.
I think the people that have told me the didn't like having to click outside of the popup just wanted it to work like on chrome.
I do agree that it's a pity though that you loose the context of what has been expanded when the popup is hidden.
I don't think it's something that occurs all that often though. When you're expanding properties in the popup, you're focused on reading the children properties and scrolling through, so it's quite rare that you'd move your mouse out of the popup at that stage. Having said that, if we could restore the expanded state if you move your mouse back to the same variable, that would solve this issue too, right? (and it could be easy if we just remember the last variable that was inspected and left the content in the panel).
If you hover on another variable by mistake, then you'll still lose it :)

I think we just need to try it for real to know how this feels.
I'm going to try and look into this in Q1.
Assignee: nobody → ejpbruel
I ranted about this a while ago - while some of the following has changed due to debugger evolution, most of it applies here (IMO)

https://bugzilla.mozilla.org/show_bug.cgi?id=967096#c14

And if you can fix the referenced bug while you're in this code, great - I'll be more than pleased - it's a 24/7 problem here.
(In reply to Russ from comment #22)
> I ranted about this a while ago - while some of the following has changed
> due to debugger evolution, most of it applies here (IMO)
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=967096#c14
> 
> And if you can fix the referenced bug while you're in this code, great -
> I'll be more than pleased - it's a 24/7 problem here.

Hi Russ. I'm sorry to hear you had a bad experience :-( I've read your rant and agree with most of the points in it. This really is something that needs to be fixed. My queue is pretty full at the moment, but I still intend to get to this in Q1 if at all possible.

If you can't wait that long, and if you really wanted to, you could probably fix this problem yourself. It shouldn't be that hard to fix if you know where to look. If you are interested, I could find a mentor to help you out, which would save you a lot of time.

Of course, I realise your time is probably just as precious as mine, so I understand if you don't want to do that. In which case all I can do is to ask you to be patient for a bit longer :-)
Hi Eddy

Thanks.  No, I'm not a moz dev - just a 24/7 dev user. The on ramp for me would be huge plus, I'm exclusively contracted to my employer :/
(In reply to Russ from comment #24)
> Hi Eddy
> 
> Thanks.  No, I'm not a moz dev - just a 24/7 dev user. The on ramp for me
> would be huge plus, I'm exclusively contracted to my employer :/

Fair enough Russ. I'll try to get to this bug as soon as I can.
(The fix I'm trying to get in through bug 967853 is nearby and related but I don't think it will conflict after looking briefly at the attached wip1 patch)
My apologies to the people who have been waiting for this, but this bug kind of slipped of my radar, and I am not actively working on it at the moment
Assignee: ejpbruel → nobody
Mentor: nfitzgerald
I'm a js developer and this really makes me crazy: Waiting, no debugger popup, clicking somewhere, delay, then finally there it is.... It is still present and very annoying :( I was just about screencasting how Chrome does the debugger popup, until I found this bug here. The way the Chrome devtools opens and closes the popup feels very natural, like already pointed out in Comment 17 by pbro (almost 2 years ago).
Also, the image popup in the network and inspector panel (transient) do just feel right to me - and are fast. That the debugger popup behaves different makes the devtool's UI inconsistent.
Now that there's a very nice transient(!) Popup for the “Cause” column of the Network Monitor (see Bug 1134073 and its dependent Bug 1270111), I wonder if the debuggers driving-me-crazy-click-hover-click-somewhere-else-hover-again ;) popup could be approached.
Closing.

This work will now be tracked in this issue: https://github.com/devtools-html/debugger.html/issues/626
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → INVALID
Product: Firefox → DevTools
Blocks: 1565711
Blocks: 1565713
No longer blocks: 1565711
No longer blocks: 1565713
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: