Open Bug 940733 Opened 7 years ago Updated 1 year ago

When opening subviews in the panel menu, scroll bar flickers (appears, then disappears) during animation

Categories

(Firefox :: Menus, defect, P4)

x86_64
All
defect

Tracking

()

People

(Reporter: luke, Unassigned)

References

(Blocks 2 open bugs)

Details

(Whiteboard: [fxperf:p3][Australis:P4])

Attachments

(2 files, 1 obsolete file)

This isn't a functional problem, but when I click the "history" button in the new Australis menu, during the animation where the history slides open, a scrollbar flickers visible then invisible.  This is a little visibly jarring and could potentially contribute to missed animation frames.

For reference, I'm using FF Nightly on Ubuntu.
P4 for now, but it'd be higher if this is reproducible on other platforms.
Whiteboard: [Australis:P4]
This also reproduces for me on Mac (although it is not as noticeable since the scrollbar fades in/out and overlays).
OS: Linux → Mac OS X
Duplicate of this bug: 962841
OS: Mac OS X → All
Still a problem? Seems smooth to me.
Flags: needinfo?(luke)
I can still reproduce the problem
https://hg.mozilla.org/mozilla-central/rev/8122ffa9e1aa
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0 ID:20140306030201
I can also reproduce the problem on recent Linux and Mac Nightly build.  It's a brief flash, but quite noticeable.
Flags: needinfo?(luke)
Should this be higher prio if people can reproduce it? I haven't tried, also not sure how hard it is to reproduce and/or fix.
Flags: needinfo?(dolske)
Is it possible this is just the animation starting before Places has given us history results? It's one of those things where you're damned either way -- if you wait for results before starting the UI will feel sluggish/unresponsive, if you start before there are results you can get visual glitches like this.

How does the old history menu in the menubar feel for people who can reproduce this?

Oh, I do see the scrollbar show and then fadeout on OS X. But at comment 2 notes it's not very jarring due to the fadeout.

Alas I don't see the flicker either on Ubuntu (MattN's debug build in a VM).

I think P4 is about right for now, but would reconsider if it really looks worse than it sounds.
Flags: needinfo?(dolske) → needinfo?(mak77)
I know approximately nothing about frontend development, but the problem seemed to be to be the following sequence:
 1. click History, the History pane starts sliding in from the right and the whole menu starts getting vertically taller
 2. the History pane is populated with the number entries that is expected to fit without scrolling once the pane is at its final vertical height
 3. since the animation in #1 isn't finished yet, the number of entries is bigger than the visible size and so we get a vertical scrollbar
 4. the animation finishes, the number of entries fits w/o any need for the scrollbar, so it goes away
Maybe same issue as bug 977845?
(In reply to Justin Dolske [:Dolske] from comment #8)
> Is it possible this is just the animation starting before Places has given
> us history results?

The history widget doesn't use Places API, it does a direct async query.

> How does the old history menu in the menubar feel for people who can
> reproduce this?

The old menubar uses the synchronous API (exactly it uses a nsNavHistoryResult). That API is sometimes moving to async btw.

> Oh, I do see the scrollbar show and then fadeout on OS X. But at comment 2
> notes it's not very jarring due to the fadeout.

I see the same on Win8.1

Btw, I think it's more a frontend bug than a bug with results coming late, it should cope with asynchronous content since we are moving more and more stuff to async.
Flags: needinfo?(mak77)
This is also the case with the developer subview for example and with the fact that the shortcuts are now shown in the menu it's quite more visible than before, because the shortcuts are briefly moved from the left to the right during the subview opening.
As far as I know this is just because of the fact that we transition the size changes of the panel, and so for some time the panel view isn't high enough to accommodate all the items, so a scrollbar is shown.

I'm not really sure what could be done about this. We could set overflow: hidden, but that's likely to look just as bad...
Using overflow: hidden sounds good; what would look wrong?  It seems like, for the very short time during the animation, some items would be clipped which is what I would expect to happen.  The only jarring thing is the scrollbar appearing and disappearing.
I'd vote for overflow:hidden during the transition as well.
Duplicate of this bug: 986915
Summary: when clicking 'History' button in australis menu, scroll bar flickers on and off during animation → When opening subviews in the panel menu, scroll bar flickers (appears, then disappears) during animation
I don't want to be annoying or something but is there any update on this issue? It's been like 5 months since this bug was reported.

It looks quite cheap in Australis menu and is as far as I know last graphical glitch I'm aware of.
Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED
Comment on attachment 8406523 [details] [diff] [review]
set overflow:hidden during the transition,

Gijs, it might be me, but I don't see a difference when I open the Character Encoding subview on OSX with this patch applied... did you test it there, or only on Linux?
Attachment #8406523 - Flags: review?(mdeboer)
Flags: needinfo?(gijskruitbosch+bugs)
(In reply to Mike de Boer [:mikedeboer] from comment #19)
> Comment on attachment 8406523 [details] [diff] [review]
> set overflow:hidden during the transition,
> 
> Gijs, it might be me, but I don't see a difference when I open the Character
> Encoding subview on OSX with this patch applied... did you test it there, or
> only on Linux?

I tested on OS X. No difference as in, there's still a scrollbar showing temporarily?
Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(mdeboer)
(In reply to :Gijs Kruitbosch from comment #20)
> I tested on OS X. No difference as in, there's still a scrollbar showing
> temporarily?

Yes, but now I see that the scrollbars might only be visible _after_ the transition, it's so fast :)
When I slow down the transition it actually looks like the patch works as advertised.
Flags: needinfo?(mdeboer)
But then again, when I slow down the transition and run it without the patch applied, I also don't see any scrollbars.
(In reply to Mike de Boer [:mikedeboer] from comment #21)
> (In reply to :Gijs Kruitbosch from comment #20)
> > I tested on OS X. No difference as in, there's still a scrollbar showing
> > temporarily?
> 
> Yes, but now I see that the scrollbars might only be visible _after_ the
> transition, it's so fast :)
> When I slow down the transition it actually looks like the patch works as
> advertised.

I see. I tested by emptying out most of the panel and then opening the developer tools. There the scrollbar flash was sometimes visible, and now isn't anymore.
Comment on attachment 8406523 [details] [diff] [review]
set overflow:hidden during the transition,

True. And I see a nice improvement on Linux and Win.

Thanks!
Attachment #8406523 - Flags: review+
This seems to be enough to get rid of the last flash of scrollbar I was seeing on the history view on Linux.
Attachment #8406783 - Flags: review?(mdeboer)
Attachment #8406523 - Attachment is obsolete: true
Comment on attachment 8406783 [details] [diff] [review]
set overflow:hidden during the transition,

These handlers are broken in some way. I don't really know why. But I'm going to figure it out and get a better patch, because while we keep the underlying brokenness we can't really fix this bug very well.
Attachment #8406783 - Flags: review?(mdeboer)
Duplicate of this bug: 994301
So bug 994194 seems to have fixed the history subview issue (side note the animation is now laggy but I'm not sure it's related), the issue is however still visible at least in the developer subview.
(In reply to Guillaume C. [:ge3k0s] from comment #28)
> So bug 994194 seems to have fixed the history subview issue (side note the
> animation is now laggy but I'm not sure it's related), the issue is however
> still visible at least in the developer subview.

That patch only affected subviews opened as panels on their own from toolbars; It shouldn't have affected these cases at all. I think the history case is just intermittent and/or depends on how big the menu is, what OS you have, how many history items you have, and the phase of the moon.

:-(

I hope to get back to this bug this week, but I've been distracted by some other high-prio issues over the last few weeks.
(In reply to :Gijs Kruitbosch from comment #29)
> (In reply to Guillaume C. [:ge3k0s] from comment #28)
> > So bug 994194 seems to have fixed the history subview issue (side note the
> > animation is now laggy but I'm not sure it's related), the issue is however
> > still visible at least in the developer subview.
> 
> That patch only affected subviews opened as panels on their own from
> toolbars; It shouldn't have affected these cases at all. I think the history
> case is just intermittent and/or depends on how big the menu is, what OS you
> have, how many history items you have, and the phase of the moon.

Yeah that seems to be the case. It's strange that the scrollbar appears to flash only after the subview is extended. Although it's a minor issue I hope it'll get fixed. :-)
I can confirm this issue still persists when opening subviews like History, Developer etc from appmenu. Scrollbar appears  for a brief moment during the animation.
Making this bug's status reflect reality...
Assignee: gijskruitbosch+bugs → nobody
Status: ASSIGNED → NEW
Flags: qe-verify+
Flags: firefox-backlog+
Duplicate of this bug: 1102451
Duplicate of this bug: 1212307
Whiteboard: [Australis:P4] → [photon] [Australis:P4]
Flags: firefox-backlog+
Priority: -- → P2
QA Contact: adrian.florinescu
Whiteboard: [photon] [Australis:P4] → [photon-performance] [Australis:P4]
Priority: P2 → P3
Whiteboard: [photon-performance] [Australis:P4] → [reserve-photon-performance] [Australis:P4]
This still happens on currently nightlies, despite the rest of the animation now being smoother than ever.
(In reply to Florian Quèze [:florian] [:flo] from comment #35)
> Created attachment 8879097 [details]
> Screenshot of the flickering scrollbar on Mac
> 
> This still happens on currently nightlies, despite the rest of the animation
> now being smoother than ever.

I think this is simply a consequence of the fact that, mid-animation, the panel is too small to contain some of the items, and so we have to display a scrollbar, even if the final state of the panel subview will be tall enough to accommodate all the items.

I think to avoid this we'd have to set overflow: hidden in both directions on the scrollable vbox that contains items in the panel. The issue is that this messes with measuring height/width, as well as not causing (too many) sync reflows, as well as with eventually having a scrollbar if/when we do need one in the end.
Duplicate of this bug: 1374511
Duplicate of this bug: 1378109
Priority: P3 → P4
Duplicate of this bug: 1403331
Duplicate of this bug: 1404900
Whiteboard: [reserve-photon-performance] [Australis:P4] → [fxperf][Australis:P4]
We should probably figure out whether a scroll bar is present when preparing the subview off-screen, make the scrollbar always visible or always hidden during the animation, and then restore the visibility to be automatic.
Whiteboard: [fxperf][Australis:P4] → [fxperf:p3][Australis:P4]
Duplicate of this bug: 1588063
You need to log in before you can comment on or make changes to this bug.