Closed Bug 1021377 Opened 6 years ago Closed 4 years ago

(vertical-homescreen) Scrollbar overlaps with RocketBar when scrolling near the top of homescreen

Categories

(Firefox OS Graveyard :: Gaia::Homescreen, defect)

x86
macOS
defect
Not set

Tracking

(feature-b2g:-)

RESOLVED WONTFIX
feature-b2g -

People

(Reporter: pla, Unassigned)

References

Details

(Whiteboard: ux-tracking, visual design, visual-tracking, [ft:systemsfe][systemsfe][2.0-FL-bug-bash] )

Attachments

(2 files)

The scrollbar on the homescreen currently overlaps with the searchbar (rocketbar).  Even though this 'makes sense' given how the component works in that the scrollable region includes the search bar, it just looks 'wrong'.

A solution would probably involve 'faking it' in some way so that the scroll bar only extends up to the bottom of the searchbar (in it's initial position).
Whiteboard: ux-tracking, visual design, visual-tracking, [ft:systemsfe][systemsfe] → ux-tracking, visual design, visual-tracking, [ft:systemsfe][systemsfe][2.0-FL-bug-bash]
I don't know how do it because search bar belongs to scrollable region and the scrollbar is controlled by Gecko. We could hide the scrollbar in other apps doing the width of the region calc(100 + .8rem) AFAIR, but, it won't work here because it will hide the scrollbar in the whole region. Maybe we could reduce the input some pixels in order not to overlap.
QA Whiteboard: [VH-FL-blocking-]
This is not really the way a scrollbar works at all. If this was an explicit spec and user story in early 2.0 we may be able to accomplish this, but I think it needs to wait.
Blocks: vertical-home-next
No longer blocks: vertical-homescreen
This should not block 2.0. I feel this can change later (sorry Peter). :(
QA Whiteboard: [VH-FL-blocking-] → [VH-FL-blocking-][VH-FC-blocking-]
Understood. :)

On the one hand it can be viewed as a minor detail, but it makes me cringe and I would not let something like this ship EVER (if it were up to me).  It looks unprofessional.

I'm just hoping we have time to get to this.  This was originally in the scrolling behaviour spec but not explicitly called out enough.  I'll ask Amy to spec this out.
Flags: needinfo?(amlee)
> On the one hand it can be viewed as a minor detail, but it makes me cringe
> and I would not let something like this ship EVER (if it were up to me).  It
> looks unprofessional.

I understand where you're coming from. Though it is possible that it would take another several months to ship if we don't have platform support for this today. Obviously we all want this to be as polished as possible, but given timelines we of course have to make compromises.

Kats, Vivien - Are you guys aware of any easy way to offset the scrollbar as in the attachment in this bug? It seems possible that we could do this with the coming CSS timeline animation thing, but perhaps there is something easy and I'm just overlooking it.
Flags: needinfo?(bugmail.mozilla)
Flags: needinfo?(21)
I can't think of any easy way to do this in the platform code. We'd have to add additional CSS properties or attributes or something for the gaia code to let platform know how tall the search bar is. It also can't think of any easy way to modify the HTML structure of the homescreen so that the search bar is outside the scrollable frame with the scrollbar but still scrolls properly.
Flags: needinfo?(bugmail.mozilla)
Hi, 

Here is the spec for the scroll bar on homescreen. I am aware that we don't have time to restyle the scroll bar so you can skip that portion in the spec. Let me know if you have any questions. Thanks!
Flags: needinfo?(amlee)
feature-b2g: --- → -
(In reply to Amy Lee [:amylee] from comment #7)
> Created attachment 8439259 [details]
> Homescreen_Scrollbar_Spec.png
> 
> Hi, 
> 
> Here is the spec for the scroll bar on homescreen. I am aware that we don't
> have time to restyle the scroll bar so you can skip that portion in the
> spec. Let me know if you have any questions. Thanks!

What you want for this part of the spec is a separate bug. This is bug 77790.
Flags: needinfo?(21)
(In reply to Kevin Grandon :kgrandon from comment #5)
> Kats, Vivien - Are you guys aware of any easy way to offset the scrollbar as
> in the attachment in this bug? It seems possible that we could do this with
> the coming CSS timeline animation thing, but perhaps there is something easy
> and I'm just overlooking it.


I tried to thing of how we can do that, but didn't found anything really smart.

Maybe something to explore would be to:

 - Have a container where its size is the height of the screen + the size of the rocketbar
 - Make its width 100% + the size of the scrollbars (to hide them).
 - Add the scrollgrab property on it.

 - Then have 2 parts inside the container.
 - One that contains the rocketbar
 - The other that contains the list of icons (scrollable with its own scrollbar).
 - The list of icons size would be 100% of the screen height.

My understanding of scrollgrab in this case is that:

When the user starts to scroll the list of icons, the element with scrollgrab will be scrolled first. And so the rocketbar will be the first thing to be hidden. Then the list of icons would be scrolled.

I didn't prototype this, so its not clear if it works or not, but it may be one way of doing it, while keeping APZC happy :)
(In reply to Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please) from comment #9)
> (In reply to Kevin Grandon :kgrandon from comment #5)
> > Kats, Vivien - Are you guys aware of any easy way to offset the scrollbar as
> > in the attachment in this bug? It seems possible that we could do this with
> > the coming CSS timeline animation thing, but perhaps there is something easy
> > and I'm just overlooking it.
> 
> 
> I tried to thing of how we can do that, but didn't found anything really
> smart.
> 
> Maybe something to explore would be to:
> 
>  - Have a container where its size is the height of the screen + the size of
> the rocketbar
>  - Make its width 100% + the size of the scrollbars (to hide them).
>  - Add the scrollgrab property on it.
> 
>  - Then have 2 parts inside the container.
>  - One that contains the rocketbar
>  - The other that contains the list of icons (scrollable with its own
> scrollbar).
>  - The list of icons size would be 100% of the screen height.
> 
> My understanding of scrollgrab in this case is that:
> 
> When the user starts to scroll the list of icons, the element with
> scrollgrab will be scrolled first. And so the rocketbar will be the first
> thing to be hidden. Then the list of icons would be scrolled.
> 
> I didn't prototype this, so its not clear if it works or not, but it may be
> one way of doing it, while keeping APZC happy :)

What would we do about the scrollbar of the container?
Blocks: 1069288
I think at this point the way to solve this is to have the rocketbar shrink into the app chrome on the home screen.
I'll look into this soon.
Flags: needinfo?(kgrandon)
I think we should solve this via bug 1053747.
Depends on: 1053747
Ok.  Is bug 1053747 something that is slated for the 2.2 timeframe?  What can I do to help get this moving?
(In reply to Peter La from comment #14)
> Ok.  Is bug 1053747 something that is slated for the 2.2 timeframe?  What
> can I do to help get this moving?

I think it's something we're going to try to have done, yes. I need to refresh myself on that though, and gauge the level of effort required.
Ok.  I'm going to chat with Francis about that bug and try to give a unified UX recommendation to help move it forward.  My initial thought is that if we can just hide RocketBar in Edit Mode, we'd be set.  I think having RocketBar in Edit Mode is unnecessary and might be confusing.
I'm currently working on bug 1053747. I think the most promising path forward is entering fullscreen during the home screen edit mode. I'm tracking this in bug 1100138.
Flags: needinfo?(kgrandon)
Mass update: Resolve wontfix all issues with legacy homescreens.

As of 2.6 we have a new homescreen and having these issues open is confusing. All issues will block bug 1231115 so we can use that to re-visit any of these if needed.
Blocks: 1231115
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.