1127571 - Rocketbar width fixes when minimized

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::System::Browser Chrome, defect)

Description

[Kevin Grandon :kgrandon]

This is a dupe of something, but I'm not sure what. Would like to finally get this fixed though.

Comment 1

[GitHub Autolander Bot]

Attachment: [PullReq] KevinGrandon:bug_1127571_rocketbar_width_fixes to mozilla-b2g:master

Comment 2

[Kevin Grandon :kgrandon]

Comment on attachment 8556743 [details] [review]
[PullReq] KevinGrandon:bug_1127571_rocketbar_width_fixes to mozilla-b2g:master

I would imagine that we take a slight performance hit for this, but I think the bigger URLbar is worth it - right now it's just way too small if you have control buttons enabled. Could one of you guys take a look here? Thanks!

Comment 3

[Chris Lord [:cwiiis]]

Comment on attachment 8556743 [details] [review]
[PullReq] KevinGrandon:bug_1127571_rocketbar_width_fixes to mozilla-b2g:master

I don't notice the jank in a quick test, but I'd be worried it'd contribute when the phone is bogged down, especially as the animation can be triggered too easily right now (another polish bug I've been meaning to file/fix...)

The disappearance of the controls is noticeable and jarring though, I'd really prefer to get a decent transition here rather than doing this.

However, this r- is mainly because it breaks layout when there are no back/forward buttons visible. (open up the browser and scroll down on that page, and indeed on the first page loaded after opening the browser).

Comment 4

[Chris Lord [:cwiiis]]

How I imagine doing the transition:

The background of the text in the rocketbar (the bubble) is split into three elements, start, middle and end. The middle is actually only a 1 pixel wide, solid-coloured block and we use a scale transform to grow to the correct size. We use a translate transform to keep the end of the bar in sync with the middle (these elements will all need to be absolutely positioned to a relative box at the start of the bubble).

The width of the text will be set on transitionend when shrinking and immediately when growing (as it can be shorter when in the expanded state, so we don't want it to ever go over the end of the bubble and we don't want to be changing the width during the transition).

Structure-wise, it'd look like:

<div id="rocketbar-background">
  <div class="start"></div>
  <div class="middle"></div>
  <div class="end"></div>
  <span class="text"></span>
</div>

Where #rocketbar-background is position-relative, .start, .middle and .end are position:absolute and the entire size would be determined by .text and any padding/margin/etc. JavaScript would be necessary to size the middle and position the end, but we already have hook points as the transition is triggered by javascript anyway.


The homescreen app-grouping expand/collapse transition does a very similar thing (including the end-cap, though no start-cap). A nice side-effect is that you end up saving a bit as the centre block will be optimised to a ColorLayer (which is cheaper on memory and theoretically cheaper to draw - though the context switch to draw it and its tiny size likely mean there's no difference at all... Or perhaps even a slight negative one...)

Comment 5

[Kevin Grandon :kgrandon]

(In reply to Chris Lord [:cwiiis] from comment #3)
> Comment on attachment 8556743 [details] [review]
> [PullReq] KevinGrandon:bug_1127571_rocketbar_width_fixes to
> mozilla-b2g:master
> However, this r- is mainly because it breaks layout when there are no
> back/forward buttons visible. (open up the browser and scroll down on that
> page, and indeed on the first page loaded after opening the browser).

Doh, I definitely fixed that, but must've forgotten to push!

I agree that it would probably be better with a transition, so I'll experiment with that a bit before re-opening this for review.

Comment 6

[BMO Automation]

Firefox OS is not being worked on