1029230 - [B2G][Messaging]Horizontal line dividing message thread and compose text area does not account for auto-suggest bar

Status: RESOLVED DUPLICATE of bug 1023928

(Core :: Graphics, defect)

Description

[Ross Kuhlman ([e-mail])]

Attachment: horizontalLineComparison.jpg

In the SMS app, there is a faint horizontal line that separates the compose text area and the message thread area. When the user begins typing in the compose text area, the autosuggest bar appears. The 'Send' button and message text move upwards to account for appearance of autosuggest bar. However, the horizontal dividing line does not, and is now intersecting the 'Send' button

Repro Steps:
1) Update a Flame to BuildID: 20140623095853
2) Launch SMS app
3) Tap on 'to' field to enter a contact or number
4) Observe horizontal line between sms thread and compose text area
5) Tap on compose text area to move text cursor to it

Actual:
Autosuggest bar appears. message text and 'Send' button move upwards to account for additional space. Horizontal line does not move, and now intersects message text and send button

Expected:
Horizontal dividing line moves upwards when autosuggest bar appears

Master M-C Environmental Variables:
Device: Flame Master M-C MOZ
BuildID: 20140623095853
Gaia: 41cc1de26e4edbe12add0009cdc0bd292f2e94fe
Gecko: 31de1a84b27f
Version: 33.0a1
Firmware Version: v122

Notes:
I had to take pictures of the screen with a different device, because the horizontal bar does not show up in screenshots for some reason.

Repro frequency: 100%
See attached: logcat

Comment 1

[Ross Kuhlman ([e-mail])]

adding qawanted to determine if issue occurs in v1.4 and v2.0

Comment 2

[Julien Wajsberg [:julienw]]

This behavior may change with bug 1008127.

Also, there is no line on my Buri, could it be happening on HD phones only like bug 1023190?

QA: is it possible to try this on Buri on v2.0 and v2.1?

Comment 3

[Chris Kreinbring [:CKreinbring]]

This bug repros on Flame 2.1, Flame 2.0 and Open C 2.0

Flame 2.1
Build ID: 20140701040201
Gaia: 90bb898e8401f5fb98edcf38293073c5c26ab7bd
Gecko: 83c09fe3a658
Platform Version: 33.0a1
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

Flame 2.0
Build ID: 20140701000201
Gaia: 8fb5e2a9ad1025ee7d247b90af7499766afadd28
Gecko: 5da69a493324
Platform Version: 32.0a2
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Open C 2.0
Build ID: 20140701000201
Gaia: 8fb5e2a9ad1025ee7d247b90af7499766afadd28
Gecko: 5da69a493324
Platform Version: 32.0a2
Firmware Version: P821A10V1.0.0B06_LOG_DL
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Actual result: When the message textbox is tapped with Word Suggestion on, the horizontal line marking the border between the textbox and the conversation area will not move causing it to appear through the textbox and the Send button.

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

The bug does not repro on Buri 2.1, Buri 2.0 and Flame 1.4

Flame 1.4
Build ID: 20140630000201
Gaia: aa896d5db1b4929f3bf31a0f4bb7de50530222a8
Gecko: 8cba60bc12ef
Platform Version: 30.0
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0

Buri 2.1
Build ID: 20140701063753
Gaia: 34a52e7f024cc3d0e3aade94970773d2555f5ccb
Gecko: ffb8b976548b
Platform Version: 33.0a1
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

Buri 2.0
Build ID: 20140701021753
Gaia: 8fb5e2a9ad1025ee7d247b90af7499766afadd28
Gecko: dd61b50b2bcf
Platform Version: 32.0a2
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Actual result: For Flame, tapping the message textbox with Word Suggestion on moves the entire textbox and Send button upwards, including the border between the textbox and the conversation area.  
For Buri, there is no visible top border between the message textbox and the conversation area, so tapping it with Word Suggestion on moves the textbox and Send button up with no visible line through them.

Comment 4

[Julien Wajsberg [:julienw]]

I think the "line" does not come from SMS but from something else.

QA: can we look if the line appears in other applications too when the keyboard is up ? (email, browser...).

Comment 5

[Steve Chung [:steveck]]

(In reply to Julien Wajsberg [:julienw] from comment #4)
> I think the "line" does not come from SMS but from something else.
> 
> QA: can we look if the line appears in other applications too when the
> keyboard is up ? (email, browser...).

I checked other apps(email/contact) and they also have this issue. After some invesigate with Rudy, this line is related to some widgets on keyboard, but it might be another rounding issue from graphics team since it's depends on the device resolution. ni? to graphics member and keyboard owner.

Comment 6

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Hi all,

This strange issue is related to keyboard app.
When I hide the body of keyboard app, this line would disappear.

After checking, this is somehow related to the following style,
https://github.com/mozilla-b2g/gaia/blob/466c76b796f7c31311d55615b3c16bede5fe5f46/apps/keyboard/style/keyboard.css#L129 
If you tweak the top of .popup, you could adjust the position of this line.
I could not find out what style (say background-color, border or anything) that caused this strange line, and we don't even show this .popup element, so might need Graphics team to help take a look.

Comment 7

[Julien Wajsberg [:julienw]]

Looks like the same rounding issue than in bug 1023190 then...

Comment 8

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

FWIW, I just checked the border and background color of #keyboard element in keyboard app with Peter, but it seems this won't affect this strange line.

Peter, you may change the color of these properties here if you want to play with it,
https://github.com/mozilla-b2g/gaia/blob/466c76b796f7c31311d55615b3c16bede5fe5f46/apps/keyboard/style/keyboard.css#L41-L42

Thanks.

Comment 9

[Peter Chang[:pchang]]

(In reply to Rudy Lu [:rudyl] from comment #8)
> FWIW, I just checked the border and background color of #keyboard element in
> keyboard app with Peter, but it seems this won't affect this strange line.
> 
> Peter, you may change the color of these properties here if you want to play
> with it,
> https://github.com/mozilla-b2g/gaia/blob/
> 466c76b796f7c31311d55615b3c16bede5fe5f46/apps/keyboard/style/keyboard.
> css#L41-L42
> 
> Thanks.

I just disable the keyboard layer on compositor side and saw the strange line disappeared.
Confirm the line is related to keyboard.

(In reply to Julien Wajsberg [:julienw] from comment #7)
> Looks like the same rounding issue than in bug 1023190 then...
Bug 1023190 has problem when draw background image with repeat-x only. It looks like not the same root cause, maybe it is another rounding issue.

Comment 10

[Peter Chang[:pchang]]

BTW, right now keyboard app is on the top of screen. That's why you see the extra horizontal line displayed on the screen.

Do we have any difference of keyboard app between frame 1.4 and frame 2.0?

Comment 11

[Milan Sreckovic [:milan] (needinfo for best results)]

Preeti, who can answer Peter's keyboard app question from comment 10?

Comment 12

[Julien Wajsberg [:julienw]]

Rudy should.

Comment 13

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

We have serveral CSS style updates for v2.0, but we did not change the top property of the popup, as described in comment 8.
I'll try to reproduce this again with v1.4 styles to see if this makes any difference.
So, keep ni myself.

Comment 14

[Joshua Mitchell (Inactive)]

Regression-window is not available. This issue occurs in the oldest possible Flame build we have access to

Build ID: 20140417000006

Comment 15

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Attachment: strange_line_v1.4.png

Hi all,

I still could reproduce this issue when using v1.4 Gaia onto v2.0 Gecko,

Gaia
====
v1.4
revision: c73c46a7c9d418c14c74cbf0f88d93d98b169454

Gecko
====
Gecko     https://hg.mozilla.org/releases/mozilla-aurora/rev/f5ef28f79882
BuildID   20140705000201
Version   32.0a2
ro.build.version.incremental=eng.cltbld.20140623.194406
ro.build.date=Mon Jun 23 19:44:23 EDT 2014

Comment 16

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

FWIW, the above test (comment 15) was done on helix, so not only Flame could be used to reproduce this issue.

Comment 17

[Peter Chang[:pchang]]

The real size of keybard is bigger than you see on the device because it also needs to display the text selection popup.

The following is the popup CSS properties and it is configured as absolute position.

126 .popup {
127   position: absolute;
128   top: -5.8rem;
129   left: calc(50% - 2.8rem);
130   width: 5.6rem;
131   height: 5.6rem;
132   color: #fff;
133   font-size: 2.8rem;
134   line-height: 5.6rem;
135   border-radius: 50%;
136   background-color: #00aacc;
137   visibility: hidden;
138 
139   /* To override the text-align in .float-key-first and .float-key-last */
140   text-align: center;
141 }


After checking the frame tree[1], I suspect the horizontal line is related to first block element from the absolute list.

Checking layout code about absolute element now...

Block(div)(1)@b3dda7d0 {0,20400,19200,13760} vis-overflow=-720,-1720,20640,15480 scr-overflow=-720,-1720,20640,15480 [state=0002106008c00300] [content=b32beba0] [sc=b3dda3b8,parent=b3dd9e80]<

[1]https://pastebin.mozilla.org/5536829

Comment 18

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

I tried to create a simpler layout to reproduce, what I've tried is this testing branch,
https://github.com/RudyLu/gaia/tree/debug/Bug1029230

Comment 19

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

(In reply to Rudy Lu [:rudyl] from comment #18)
> I tried to create a simpler layout to reproduce, what I've tried is this
> testing branch,
> https://github.com/RudyLu/gaia/tree/debug/Bug1029230

However, so far I could not find a way to reproduce the same issue..

Comment 20

[Peter Chang[:pchang]]

Finally I find that extra line is related to the 'Content' display list[1] and this display item is from the block frame of keyboard row0(class=keyboard-row row0).

If I skip the content display list for that block frame[1], I won't see the line displayed on the screen.

Next step, checking what is the 'Content' display list.
[1]http://dxr.mozilla.org/mozilla-central/source/layout/base/nsDisplayList.cpp?from=nsDisplayList.cpp&case=true#1014


[Keyboard]
<div class="keyboard-row row0" data-layout-width="10" style="height: 166px; width: 90%;">
    <button class="keyboard-key float-key-first" style="width: 32px;" aria-label="q" data-row="0" data-column="0" data-keycode="113" data-keycode-upper="81" data-lowercase-label="q" role="key">
        <span class="visual-wrapper">
            <span class="key-element" data-label="Q"></span>
            <span class="uppercase popup"></span>
            <span class="lowercase popup"></span>

Comment 21

[Kai-Chih Hu [:khu]]

Peter, because this is a 2.0+ blocker and the timing is very critical now, can you provide another update for us? And, do we know the possible ETA? Thanks.

Comment 22

[Peter Chang[:pchang]]

The extra line was caused by the height of first row of keyboard app was 157.5 device pixel which is mapped to 105 CSS pixel. The layer system creates buffer by scaling out 157.5 as 158 for painting. And keyboard is aligned from the bottom of screen.


One solution is to snap the button from nsHTMLButtonControlFrame::BuildDisplayList.

Comment 23

[Peter Chang[:pchang]]

I just sync to latest gecko and looks like this issue was fixed.
Need to figure out which patch fix this issue.

Comment 24

[Peter Chang[:pchang]]

This issue was fixed by the following commit.
As mentioned in comment 22, content didn't paint the full size of layer buffer(1 pixel missing).

This line was caused by the default wrap mode is repeat during composition.
And the following commit fix this issue.

commit 89f0bf3b2f4d35a4dad1d6b24702b34146d935c3
Author: CJKu <[e-mail]>
Date:   Mon Jul 7 07:36:00 2014 -0400

    Bug 1023928 - [System][UX] The waiting icon now comes with a dirty dot. r=nical

Comment 25

[Peter Chang[:pchang]]

Attachment: 0001-Bug-1023928-System-UX-The-waiting-icon-now-comes-wit.patch

carry the r+ patch from master.

Comment 26

[Milan Sreckovic [:milan] (needinfo for best results)]

Is there something that needs to be landed or uplifted with this?

Comment 27

[Peter Chang[:pchang]]

(In reply to Milan Sreckovic [:milan] from comment #26)
> Is there something that needs to be landed or uplifted with this?

Ryan, this fix also needs to uplift to b2g-v2.0 branch.

Comment 28

[Ryan VanderMeulen [:RyanVM]]

I nominated bug 1023928 for blocking status last week. This bug should be resolved that way rather than landing the same patch under different bug numbers. Not sure who's triaging the blocking requests right now.

Comment 29

[Milan Sreckovic [:milan] (needinfo for best results)]

This is a dupe of bug 1023928.  Moving the 2.0+ there.

Comment 30

[Coler]

This issue has been verified successfully on Flame2.1&2.0.
Reproducing rate: 0/5
See attachment: Verify_Flame_SMS.mp4

Note:There is no horizontal line bettween compose text area and the message thread area in Flame 2.0.

Flame2.0 build version:
Gaia-Rev        856863962362030174bae4e03d59c3ebbc182473
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/e40fe21e37f1
Build-ID        20141208000206
Version         32.0

Flame2.1 build version:
Gaia-Rev        38e17b0219cbc50a4ad6f51101898f89e513a552
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/8b92c4b8f59a
Build-ID        20141205001201
Version         34.0

Comment 31

[Coler]

Attachment: Verify_Flame_SMS.MP4