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

NEW
Unassigned

Status

()

defect
P4
normal
6 years ago
Last year

People

(Reporter: luke, Unassigned)

Tracking

(Blocks 2 bugs)

unspecified
x86_64
All
Points:
---
Dependency tree / graph
Bug Flags:
qe-verify +

Firefox Tracking Flags

(Not tracked)

Details

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

Attachments

(2 attachments, 1 obsolete attachment)

Reporter

Description

6 years ago
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.

Comment 1

6 years ago
P4 for now, but it'd be higher if this is reproducible on other platforms.
Whiteboard: [Australis:P4]
Reporter

Comment 2

6 years ago
This also reproduces for me on Mac (although it is not as noticeable since the scrollbar fades in/out and overlays).
Reporter

Updated

6 years ago
OS: Linux → Mac OS X

Updated

6 years ago
Duplicate of this bug: 962841

Updated

6 years ago
OS: Mac OS X → All
Still a problem? Seems smooth to me.
Flags: needinfo?(luke)

Comment 5

5 years ago
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
Reporter

Comment 6

5 years ago
I can also reproduce the problem on recent Linux and Mac Nightly build.  It's a brief flash, but quite noticeable.
Flags: needinfo?(luke)

Comment 7

5 years ago
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)
Reporter

Comment 9

5 years ago
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)

Comment 12

5 years ago
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.

Comment 13

5 years ago
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...
Reporter

Comment 14

5 years ago
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.

Updated

5 years ago
Duplicate of this bug: 986915

Updated

5 years ago
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

Comment 17

5 years ago
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.

Comment 18

5 years ago
Attachment #8406523 - Flags: review?(mdeboer)

Updated

5 years ago
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)

Comment 20

5 years ago
(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.

Comment 23

5 years ago
(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+

Comment 25

5 years ago
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)

Updated

5 years ago
Attachment #8406523 - Attachment is obsolete: true

Comment 26

5 years ago
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)

Updated

5 years ago
Duplicate of this bug: 994301

Updated

5 years ago
Blocks: 1009116

Comment 28

5 years ago
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.

Comment 29

5 years ago
(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.

Comment 30

5 years ago
(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. :-)

Comment 31

5 years ago
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.

Comment 32

5 years ago
Making this bug's status reflect reality...
Assignee: gijskruitbosch+bugs → nobody
Status: ASSIGNED → NEW
Flags: qe-verify+
Flags: firefox-backlog+

Updated

5 years ago
Duplicate of this bug: 1102451

Updated

3 years ago
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.

Comment 36

2 years ago
(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.

Updated

2 years ago
Duplicate of this bug: 1374511

Updated

2 years ago
Duplicate of this bug: 1378109
Priority: P3 → P4

Updated

2 years ago
Duplicate of this bug: 1403331

Updated

2 years ago
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]
You need to log in before you can comment on or make changes to this bug.