Scrollbar resizing from 56488 is fragile; in some cases, gaps appear under the scrollbar




10 years ago
4 years ago


(Reporter: mstange, Unassigned)



Mac OS X
Bug Flags:
blocking1.9.2 -
wanted1.9.1 +

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [polish-hard] [polish-visual] [polish-p4])



10 years ago
My fix for bug 56488 doesn't seem to work too well...

This bug only shows on Mac OS X in resizable windows.

Steps to reproduce:
1. Open a Firefox window with only one tab.
2. Turn off the status bar.
3. Load a long page in the tab.
4. Open the preferences, go to the "Tabs" pane and toggle the "Always show
   the tab bar" pref several times.

Expected results:
The scrollbar should always have the right size - leaving just enough space for the resizer.

Actual results:
The scrollbar leaves either too much or not enough space.

There are other ways to trigger this bug, e.g. closing a notification bar.

I suspect this is what's going on when the tab bar is hidden:
1. The content scroll view is at its original position.
2. It realizes that it will soon be bigger and resizes itself to the new size
   without moving its upper edge upwards. Now the lower edge is further down
   than it will be when the layout is finished.
3. The scrollbar is resized to the size that would be right it stayed at
   that position.
4. The content scroll view is moved upwards to where it belongs.
Now the scrollbar is too short.

Can I do anything about this, roc?
Try doing your fixup in nsGfxScrollFrameInner::ReflowFinished?


10 years ago
Duplicate of this bug: 466910


10 years ago
Duplicate of this bug: 467924


10 years ago
Flags: wanted1.9.1?
Flags: wanted1.9.1? → wanted1.9.1+


10 years ago
Duplicate of this bug: 461865


10 years ago
Priority: -- → P2


10 years ago
Keywords: polish
Whiteboard: [polish-hard] [polish-visual] [polish-high-visibility]


9 years ago
Duplicate of this bug: 489891
This bug's priority relative to the set of other polish bugs is:
P4 - Polish issue that is rarely encountered, and is easily identifiable.

It sounds like once this happens it is pretty obvious there is a problem, but the steps to reproduce lead me to believe that it doesn't really happen that often.
Whiteboard: [polish-hard] [polish-visual] [polish-high-visibility] → [polish-hard] [polish-visual] [polish-p4]

Comment 8

9 years ago
Please remember that it also happens when you simply hide the toolbar. While not everybody uses that feature in OSX, it is by no means rare among people with small screens.
A blocker was resolved as a duplicate of this one -> blocking1.9.2
Flags: blocking1.9.2+

Comment 10

9 years ago
I talked this through with roc; it's pretty hard to fix without rewriting the scrollbar code (which is on my list, but there's no way it can make 1.9.2). The only easy way to fix this bug would be to back out bug 56488.

However, I think that bug 56488 is far worse than this bug. This bug means that scrollbars are too small in some edge cases, but you can still access them. Reintroducing bug 56488 means that you can't click the down scroll arrow in a very common case (hiding the status bar).

Also, the number of duplicates per year in bug 56488 is higher than in this bug.
Okay, putting this back in the queue then - bug 494301 was marked blocking, and subsequently dup'd to this one.

My opinion is that bug 494301 looks pretty bad, but I think it's roc's call as to whether the cure is more dangerous than the disease, here. Are there ways we can reduce or better understand the risk of fixing this (scoping down, better tests, beta exposure, some kind of protective rubber cushioning device)?
Flags: blocking1.9.2+ → blocking1.9.2?
We can do an easy quick and dirty fix for bug 494301. So let's un-dup that one, do the quick fix there, and leave this open for the general fix.
Flags: blocking1.9.2? → blocking1.9.2-
You need to log in before you can comment on or make changes to this bug.