Landscape rocketbar shrinking animation is off




5 years ago
4 years ago


(Reporter: gwagner, Assigned: etienne)


Gonk (Firefox OS)
Dependency tree / graph

Firefox Tracking Flags

(tracking-b2g:backlog, b2g-v2.1 verified, b2g-v2.2 verified)



(2 attachments, 1 obsolete attachment)



5 years ago
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.

Comment 1

4 years ago
[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?

Comment 3

4 years ago
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)


4 years ago
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)
Created attachment 8508717 [details]
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
status-b2g-v2.1: --- → affected
status-b2g-v2.2: --- → affected
Keywords: qawanted
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)

Comment 15

4 years ago
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)

Comment 20

4 years ago
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.

Comment 22

4 years ago
Created attachment 8512777 [details] [review]
First try

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+

Comment 25

4 years ago
Created attachment 8513651 [details] [review]
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+


4 years ago
Blocks: 1090562

Comment 27

4 years ago
Last Resolved: 4 years ago
Resolution: --- → FIXED
This is a dependency of bug 1090562. Uplifted to v2.1:
status-b2g-v2.1: affected → fixed
status-b2g-v2.2: affected → 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?]
status-b2g-v2.1: fixed → verified
status-b2g-v2.2: fixed → verified
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Depends on: 1097941
blocking-b2g: backlog → ---
tracking-b2g: --- → backlog
You need to log in before you can comment on or make changes to this bug.