Message input field in conversation field cleared after view finishes drawing



Firefox OS
5 years ago
5 years ago


(Reporter: cjones, Assigned: borjasalguero)



Firefox Tracking Flags

(blocking-b2g:-, b2g18+)


(Whiteboard: UX-P?)

 (1) Load a conversation with 150-200 messages so that draw time takes 10 seconds
 (2) During that delay, start entering a message.

(Find to your surprise that the input box is still responsive!)

 (3) Wait for conversation to render

The input box that I just spent many seconds working on was cleared out from under me.  As long as rendering the conversation isn't instant, this is a major problem.

Comment 1

5 years ago
Borja - how much effort would it be to lock the input box from writing or ensure that the input box isn't clear? Whether or not we'll take for v1.0.0/v1.0.1 depends on the level of effort here.
Assignee: nobody → fbsc
tracking-b2g18: --- → +
My conversations are growing while I dogfood, so the time it takes to render them is growing too.

Consequently, it's getting easier to send texts before the view renders.  When I'm able to do this, the SMS app doesn't notice that a text is outgoing, and it doesn't show in the conversation view after sending.  Refreshing the view and waiting for it to render shows it.

That bug feels like data loss.  (It might be actual data loss; awaiting confirmation that the text was received.)

By next week or so, the render time will probably be updwards of 30s so this is going to get very annoying.  I'll probably stop using the phone then though.
Hopefully by next week your SMS app will have a smaller render time because of the perf improvement we're trying to do now ;-)

I believe locking the input box would be as easy as adding "disabled" when rendering it first, and removing "disabled" when we're ready. Also, maybe we might not clear it...

Big inconvenience still: 30s just before we can send a text feels like the app is useless.
(In reply to Chris Jones [:cjones] [:warhammer] from comment #2)
> That bug feels like data loss.  (It might be actual data loss; awaiting
> confirmation that the text was received.)

I did confirm that the text I sent before the conversation was rendered, which wasn't displayed, did reach the recipient.  So no actual data loss, only perceived data loss.

Comment 5

5 years ago
@Julien: Next week I will need your help and review about it ;)
@Chris: Next week I hope to have a proposal, and I will work with Julien in order to have the code landed asap.

Comment 6

5 years ago
No actual data loss here. We're hoping bug 833855 resolves the rendering time, so this is less critical. We'll take a low risk uplift once found.
blocking-b2g: tef? → -
Bug 827815 especially.
Last Resolved: 5 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.