Closed Bug 1027593 Opened 10 years ago Closed 10 years ago

[SMS] Long messages become blurry

Categories

(Core :: Panning and Zooming, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla33
blocking-b2g 2.0+
Tracking Status
firefox30 --- wontfix
firefox31 --- wontfix
firefox32 --- fixed
firefox33 --- fixed
b2g-v1.4 --- unaffected
b2g-v2.0 --- fixed
b2g-v2.1 --- fixed

People

(Reporter: arcturus, Assigned: kats)

References

Details

(Keywords: regression)

Attachments

(4 files, 3 obsolete files)

Found myself writing an sms pretty long, actually splint in 2 messages, and when i was 109 characters left from the 2nd message stop seeing what I was writing. Seems it happened when the layout was full, then i was able to see what I wrote when pulling down the input area. Then when sending the message got the following error: E/GeckoConsole( 1019): Content JS LOG at app://keyboard.gaiamobile.org/gaia_build_defer_index.js:4 in LayoutManager.prototype.switchCurrentLayout/p<: LayoutManager: Promise is resolved after another switchCurrentLayout() call. Reject the promise instead. E/GeckoConsole( 1019): Content JS WARN at app://keyboard.gaiamobile.org/gaia_build_defer_index.js:117 in updateCurrentLayout/<: Failed to switch layout for en. It might possible because we were called more than once. E/GeckoConsole( 1019): Content JS WARN at app://keyboard.gaiamobile.org/gaia_build_defer_index.js:249 in switchIMEngine/<: Failed to switch imEngine for en. It might possible because we were called more than once. E/GeckoConsole( 1019): Content JS WARN at app://keyboard.gaiamobile.org/gaia_build_defer_index.js:249 in switchIMEngine/<: Failed to switch imEngine for en. It might possible because we were called more than once.
Forgot to menting, it happened to me while dogfooding 2.1 with Open C
Just managed to send the sms once I saved the original one as draft and reopen again for editing.
The logcat is probably irrelevant. Can you possibly tell us if this is always reproducing, or only once? Could be a regression from bug 1015867 :(
Flags: needinfo?(francisco)
Yes it's reproducible 100%, just need to fill the input are once the keyboard is open, so I guess that depending on the device the number of characters will be different.
Flags: needinfo?(francisco)
QA, can we please test on v2.1 and v2.0 on Flame ? I don't reproduce on Buri v2.1.
Keywords: qawanted
Hey Jason, any chance you can make the qawanted request happen?
Flags: needinfo?(jsmith)
Sure. Redirecting to Josh to get an assignee here.
Flags: needinfo?(jsmith) → needinfo?(jmitchell)
Flags: needinfo?(jmitchell)
QA Contact: croesch
On the Flame 2.1 Master, text stops populating at 6 characters left on page 3 (so 6/3 shows on the side). The cursor will stop printing characters when typing. On the Flame 2.0, the text will stop appearing at (80/2) On the Buri 2.1, the text will stop appearing at (78/6) This bug repro's on: Flame 2.1 Master, Flame 2.0, Buri 2.1 Actual Results: Environmental Variables: Device: Flame Master Build ID: 20140629193729 Gaia: de14e61098b742251b34f856e48649db8bed552c Gecko: b6408c32a170 Version: 33.0a1 (Master) Firmware Version: v122 ---------------------------------------------- Environmental Variables: Device: Flame 2.0 Build ID: 20140629214227 Gaia: c0c8ad187c0466285f2580531e09f8322996f561 Gecko: d4dc609bcc8a Version: 32.0a2 (2.0) Firmware Version: v122 ---------------------------------------------- Environmental Variables: Device: Buri Master Build ID: 20140629193729 Gaia: de14e61098b742251b34f856e48649db8bed552c Gecko: b6408c32a170 Version: 33.0a1 (Master) Firmware Version: v1.2device.cfg ----------------------------------------------- ----------------------------------------------- This bug does NOT repro on: Flame 1.4, Actual Result: Created over 10 pages of sms text and still no issues with text disappearing. Environmental Variables: Device: Flame 1.4 Build ID: 20140629211929 Gaia: aa896d5db1b4929f3bf31a0f4bb7de50530222a8 Gecko: 8cba60bc12ef Version: 30.0 (1.4) Firmware Version: v122
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawantedregression
blocking-b2g: --- → 2.0?
Would be useful to have a regression window, if it's not too much work. One culprit is bug 949457, could also be bug 1015867. But it could also be a Gecko issue.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
QA Contact: croesch → pcheng
b2g-inbound regression window: Last Working Environmental Variables: Device: Flame Build ID: 20140612193719 Gaia: aa125bd4f448c65c94fca678ead21f6e68d239fc Gecko: 685d988cb37f Version: 33.0a1 (Master) Firmware Version: B1TC00011220 User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0 First Broken Environmental Variables: Device: Flame Build ID: 20140613050717 Gaia: 07ab0bb6a6b26f4b0a2aaafb0c725f20464440de Gecko: 71e899337efa Version: 33.0a1 (Master) Firmware Version: B1TC00011220 User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0 First broken gecko & last working gaia - issue does NOT repro Gaia: aa125bd4f448c65c94fca678ead21f6e68d239fc Gecko: 71e899337efa Last working gecko & first broken gaia - issue DOES repro Gaia: 07ab0bb6a6b26f4b0a2aaafb0c725f20464440de Gecko: 685d988cb37f Gaia pushlog: https://github.com/mozilla-b2g/gaia/compare/aa125bd4f448c65c94fca678ead21f6e68d239fc...07ab0bb6a6b26f4b0a2aaafb0c725f20464440de Bug 1015867, which was mentioned as a possible cause at comment 3 and 10, is in the pushlog.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Confirmation on your suspicion.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell) → needinfo?(felash)
Yes, it's the likely culprit, thanks a lot.
Blocks: 1015867
Flags: needinfo?(felash)
blocking-b2g: 2.0? → 2.0+
Depends on: 1033383
So, to any manager that looks at blockers progress, it's likely a dupe from bug 1027851 that's being worked on.
Depends on: 1027851
No longer depends on: 1033383
Should we test again on master since bug 1027851 was landed?
Flags: needinfo?(pcheng)
(In reply to Wesley Huang [:wesley_huang] from comment #15) > Should we test again on master since bug 1027851 was landed? Issue is not completely fixed on Today's Flame 2.1 master. Somewhere in 3rd page of composing an SMS, blurry texts start to appear as typing occurs. Those blurry texts would become clear by themselves a few seconds later. This blurry text issue doesn't happen continuously once it occurs. Another issue would follow after blurry text which is slowing down in displaying texts - if I spam a bunch of texts at once, it takes twice the time to display those texts. So texts would continue to appear even if I stop typing. Tested on: Device: Flame Build ID: 20140707054517 Gaia: 93daa354671a698634a3dc661c8c9dcb7d824c31 Gecko: 9b0206fad5f2 Version: 33.0a1 (Master) Firmware Version: v122 User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0
Flags: needinfo?(pcheng)
Hey Kartikaya, We still see blurry text + some lags in text painting (see comment 16) while typing in the SMS app, even after patches for bug 1027851 have been landed. Could you please help with this? Thanks!
Flags: needinfo?(bugmail.mozilla)
Can you provide a video of the issue?
Flags: needinfo?(bugmail.mozilla)
QA-Wanted: please get a video or NI: Pi Wei for the video - whomever gets to it first
QA Whiteboard: [QAnalyst-Triage+]
Flags: needinfo?(pcheng)
Keywords: qawanted
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #18) > Can you provide a video of the issue? Video provided: https://www.youtube.com/watch?v=-32ovBo7X9w At around 1:00 the blurry text issue starts to appear. At toward the end of the video when my fingers stop typing, it continues to display text due to slowness on displaying text in real time. Tested on: Device: Flame Build ID: 20140707060819 Gaia: 99f56d9db3cd37c684b01de6fed786421f47e2b7 Gecko: 085eea991bb9 Version: 33.0a1 (Master) Firmware Version: v122 User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pcheng) → needinfo?(jmitchell)
Keywords: qawanted
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
Thanks for the video. I can take a look at this.
Blocks: 993473
Component: Gaia::SMS → Panning and Zooming
Product: Firefox OS → Core
Version: unspecified → Trunk
Assignee: nobody → bugmail.mozilla
Seems like AboutToCheckerboard is returning true in some cases because the displayport doesn't cover the danger zone still. It might be that we're not updating the requested displayport from the APZC in response to changes in the size of the scrollable rect. I'll continue investigating.
Whoops, had an inverted condition there. Updated patch.
Attachment #8452357 - Attachment is obsolete: true
Attachment #8452375 - Flags: review?(tnikkel)
Attachment #8452358 - Flags: review?(tnikkel)
The change in part 2 should ensure that we don't get unnecessary repaints happening because if the margins are the same then the deduplication in RequestContentRepaint will prevent the repaint request from ever going out. Try push: https://tbpl.mozilla.org/?tree=Try&rev=62a5bf70264a
Attachment #8452362 - Attachment is obsolete: true
Attachment #8452378 - Flags: review?(botond)
Summary: [SMS] Error displaying long messages → [SMS] Long messages become blurry
Attachment #8452378 - Flags: review?(botond) → review+
Attachment #8452375 - Flags: review?(tnikkel) → review+
Attachment #8452358 - Flags: review?(tnikkel) → review+
The change to the isFirstPaint block was causing gtests to fail. After investigation I realized that we don't actually want that block at all. If it is a first paint, then we don't want to request a repaint because otherwise we might inadvertently set a displayport on a scrollinfo layer before we need to. The scrollable rect can't be "changing" in this scenario because it's the first paint and there is no previous scrollable rect to have changed.
Attachment #8452378 - Attachment is obsolete: true
Attachment #8452659 - Flags: review?(botond)
Comment on attachment 8452659 [details] [diff] [review] Part 3 - Ensure we trigger a repaint when the scrollable rect changes Review of attachment 8452659 [details] [diff] [review]: ----------------------------------------------------------------- Sounds reasonable.
Attachment #8452659 - Flags: review?(botond) → review+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: