Closed
Bug 1021377
Opened 10 years ago
Closed 8 years ago
(vertical-homescreen) Scrollbar overlaps with RocketBar when scrolling near the top of homescreen
Categories
(Firefox OS Graveyard :: Gaia::Homescreen, defect)
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).
Updated•10 years ago
|
Whiteboard: ux-tracking, visual design, visual-tracking, [ft:systemsfe][systemsfe] → ux-tracking, visual design, visual-tracking, [ft:systemsfe][systemsfe][2.0-FL-bug-bash]
Comment 1•10 years ago
|
||
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.
Updated•10 years ago
|
QA Whiteboard: [VH-FL-blocking-]
Comment 2•10 years ago
|
||
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.
Comment 3•10 years ago
|
||
This should not block 2.0. I feel this can change later (sorry Peter). :(
Updated•10 years ago
|
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)
Comment 5•10 years ago
|
||
> 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)
Comment 6•10 years ago
|
||
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)
Comment 7•10 years ago
|
||
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)
Updated•10 years ago
|
feature-b2g: --- → -
Comment 8•10 years ago
|
||
(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)
Comment 9•10 years ago
|
||
(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 :)
Comment 10•10 years ago
|
||
(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?
Comment 11•10 years ago
|
||
I think at this point the way to solve this is to have the rocketbar shrink into the app chrome on the home screen.
Reporter | ||
Comment 14•10 years ago
|
||
Ok. Is bug 1053747 something that is slated for the 2.2 timeframe? What can I do to help get this moving?
Comment 15•10 years ago
|
||
(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.
Reporter | ||
Comment 16•10 years ago
|
||
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.
Comment 17•10 years ago
|
||
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)
Comment 18•8 years ago
|
||
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.
You need to log in
before you can comment on or make changes to this bug.
Description
•