Closed Bug 1025672 Opened 10 years ago Closed 8 years ago

[Messages] Get Messages app working with overlaid keyboard

Categories

(Firefox OS Graveyard :: Gaia::SMS, defect, P3)

defect

Tracking

(tracking-b2g:backlog)

RESOLVED WONTFIX
tracking-b2g backlog

People

(Reporter: drs, Unassigned)

References

Details

In bug 970093, we implement the overlaid keyboard. I created a reference app for this functionality which can be found at http://people.mozilla.org/~dsherk/fxos-overlay-keyboard-reference-app/ (https://github.com/DouglasSherk/fxos-overlay-keyboard-reference-app). This reference app is supposed to look mostly like the SMS app, so it seems natural that we should get the SMS app working with the overlaid keyboard first. This is especially true since we're showing and hiding the keyboard very often here.
Depends on: overlaid-keyboard
Summary: [Messages] Get overlaid keyboard working with Messages app → [Messages] Get Messages app working with overlaid keyboard
We've been asked to deliver the underlying Gecko functionality in bug 970093. Please let us know if this feature is 2.2 or not on the Gaia side, so that we can prioritize bug 970093 accordingly.
feature-b2g: --- → 2.2?
I don't think we'll do the needed work in Messages app to support this. If we can opt-in the current behavior or opt-out the future behavior, then we'll likely do this. If the SMS app is the principal use case for this feature, then we'll need some discussion about the planned features for v2.2.
(In reply to Julien Wajsberg [:julienw] from comment #2) > I don't think we'll do the needed work in Messages app to support this. If > we can opt-in the current behavior or opt-out the future behavior, then > we'll likely do this. The changes that would be needed here aren't really opt-in or opt-out. It would mostly involve layerizing things using `will-change` and making sure that they can be composited in the keyboard-out and keyboard-in positions without any work from layout. I chose the SMS app here for the following reasons: * It seems like the app that makes the most heavy use of the keyboard and pays for it in both perceived and actual performance. * The layout changes needed shouldn't be extremely complicated and I predicted that it wouldn't require massive reworking to get the app to be compatible. * At the time, it was the app that I was most familiar with. * It was closest to the reference app that I wrote, though this is a bit of a tautology. I agree though that this will be a lot of work for the SMS team. This isn't really something that can be tacked on willy-nilly to their current workload.
In bug 970093 I see this is an opt-in behavior though? We'd need an attribute in manifest.webapp to have the new behavior? I agree it would be nice to have this in the SMS app, but you'd need to explain this to our UX team too (maybe easier with a poc :) ). And yeah, our resources are getting sucked by SmartData for v2.2...
Bug 970093 is opt-in, but I imagine that the changes here wouldn't be. When we layerize things and change the CSS/HTML, there's not much we can do to allow opting out of those changes. Ideally, they should work fine even if we opt out of the overlaid keyboard. Indeed, they must, since the keyboard isn't always being shown. We could certainly structure it such that the changes are toggleable, but I can't imagine why we'd want to since it would be such a maintenance nightmare. (In reply to Julien Wajsberg [:julienw] from comment #4) > I agree it would be nice to have this in the SMS app, but you'd need to > explain this to our UX team too (maybe easier with a poc :) ). And yeah, our > resources are getting sucked by SmartData for v2.2... This looked really promising when I was prototyping it. If someone on graphics could rebase bug 970093 and then take a video of it in action, even without any changes to Gaia at all, it would be pretty clear how much faster it'll be.
:drs, is the Gaia patch really needed in Messages app along and not the input management in the System app? If we need to do something for the latter part of Gaia please file a corresponding bug.
Flags: needinfo?(drs.bugzilla)
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #6) > :drs, is the Gaia patch really needed in Messages app along and not the > input management in the System app? If we need to do something for the > latter part of Gaia please file a corresponding bug. I'm not sure what's being asked here. There's a Gaia component to bug 970093, but you posted asking in this bug and not there. The purpose of this bug is to get the SMS app to conform to the layout requirements for the overlaid keyboard. Right now, it's not layerizing the elements that will be recomposited in different positions when the overlaid keyboard is opened. For example, the input bar with the input field and send button will be flattened into the same layer as the rest of the visible window by layout/graphics. It needs to be able to move without being repainted/reflowed, just recomposited. One way to solve this is to layerize it by setting `will-change` on the element that wraps this. Another problem is that the we have to be able to resize the composition bounds of the thread views and still have it be scrollable with header and footer (input bar) elements. This may or may not require any changes in the app itself. There will be much more than this to be done, but to be more specific, we'd need someone to investigate.
Flags: needinfo?(drs.bugzilla)
I simply want to make sure we are not touching System app in any way for this feature. You do know we resize app iframe in System app when the keyboard is shown right? Having the "Gaia" part only filed under Messages app look incomplete to me.
Flags: needinfo?(drs.bugzilla)
Ah, I see. Filed bug 1091797.
Flags: needinfo?(drs.bugzilla)
[Tracking Requested - why for this release]: not in 2.2 must-have scope.
feature-b2g: 2.2? → ---
tracking-b2g: --- → ?
Priority: -- → P3
Mass closing of Gaia::SMS bugs. End of an era :(
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
Mass closing of Gaia::SMS bugs. End of an era :(
You need to log in before you can comment on or make changes to this bug.