1237995 - All customization UI infinitely twitches without user interaction if I hover mouse over a lightweight theme

Status: RESOLVED WORKSFORME

(Firefox :: Toolbars and Customization, defect)

Description

[arni2033]

Attachment: screencast 1 - All customization UI infinitely twitches without user interaction.webm

>>>   My Info:   Win7_64, Nightly 46, 32bit, ID 20160107030235
STR:
1. Swith window to normal (not maximized) mode
2. Open new tab
3. Open devtools in that tab, make sure toolbox is docked to the bottom side of the window
4. Hover mouse over devtools resizer, hold left mouse button, move mouse pointer to the top side
   of the screen, release left mouse button
5. Open new tab
6. Right-click Australis menu button (≡), click Customize
7. In customizing mode, click button "Themes", click theme "Developer Edition" to set it as default
8. Click button "Themes", hover mouse over any lightweight theme
8. Wait until that theme is applied, then slowly move mouse pointer to adjacent lightweight theme

Result:       
 All UI twitches. Read "Notes" to see that it happens in other cases (e.g. without Dev.Edition theme)
 I only provided such complex STR to make sure everybody is able to reproduce the issue.
 
Expectations: 
 UI should not twitch.

Notes:
 1) I can reproduce it using Default theme (not Dev.Edition), because bug 1111138 causes twitching.
    Once that bug is fixed, this will be observable only on Aurora and Nightly
    (and on release/beta with extension "dev.edition theme enabler" installed)
 2) It's not necessary to open devtools in other tab. This also happens if I resize window in normal
    mode so that the customization page overlapped the content borders when lwtheme is applied, and
    didn't overlap the content borders when Dev.Edition theme is applied. About 600px X 700px

 If anything in "Notes" is not clear - do request screenshots/screencasts/further explanations.

Comment 1

[:Gijs (out for now; he/him)]

Fixing bug 1111138 will fix the general lightweight-theme case.

I am curious, how would you propose fixing the other case? I believe it isn't possible using the current UI**, unless we make the toolbox height the same between the devedition and normal theme, which I don't think we want to do. Do you have a different/better idea?

** so one obvious option would be taking out the devedition theme from the UI - but we'll only get the same issue back if we ever give lwts more styling power than they currently have.

Comment 2

[arni2033]

Attachment: screenshot 1 (comment 2) - suggestion (A).png

So I suppose you reproduced this... I haven't thought about possible solutions yet, only reported it because I encounter this surprisingly often.
I agree that tooltip attached to any element in navigaion toolbar or below will trigger this bug

 I see some other possible options:
A) to attach tooltip to a fixed place within the tab (e.g. "position:fixed; bottom:0px; left:0px")
B) to replace that tooltip, because it's not good anyway - is sometimes clipped by top side of screen

 Changes related to automatic-theme-applying mechanism:
C) not to apply a theme when it's hovered & not to collapse tooltip when user clicks a theme
  (I'd like it a lot, as now I have to avoid hovering that popup when I simply need to set Dev theme)
D) to increase the time required for the hovered theme to be applied   (optional: to display a
    spinner/progressbar indicating how much time is left before the theme is applied)

Comment 3

[:Gijs (out for now; he/him)]

(In reply to arni2033 from comment #2)
> Created attachment 8705688 [details]
> screenshot 1 (comment 2) - suggestion (A).png
> 
> So I suppose you reproduced this...

I haven't, actually. I just trust you & your steps, and the issue makes sense to me. As in, I can understand why the behaviour you describe would happen given the current UI and behaviour of the code. :-)

> I haven't thought about possible
> solutions yet, only reported it because I encounter this surprisingly often.

Just to be clear, that's already great. But in this case I figured some ideas by people who use this regularly (which isn't me) wouldn't hurt.

>  I see some other possible options:
> A) to attach tooltip to a fixed place within the tab (e.g. "position:fixed;
> bottom:0px; left:0px")

Hmm, I think the popup code actually has a way of doing this so that the popup does not move with the anchor, if the anchor moves because of style changes. Of course, that also means that it won't move if you resize the window manually while it's open (though I think that should normally cause the panel to collapse, it's possible that you can avoid that in certain edgecases).

> B) to replace that tooltip, because it's not good anyway - is sometimes
> clipped by top side of screen
> 
>  Changes related to automatic-theme-applying mechanism:
> C) not to apply a theme when it's hovered & not to collapse tooltip when
> user clicks a theme
>   (I'd like it a lot, as now I have to avoid hovering that popup when I
> simply need to set Dev theme)
> D) to increase the time required for the hovered theme to be applied  
> (optional: to display a
>     spinner/progressbar indicating how much time is left before the theme is
> applied)

Thanks for these. I like A, C or D better than the others (maybe because I'm not sure what B would look like), but let's see what UX thinks. Philipp, what do you reckon?

Comment 4

[arni2033]

> I encounter this surprisingly often.
Well, "normal" users may encounter this very rarely, e.g. never.
> resizing the window manually should normally cause the panel to collapse
I confirm that I can avoid that by pressing Win+Left/Right/Up/Down on Windows 7.
Also, "screenshot 1" is a bit inaccurate: I meant fixed indent between the tooltip and the bottom side of #main-window, not between the tooltip and some unrelated border. That's all I wanted to add.

Comment 5

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

Hm, I can't reproduce the issue exactly (on Windows 10). When using the dev edition theme and hovering over items, the UI jumps (which isn't great), but at least the menu stays in place, so it doesn't jump back and forth like in your video.

I'd say that if we can keep the menu from jumping, that would be acceptable for now. If LWTs get more powers, we might need to reconsider the switching UI, since switch-on-hover would become increasingly problematic.

Comment 6

[:Gijs (out for now; he/him)]

Closing as WFM for 57 now that lightweight themes and the dark/light builtin themes are independent from the UI density settings.