Closed
Bug 958582
Opened 10 years ago
Closed 10 years ago
Long titles in the Rocketbar should not displace all status icons
Categories
(Firefox OS Graveyard :: Gaia::System::Browser Chrome, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
1.3 C2/1.4 S2(17jan)
People
(Reporter: benfrancis, Assigned: benfrancis)
References
Details
(Whiteboard: [systemsfe])
Attachments
(2 files)
Currently if a long title is displayed in the collapsed state of the Rocketbar it will displace all the icons in the status bar so you can't see them. The UX spec asks for the following... "The title area should use all available space that is not being used by the Status icons. Furthermore, a fixed minimum amount of space (tbd) should be reserved on the Rocket bar to display the title. If the title does not fit within the available space, the text should be truncate" "The status icon area should expand to show all active status icon, up to the maximum allowed size. If there is not enough space to display all the icons, they should be shown in priority order and the status icons should be truncated (priority to be determined)." Let's see how close we can get to that.
Assignee | ||
Comment 1•10 years ago
|
||
I'm not sure if we can do what's ask for in the spec 100% using CSS, but I have a prototype which uses CSS flexible boxes to do something very similar. The title bar and row of icons are each use flex auto to size themselves to use the available space, proportional to the size of their content but each of the two boxes has a minimum size of 33%. (In reply to Ben Francis [:benfrancis] from comment #0) > "The title area should use all available space that is not being used by the > Status icons. The title will be able to use up to 67% of the status bar, but will not use *all* of the available space if it's not proportionally much bigger than the list of icons. > Furthermore, a fixed minimum amount of space (tbd) should be > reserved on the Rocket bar to display the title. Yes, 33% is reserved. > If the title does not fit > within the available space, the > text should be truncate" Yes, currently using an ellipsis. We can try a fade instead once the visual design is finalised. > "The status icon area should expand to show all active status icon, up to > the maximum allowed size. The maximum allowed size is 67%, but some icons may be clipped if the list of icons is not proportionally much larger than the title. > If there is not enough space to display all the > icons, they should be shown in priority order The priority order is defined by the order of the HTML elements in the source code. > and the status icons should be > truncated (priority to be > determined)." Currently these will be clipped. We can try a fade once the visual design is finalised. Now I'm going to *try* and apply this prototype to the actual status bar in a way that's backwards compatible with a no Rocketbar state...
Assignee | ||
Comment 2•10 years ago
|
||
CSS flexible boxes are pretty cool :) (In reply to Ben Francis [:benfrancis] from comment #0) > "The title area should use all available space that is not being used by the > Status icons. Check. > Furthermore, a fixed minimum amount of space (tbd) should be > reserved on the Rocket bar to display the title. Check, 33% is reserved. > If the title does not fit > within the available space, the > text should be truncate" Check, ellipsis. > "The status icon area should expand to show all active status icon, up to > the maximum allowed size. Check, maximum allowed size of 67%. > If there is not enough space to display all the > icons, they should be shown in priority order Check, the priority order is defined by the order of the HTML elements in the source code. I have also moved the notifications icon and emergency notifications icon to the left of the other icons instead of the right of the clock. > and the status icons should be > truncated (priority to be > determined)." Check. The only thing missing are the fades when things get truncated, but we should probably hold off until we get the visual design spec for that. The status bar in general could probably do with some visual polish, things aren't aligned brilliantly. I've tried my best to check for regressions in both the rocketbar enabled and rocketbar disabled case.
Attachment #8358611 -
Flags: review?(dale)
Comment 3•10 years ago
|
||
Comment on attachment 8358611 [details] [review] https://github.com/mozilla-b2g/gaia/pull/15213 All looks good, am going to file a follow up for UX to decide what is happening to the notifications as they are out of place in both version of rocketbar being enabled, but not a part of this patch
Attachment #8358611 -
Flags: review?(dale) → review+
Comment 4•10 years ago
|
||
merged: https://github.com/mozilla-b2g/gaia/commit/de0ee514be32af0677379b29013e55efb86ec49b
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Comment 5•10 years ago
|
||
Sorry about that, had to revert as failing tests https://travis-ci.org/mozilla-b2g/gaia/jobs/16865736 https://github.com/mozilla-b2g/gaia/commit/0fd63c0d0f0856da666d44f15d563bdb0f036257
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 6•10 years ago
|
||
Going to needsinfo? myself on this today. The test could probably be a little less flaky, as the line it's failing on will likely be updated in the future. (Currently it's just waiting for the search input to finish transitioning by checking the location of the search box)
Flags: needinfo?(kgrandon)
Comment 7•10 years ago
|
||
Yeah, this is actually breaking some rocketbar use cases for me, good thing we had those few marionette tests. My assumption is that the statusbar-icons element is now capturing the pointer events. I think we just need some CSS tweaks to change the pointer-events behavior.
Flags: needinfo?(kgrandon)
Assignee | ||
Comment 8•10 years ago
|
||
What use cases get broken? I'm trying to debug the failing search app tests but I get completely different results locally than on Travis. Locally all the tests fail for that app.
Flags: needinfo?(kgrandon)
Comment 9•10 years ago
|
||
I am fairly sure that this line is causing the problem I was seeing: https://github.com/mozilla-b2g/gaia/pull/15213/files#diff-19076406e0c835797eb201e0143532c7R37 I think if you add pointer-events: none to the statusbar-icons things should be better.
Flags: needinfo?(kgrandon)
Assignee | ||
Comment 10•10 years ago
|
||
Travis was green so I've merged. I set pointer-events: none on #statusbar-title as suggested in IRC, but not #statusbar-icons as mentioned here. https://github.com/mozilla-b2g/gaia/commit/7dc21dfa30a7b1ad69c5fdec7fdde17a6ed15bef I'm not able to reproduce any problems on a Hamachi, but Kevin if you can still reproduce then please file a follow-up.
Status: REOPENED → RESOLVED
Closed: 10 years ago → 10 years ago
Resolution: --- → FIXED
Comment 11•10 years ago
|
||
Turns out we need a follow-up here after all. Statusbar-icons needs pointer-events: none, otherwise the event is not dispatched properly. R=me.
Attachment #8362124 -
Flags: review+
Comment 12•10 years ago
|
||
Follow-up landed in master: https://github.com/mozilla-b2g/gaia/commit/c42a688c370053040b60f287b7e96f6a52792bf6
Assignee | ||
Updated•10 years ago
|
Whiteboard: [systemsfe]
Target Milestone: --- → 1.3 C2/1.4 S2(17jan)
You need to log in
before you can comment on or make changes to this bug.
Description
•