Closed Bug 1071114 Opened 7 years ago Closed 6 years ago

Landscape rocketbar shrinking animation is off


(Core :: Graphics, defect)

Gonk (Firefox OS)
Not set



tracking-b2g backlog
Tracking Status
b2g-v2.1 --- verified
b2g-v2.2 --- verified


(Reporter: gwagner, Assigned: etienne)




(2 files, 1 obsolete file)

I have a debug gecko build which shows an obvious glitch in the shrinking animation for the rocketbar.
When showing the collapsed rocketbar, the URL field starts as a rectangle and gets rounded corners after some time.
[Blocking Requested - why for this release]:

This is also pretty bad with an optimize build.
blocking-b2g: --- → 2.1?
It seems like this is possibly a graphics issue?
Logcat also shows this during the transition:
E/GeckoConsole( 1087): [JavaScript Error: "TypeError: element is undefined" {file: "app://" line: 589}]
(In reply to Gregor Wagner [:gwagner] from comment #3)
> Logcat also shows this during the transition:
> E/GeckoConsole( 1087): [JavaScript Error: "TypeError: element is undefined"
> {file: "app://" line: 589}]

I think this was a false-positive fixed today in bug 1082667.
It might be a platform issue with OMTA. The border radius seems to be ignored for the duration of the transform transition. If I remove the transition:transform at [1] then the corners remain rounded as expected. I did notice also that the border-radius comes from [2] when the urlbar is maximized and a mixture of [2] (for the left corners) and [3] (for the right corners) when the urlbar is minimized, so that might also have something to do with it.

It does appear that we have border-radius on two different elements currently. In the long term I'd like to avoid this by using display: box, but that is going to be a major refactoring of rocketbar.

For now - can we move this into the graphics component to see why border-radius is being ignored during OMTA? Kats - is this something you can help us with?
Component: Gaia::Browser → Graphics
Flags: needinfo?(bugmail.mozilla)
Product: Firefox OS → Core
Matt might be a better person for this. I'm guessing it's some sort of restrictions with mask layers or something?
Flags: needinfo?(bugmail.mozilla) → needinfo?(matt.woodrow)
Brian may be able to help.
Flags: needinfo?(birtles)
OS: Mac OS X → Gonk (Firefox OS)
Whiteboard: [systemsfe]
Any chance of a video demonstrating the problem? Based on the description I can't reproduce the problem on a build from about 3 weeks ago.
Flags: needinfo?(birtles) → needinfo?(anygregor)
Attached video Video of the bug
Flags: needinfo?(anygregor) → needinfo?(birtles)
Can QA help test this on a 2.1 production build ?
Keywords: qawanted
Issue Repro's on Flame 2.1 and Flame 2.2  (Feature not available in 2.0)

Note - Only occurs in LANDSCAPE mode 

Device: Flame 2.1 - KK base - Shallow Flash
Build ID: 20141021001201
Gaia: e458f5804c0851eb4e93c9eb143fe044988cecda
Gecko: ee86921a986f
Version: 34.0 (2.1)
Firmware Version: V188
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Device: Flame 2.2 - KK Base - Shallow Flash
Build ID: 20141021040206
Gaia: 457a54fc3200b80e4f5e1cd3acaa062309230732
Gecko: 29fbfc1b31aa
Version: 36.0a1 (2.2)
Firmware Version: V188
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0
Triage decided, sadly, not blocking because landscape mode which reduces user impact, and doesn't really meet any other blocker criteria. If you have a patch landed on master, re-nom once you have a risk estimate, or just ask for patch approval to uplift.
blocking-b2g: 2.1? → backlog
CC-ing No-Jun, there are other "landscape only" issues creeping in, wonder if they're related.
Flags: needinfo?(matt.woodrow)
There is also another bug with the software home button enabled where the rocketbar in extended state stick around for too long:
Hi Gregor, sorry I won't be able to look at this properly until next week but can I get a pointer to the source for the animation/transition in landscape mode?
Flags: needinfo?(birtles) → needinfo?(anygregor)
It seems to me we're doing some reflow of the start of this transition that we don't do when we're in portrait mode. I see some flicker at the start of the animation but only in landscape mode. In fact, it seems like we start doing the animation, do some restyling, then restart the animation. Is there any difference to the content when we are in landscape mode?

It seems like we might end up layerizing without the border-radius applied. When we drop the layer at the end of the transition we re-render with the correctly computed border-radius. I'm curious if there's some other action we take when the collapse the rocketbar (particularly if it's something that only happens in landscape mode) that causes a reflow. (Unfortunately I can't get WebIDE to talk to my Flame anymore so I can't easily check this myself yet.)

(Another, less likely, possibility is that we are actually rendering the border-radius but the layer is too small/large so by the time we scale it the border-radius appears to be square.)
Flags: needinfo?(birtles) → needinfo?(anygregor)
Adding n?vingtetun for comment #18 - I'm not sure how the controls are hidden, but that may cause a reflow... But I don't think there's any difference between what happens in portrait and landscape.

It might be worth disabling the HWC (hardware compositor) in the dev settings and restarting, just to rule that out.
Flags: needinfo?(21)
Kevin or Etienne should be able to help out as well.
Flags: needinfo?(kgrandon)
Flags: needinfo?(etienne)
Flags: needinfo?(anygregor)
I'll look into this soon, but I agree - I don't think there's a difference between portrait and landscape. 

(In reply to Chris Lord [:cwiiis] from comment #19)
> It might be worth disabling the HWC (hardware compositor) in the dev
> settings and restarting, just to rule that out.

I've disabled HWC and the issue still reproduces.
Attached file First try (obsolete) —
I think the issue might come from the instant where the background is sampled (??) for the rounded corners.

The dom looks like this
|background div |bigger border-radius div|smaller border-radius div|||

At the very beginning of the transition the color behind the smaller div is the heavy gray from the bigger div, the same color than the div itself, so you can't actually see the radius. Then the background of the bigger div switches to transparent, but we're transitioning a transform on the smaller div at the same time and maybe not re-sampling what's behind the corners?

Anyway, setting a background-color on the bigger deiv instead of having it be transparent fixes the issue.
Also, we were dispatching the appchomecollapsed a bit early since the controls transition was finishing earlier (and bubbling to our transition end listener).
Flags: needinfo?(etienne)
Attachment #8512777 - Flags: feedback?(
Thanks for picking this up Etienne!
Flags: needinfo?(kgrandon)
Flags: needinfo?(21)
Comment on attachment 8512777 [details] [review]
First try

Nothing about these changes looks like it'd cause any problems and the event listener stuff looks good. Good work, assuming it works around the bug :)
Attachment #8512777 - Flags: feedback?( → feedback+
Attached file Gaia PR
New cleaned-up version with tests, ready for review!
Assignee: nobody → etienne
Attachment #8512777 - Attachment is obsolete: true
Attachment #8513651 - Flags: review?(
Comment on attachment 8513651 [details] [review]
Gaia PR

Looks good :)
Attachment #8513651 - Flags: review?( → review+
Blocks: 1090562
Closed: 6 years ago
Resolution: --- → FIXED
Issue verified fixed in Flame 2.1 and Flame 2.2

Actual Results: The Rocketbar has rounded edges at all times. Gregor's shrinking issue in comment 15 does not manifest with or without SHB enabled.

Device: Flame 2.1 (319mb)(Kitkat Base)(Full Flash)
BuildID: 20141104001202
Gaia: 8b0cf889ae0d48a9eb7ecdcb9b67590de45cc5e5
Gecko: 388b03efe92d
Gonk: 48835395daa6a49b281db62c50805bd6ca24077e
Version: 34.0 (2.1)
Firmware: V188
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Device: Flame 2.2 Master (319mb)(Kitkat Base)(Full Flash)
BuildID: 20141104040207
Gaia: 3c50520982560ccba301474d1ac43706138fc851
Gecko: 54d05732f29b
Gonk: 48835395daa6a49b281db62c50805bd6ca24077e
Version: 36.0a1 (2.2 Master)
Firmware: V188
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Depends on: 1097941
blocking-b2g: backlog → ---
You need to log in before you can comment on or make changes to this bug.