1084173 - [Midori 2.0][SMS]The title of Messages appears to move quickly.

Status: RESOLVED DUPLICATE of bug 1089920

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

Description

[sync-1]

Mozilla Build ID: 20140916000205
 Created an attachment (id=971716)
 issue_pic
 
 DEFECT DESCRIPTION:
 The title of Messages appears to move quickly.
 
  REPRODUCING PROCEDURES:
 1.Launch messages app for the first time;
 2.The title of Messages appears to move quickly.-->KO
 
  EXPECTED BEHAVIOUR:
 The title of Messages remain unchanged.
 
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:Medium
 
  REPRODUCING RATE:5/5
 
  For FT PR, Please list reference mobile's behavior:

Comment 1

[sync-1]

Attachment: issue_pic1

Comment 2

[sync-1]

Attachment: issue_pic

Comment 3

[sync-1]

Attachment: PR808090_jrdlog

Comment 4

[Julien Wajsberg [:julienw]]

NI Wilson.

Do you think this happens because of the synchronous reflow triggered by the gaia-header component?

I really don't think we want to change this in 2.0 though :/

Comment 5

[Wilson Page [:wilsonpage]]

(In reply to Julien Wajsberg [:julienw] from comment #4)
> NI Wilson.
> 
> Do you think this happens because of the synchronous reflow triggered by the
> gaia-header component?
> 
> I really don't think we want to change this in 2.0 though :/

The gaia-header component didn't actually make it into v2.0, so this logic is taken care of by the earlier headers.css and shared/js/font_size_utils.js.

We are seeing the header painted before the font-fit logic has calculated and set the size/position of the title text. I haven't seen this before, is it running on a particularly low-end device?

One solution would be to hide the text (via visibility/opacity), until positioning is complete.

Comment 6

[田旻]

We can add the computed result in to html to fix this problem.
diff --git a/apps/sms/index.html b/apps/sms/index.html
index 7319a44..0b7ad1f 100644
--- a/apps/sms/index.html
+++ b/apps/sms/index.html
@@ -102,7 +102,7 @@
               <span class="icon icon-options"></span>
             </a>
           </menu>
-          <h1 data-l10n-id="messages">Messages</h1>
+          <h1 data-l10n-id="messages" style="margin-left: 100px">Messages</h1>
         </header>
         <article id="threads-container" class="view-body edit-container" data-type="list">
         </article>
--

Comment 7

[Julien Wajsberg [:julienw]]

The main issue is that this margin is likely dependent on the locale :/

Comment 8

[Steve Chung [:steveck]]

(In reply to Wilson Page [:wilsonpage] from comment #5)
> (In reply to Julien Wajsberg [:julienw] from comment #4)
> > NI Wilson.
 
> We are seeing the header painted before the font-fit logic has calculated
> and set the size/position of the title text. I haven't seen this before, is
> it running on a particularly low-end device?

I vaguely remember that I even saw this on relatively low-end device buri(haven't used it for long time, and I don't have a usable one right now :/), but I can't reproduce on flame, so probably just like wilson said in comment 5. Just curious that it seems a general issue for all the header, does it reproducible in other apps like contacts? Ni? partner about the target device spec and behavior in other apps.

Comment 9

[田旻]

(In reply to Steve Chung [:steveck] from comment #8)
> (In reply to Wilson Page [:wilsonpage] from comment #5)
> > (In reply to Julien Wajsberg [:julienw] from comment #4)
> > > NI Wilson.
>  
> > We are seeing the header painted before the font-fit logic has calculated
> > and set the size/position of the title text. I haven't seen this before, is
> > it running on a particularly low-end device?
> 
> I vaguely remember that I even saw this on relatively low-end device
> buri(haven't used it for long time, and I don't have a usable one right now
> :/), but I can't reproduce on flame, so probably just like wilson said in
> comment 5. Just curious that it seems a general issue for all the header,
> does it reproducible in other apps like contacts? Ni? partner about the
> target device spec and behavior in other apps.

No, it just can be reproduced in sms app.

Comment 10

[Julien Wajsberg [:julienw]]

I think this happens especially in the SMS app because we add more data to the DOM before gaia-header tries to measure things. As a result, a reflow happens.

I'll ask some layout guys, maybe our CSS can be improved to prevent this, or maybe we need platform support.

Comment 11

[Wilson Page [:wilsonpage]]

(In reply to Julien Wajsberg [:julienw] from comment #10)
> I think this happens especially in the SMS app because we add more data to
> the DOM before gaia-header tries to measure things. As a result, a reflow
> happens.
> 
> I'll ask some layout guys, maybe our CSS can be improved to prevent this, or
> maybe we need platform support.

I think deferring the large job of populating the message list for just a few milliseconds will give the font-fit logic an earlier turn in the event loop. I played around with this briefly and found populating the messages list after `window` 'load' fixed a similar issue.

Comment 12

[田旻]

We have fixed this bug, it's not a bug for us any more.

Comment 13

[Julien Wajsberg [:julienw]]

Tianm, can you please explain how you fixed this bug?

Comment 14

[田旻]

--- a/apps/sms/index.html
+++ b/apps/sms/index.html
@@ -102,7 +102,7 @@
               <span class="icon icon-options"></span>
             </a>
           </menu>
-          <h1 data-l10n-id="messages">Messages</h1>
+          <h1 data-l10n-id="messages" style="margin-left: 100px">Messages</h1>
         </header>
         <article id="threads-container" class="view-body edit-container" data-type="list">
         </article>
--

Comment 15

[田旻]

(In reply to Julien Wajsberg [:julienw] from comment #13)
> Tianm, can you please explain how you fixed this bug?

Add the moving distance in the html could avoid the computing delay.

Comment 16

[Julien Wajsberg [:julienw]]

Tianm, did you try in other languages that don't use "Messages" as title?

Comment 17

[田旻]

(In reply to Julien Wajsberg [:julienw] from comment #16)
> Tianm, did you try in other languages that don't use "Messages" as title?
Yes, I think you're right, it behaves well mostly,but in some special langage,such as Arabic, it can't work.

Comment 18

[Julien Wajsberg [:julienw]]

I think it's now fixed by bug 1089920.