1014818 - [B2G][Flame] Opening card view with keyboard active results in laggy reopening

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::System::Window Mgmt, defect)

Description

[Rachel Pribble [:rpribble]]

Attachment: Logcat.txt

Description:
If the user is in the SMS app with the keyboard active (with or without text entered), then moves to card viewer, the resulting card view will be zoomed in. When the user taps on the card to move back in to the SMS app, the app will not load smoothly as it does without the keyboard drawn, and the user will see the page load in sections and lag.

Repro Steps:
1) Updated Flame to BuildID: 20140522000200
2) Tap the sms icon
3) Create a new message
4) Tap the text entry area to activate the keyboard
5) Long press the home button to open card view
6) Observe zoomed card view
8) Tap the card to enter sms app again
9) Observe sms app reopen in 'blocks' with much lag

Actual:
Lag and 'blocky' loading seen when card view is opened with the keyboard drawn.

Expected:
No lag or 'blocky' loading experienced.

Environmental Variables:
Device: Flame v1.4 MOZ ril
BuildID: 20140522000200
Gaia: 233dd43b3b976e66a619dbc1b4044ed1e3ca3e34
Gecko: c3c0c57daef8
Version: 30.0
Firmware Version: v10F

Notes:

Repro frequency: 100%
See attached: Video, logcat

---------------------------------------------------

This issue also occurs on the Buri v1.4 MOZ ril.

Environmental Variables:
Device: Buri v1.4 MOZ ril
BuildID: 20140521000202
Gaia: 93623f6435849cc9f54d9996e8e64828ac9091d1
Gecko: 12fe2b67a099
Version: 30.0
Firmware Version: v1.2-device.cfg

Card appears zoomed and lag when loading back in to SMS app.

--------------------------------------------------

This issue partially occurs on the Buri v1.3 MOZ ril.

Environmental Variables:
Device: Buri v1.3 MOZ ril
BuildID: 20140520024003
Gaia: 0ce948e378cab7ed3db20231281dd7ca2eb99779
Gecko: ee779e37aca1
Version: 28.0
Firmware Version: v1.2-device.com

The card will appear zoomed if card view is entered with the keyboard drawn, but the keyboards drops back down before the card view is entered, and no lag is seen when re-entering.

Comment 1

[Rachel Pribble [:rpribble]]

Attachment: Video.ogg

Comment 2

[Johan Lorenzo [:jlorenzo]]

This issue also happens with others applications (like e-mail or calendar) on 2.0, as soon as the keyboard is displayed.

Comment 4

[Joshua Mitchell (Inactive)]

moving flags over from bug 1101749 - still repro's on today's 2.2

Environmental Variables:
Device: Flame Master
Build ID: 20150106010234
Gaia: b77e0d56d197e0ee02d801a25c784130d888c9db
Gecko: 2a193b7f395c
Gonk: a814b2e2dfdda7140cb3a357617dc4fbb1435e76
Version: 37.0a1 (Master)
Firmware Version: V18D
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Comment 5

[Julien Wajsberg [:julienw]]

It happens to me a lot from SMS app (where the keyboard is often on). This is not nice at all.

Can we do something about it in v2.2, at least the screenshot part?

Comment 6

[Tim Guan-tin Chien [:timdream] (please needinfo)]

This looks bad, but we probably can't block a version for this.

Comment 7

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Julien Wajsberg [:julienw] (PTO until 1/5) from comment #5)
> It happens to me a lot from SMS app (where the keyboard is often on). This
> is not nice at all.
> 
> Can we do something about it in v2.2, at least the screenshot part?

I am afraid not. Resize the window before going to task manager will just introduce another "slow" operation to you, which will become another "blocker" candidate. And again, open the resized app from task manager is expected to be slow because we don't want to see the app with empty at the bottom so we need to resize again.

One proposed idea is moving keyboard into appWindow but that is a non-trivial work and still has some problems need to get over.

Comment 8

[Gregor Wagner [:gwagner]]

Not a regression and not blocking.

Comment 9

[Chris Lord [:cwiiis]]

I think we could do something nicer for the presentation of apps in this state, rather than the odd, zoomed screenshot. Will open a another bug for that and add the polish keyword.

Comment 10

[Julien Wajsberg [:julienw]]

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #7)
> (In reply to Julien Wajsberg [:julienw] (PTO until 1/5) from comment #5)
> > It happens to me a lot from SMS app (where the keyboard is often on). This
> > is not nice at all.
> > 
> > Can we do something about it in v2.2, at least the screenshot part?
> 
> I am afraid not. Resize the window before going to task manager will just
> introduce another "slow" operation to you, which will become another
> "blocker" candidate. And again, open the resized app from task manager is
> expected to be slow because we don't want to see the app with empty at the
> bottom so we need to resize again.


Wondering if we could take a screenshot before the keyboard is displayed, and use this instead? I mean, never use a screenshot from when the keyboard is displayed?


> 
> One proposed idea is moving keyboard into appWindow but that is a
> non-trivial work and still has some problems need to get over.

Comment 11

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Julien Wajsberg [:julienw] (PTO until 1/5) from comment #10)
> (In reply to Alive Kuo [:alive][NEEDINFO!] from comment #7)
> > (In reply to Julien Wajsberg [:julienw] (PTO until 1/5) from comment #5)
> > > It happens to me a lot from SMS app (where the keyboard is often on). This
> > > is not nice at all.
> > > 
> > > Can we do something about it in v2.2, at least the screenshot part?
> > 
> > I am afraid not. Resize the window before going to task manager will just
> > introduce another "slow" operation to you, which will become another
> > "blocker" candidate. And again, open the resized app from task manager is
> > expected to be slow because we don't want to see the app with empty at the
> > bottom so we need to resize again.
> 
> 
> Wondering if we could take a screenshot before the keyboard is displayed,
> and use this instead? I mean, never use a screenshot from when the keyboard
> is displayed?
> 

Maybe. But the main concern is screenshot cost too much and will affect the performance if we do it in incorrect timing.

Comment 12

[Chris Lord [:cwiiis]]

The laggy reopening is a tougher problem, but the zoomed card should be easy to fix. I've opened bug 1120974 to track the latter, let's separate these issues and try to get that fixed in 2.2.

Comment 13

[BMO Automation]

Firefox OS is not being worked on