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

RESOLVED DUPLICATE of bug 1023928

Status

()

Core
Graphics
RESOLVED DUPLICATE of bug 1023928
4 years ago
3 years ago

People

(Reporter: Ross Kuhlman (rkuhlman@qanalydocs.com), Assigned: pchang)

Tracking

unspecified
mozilla33
ARM
Gonk (Firefox OS)
Points:
---

Firefox Tracking Flags

(blocking-b2g:2.0+, firefox31 wontfix, firefox32 wontfix, firefox33 fixed, b2g-v1.4 wontfix, b2g-v2.0 fixed, b2g-v2.1 fixed)

Details

(Whiteboard: [2.0-flame-test-run-2])

Attachments

(4 attachments)

Created attachment 8444796 [details]
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
adding qawanted to determine if issue occurs in v1.4 and v2.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawanted
Whiteboard: [2.0-flame-test-run-2]
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
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?
QA Contact: 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.
QA Whiteboard: [QAnalyst-Triage?]
status-b2g-v1.4: --- → unaffected
status-b2g-v2.0: --- → affected
status-b2g-v2.1: --- → affected
Flags: needinfo?(jmitchell)
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...).
blocking-b2g: --- → 2.0?
(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.
Component: Gaia::SMS → General
Flags: needinfo?(rlu)
Flags: needinfo?(pchang)
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.
Component: General → Graphics
Flags: needinfo?(rlu)
Product: Firefox OS → Core
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
Keywords: qawanted → regression
Looks like the same rounding issue than in bug 1023190 then...
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.

Updated

4 years ago
blocking-b2g: 2.0? → 2.0+

Updated

4 years ago
Keywords: regressionwindow-wanted

Updated

4 years ago
QA Whiteboard: [QAnalyst-Triage+]
(Assignee)

Comment 9

4 years ago
(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.
Flags: needinfo?(pchang)
(Assignee)

Comment 10

4 years ago
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?
Preeti, who can answer Peter's keyboard app question from comment 10?
Flags: needinfo?(praghunath)
Rudy should.
Flags: needinfo?(praghunath) → needinfo?(rlu)
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.
Regression-window is not available. This issue occurs in the oldest possible Flame build we have access to

Build ID: 20140417000006
QA Whiteboard: [QAnalyst-Triage+]
Keywords: regressionwindow-wanted
Created attachment 8452884 [details]
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
Flags: needinfo?(rlu)
FWIW, the above test (comment 15) was done on helix, so not only Flame could be used to reproduce this issue.
(Assignee)

Updated

4 years ago
Assignee: nobody → pchang
(Assignee)

Comment 17

4 years ago
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
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
(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..
(Assignee)

Comment 20

4 years ago
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>

Updated

4 years ago
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
status-b2g-v1.4: unaffected → affected
Keywords: regression

Comment 21

4 years ago
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.
Flags: needinfo?(pchang)
(Assignee)

Comment 22

4 years ago
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.
(Assignee)

Comment 23

4 years ago
I just sync to latest gecko and looks like this issue was fixed.
Need to figure out which patch fix this issue.
Flags: needinfo?(pchang)
(Assignee)

Comment 24

4 years ago
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 <cku@mozilla.com>
Date:   Mon Jul 7 07:36:00 2014 -0400

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

Comment 25

4 years ago
Created attachment 8458432 [details] [diff] [review]
0001-Bug-1023928-System-UX-The-waiting-icon-now-comes-wit.patch

carry the r+ patch from master.
Attachment #8458432 - Flags: review+
(Assignee)

Updated

4 years ago
Keywords: checkin-needed
status-b2g-v2.1: affected → fixed
status-firefox31: --- → wontfix
status-firefox32: --- → affected
status-firefox33: --- → fixed
Depends on: 1023928
Keywords: checkin-needed
Target Milestone: --- → mozilla33
Is there something that needs to be landed or uplifted with this?
(Assignee)

Comment 27

4 years ago
(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.
(Assignee)

Updated

4 years ago
Flags: needinfo?(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.
status-firefox32: affected → wontfix
Flags: needinfo?(ryanvm)
This is a dupe of bug 1023928.  Moving the 2.0+ there.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1023928
No longer depends on: 1023928
status-b2g-v1.4: affected → wontfix
status-b2g-v2.0: affected → fixed

Comment 30

3 years ago
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

3 years ago
Created attachment 8533467 [details]
Verify_Flame_SMS.MP4
You need to log in before you can comment on or make changes to this bug.