Closed
Bug 1173224
Opened 9 years ago
Closed 9 years ago
Keyboard is huge / very, very big
Categories
(Core :: Widget, defect)
Tracking
()
Tracking | Status | |
---|---|---|
b2g-v2.2 | --- | unaffected |
b2g-master | --- | verified |
People
(Reporter: callahad, Assigned: kats)
References
Details
(Keywords: DevAdvocacy, dogfood, regression, Whiteboard: [spark])
Attachments
(1 file)
61.01 KB,
image/png
|
Details |
See attached screenshot. This is with the 3.0 dogfood OTA from today on an Aries device. The build used git commit 31ef8dee from 2015-06-08 14:48:40. I've seen the issue in both the Messages and Email apps. I haven't been able to use the phone enough to look for it in others.
Reporter | ||
Comment 1•9 years ago
|
||
[Blocking Requested - why for this release]: Can't use the phone without a usable keyboard.
blocking-b2g: --- → spark?
Comment 2•9 years ago
|
||
Harald (+cc) has experienced this as well.
blocking-b2g: spark? → spark+
Keywords: regression,
regressionwindow-wanted
Comment 3•9 years ago
|
||
The issue goes away when the screen is rotated once. Same happens though when you launch the app again.
Comment 5•9 years ago
|
||
Breaking my dogfood, I'm bisecting gaia using the range provided in bug 1173300 comment 0
Comment 6•9 years ago
|
||
(In reply to Alexandre LISSY :gerard-majax from comment #5) > Breaking my dogfood, I'm bisecting gaia using the range provided in bug > 1173300 comment 0 Inconclusive, so it's probably a Gecko issue ...
Comment 7•9 years ago
|
||
Long-pressing space bar, to make it disappear, often results in keyboard app crash
Comment 8•9 years ago
|
||
Gecko bisecting is promising, I'm seeing the issue reproduced and non reproduced ...
Comment 9•9 years ago
|
||
f412d3f7b62f353ce0942fa4a80d0e728fac7a05 is the first bad commit commit f412d3f7b62f353ce0942fa4a80d0e728fac7a05 Author: David Parks <davidp99@gmail.com> Date: Sun Jun 7 22:39:28 2015 -0700 Bug 1125325 - Make TabParent/TabChild UpdateDimensions messages aware of the display scale. r=kats When connecting a lowdpi external monitor on hidpi mac, TabChild gets an UpdateDimensions call, followed by a UIResolutionChanged call. After the UpdateDimensions call, the content process is in an incorrect state where it has the dimensions of the new display and scale of the old one. After the UIResolutionChanged message, the values are again consistent. In the interim, reflow resizes layers based on the incorrect (old) scale and subsequently uses those incorrect values when the new scale comes in. This patch normalizes the message parameters by dividing by scale (the result is what OS X calls point coordinates) so that this doesn't happen. :040000 040000 23222602bb7bab93033f7a9c6bba04bed34544a7 7bd807b957e7fb8ea669eb2447b09d794a05dceb M dom :040000 040000 75eb4d3a5df186070999ef7dab04042de0d81418 6b9b814e17c9a0b879544147627ddead98fff008 M layout
Comment 10•9 years ago
|
||
I'm not able to revert this :(
Updated•9 years ago
|
Component: Gaia::Keyboard → Widget
Product: Firefox OS → Core
Comment 11•9 years ago
|
||
Ok we also have to revert 21d8c54ac2efd18a9a699186802d201ee1e926a4 before otherwise we cannot revert f412d3f7b62f353ce0942fa4a80d0e728fac7a05
Assignee | ||
Comment 12•9 years ago
|
||
Does this happen on devices other than the aries? I don't have an aries so won't be able to debug it if that's the only device it happens on.
Assignee | ||
Updated•9 years ago
|
Keywords: regressionwindow-wanted
Updated•9 years ago
|
Whiteboard: [spark]
Assignee | ||
Comment 14•9 years ago
|
||
So I can't reproduce this on a flame running master. All the bugs so far report this happening on Aries only. I'm not seriously opposed to backing this out but I want to where we are drawing the line with respect to backing stuff out. Is Aries/spark a tier 1 platform? Are we expected to make sure it stays in good shape? If so, how can we do that, considering most people don't have Aries devices, and there doesn't appear to be any way to reproduce bugs like these?
Flags: needinfo?(bugmail.mozilla)
Comment 15•9 years ago
|
||
I did see this issue on the most recent Nightly Flame build, but the reproduction rate was significantly lower than on Aries. I only saw it on 1 out of 5 devices, and only in the email app. Environmental Variables: Device: Flame 3.0 Build ID: 20150609160220 Gaia: 31ef8deec7a04a988eb92309178b87cc0bde8220 Gecko: 8be8deb10e4f Gonk: 040bb1e9ac8a5b6dd756fdd696aa37a8868b5c67 Version: 41.0a1 (3.0) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0
Assignee | ||
Comment 16•9 years ago
|
||
Thanks. After a discussion with drs on IRC I think it's fair to back this out for now. I'll do the backout on inbound (when it reopens).
Assignee | ||
Comment 17•9 years ago
|
||
Landed the backout on inbound. https://hg.mozilla.org/integration/mozilla-inbound/rev/7e232a3c57ee
Updated•9 years ago
|
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Comment 18•9 years ago
|
||
On [1], I sent multiple SMS like in bug 1173300 or like in bug 1173167, and the keyboard keeps being at the right size. [1] Build ID 20150611041939 Gaia Revision d2f31eb85837aae6eca04d022d1f5b2023bc778c Gaia Date 2015-06-10 19:57:58 Gecko Revision https://hg.mozilla.org/mozilla-central/rev/bfd82015df48 Gecko Version 41.0a1 Device Name aries Firmware(Release) 4.4.2 Firmware(Incremental) eng.worker.20150605.140045 Firmware Date Fri Jun 5 14:00:54 UTC 2015 Bootloader s1
blocking-b2g: spark+ → 2.5+
Updated•9 years ago
|
Assignee: nobody → bugmail.mozilla
status-b2g-v2.5:
--- → verified
Target Milestone: --- → 2.2 S14 (12june)
Updated•9 years ago
|
status-b2g-v2.5:
verified → ---
Updated•9 years ago
|
Flags: needinfo?(davidp99)
You need to log in
before you can comment on or make changes to this bug.
Description
•