Closed Bug 1122324 Opened 10 years ago Closed 10 years ago

[Homescreen]Zooming the browser can result in a zoomed in home screen

Categories

(Firefox OS Graveyard :: Gaia::System::Window Mgmt, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:2.2+, b2g-v2.1 unaffected, b2g-v2.2 verified, b2g-master verified)

VERIFIED FIXED
blocking-b2g 2.2+
Tracking Status
b2g-v2.1 --- unaffected
b2g-v2.2 --- verified
b2g-master --- verified

People

(Reporter: JMercado, Assigned: etienne)

References

()

Details

(Keywords: regression, Whiteboard: [systemsfe])

Attachments

(1 file)

Attached file Home screen logcat
Description: The home screen can become zoomed, leaving only a few icons on screen. This was caused by zooming in the browser in a low performance situation but could potentially occur with other applications that allow zooming and have low performance. Prerequsites: 1) Be connected to a network Repro Steps: 1) Update a Flame to 20150115051932 2) Open the browser in landscape mode 3) Search for anything 4) When the page loads repeatedly zoom in and out to reduce browser performance 5) When performance is extremely low (longer than a second to finish zooming) zoom in as much as possible 6) Press the home button before the zoom properly loads Note: This issue was not able to be reproduced in portrait mode. Actual: The home screen is zoomed and the user cannot scroll the screen. Expected: The home screen does not zoom in. Environmental Variables: Device: Flame 3.0 Build ID: 20150115051932 Gaia: ebc90190771a945d405f5d36efd813db6f77f965 Gecko: 206bf1a98cd7 Version: 38.0a1 (3.0) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0 Repro frequency: 6/10 See attached: logcat, video This issue will also occur on Flame KK 2.2. Environmental Variables: Device: Flame 2.2 BuildID: 20150115002505 Gaia: 7c5b27cad370db377b18a742d3f3fdb0070e899f Gecko: ce27f2692382 Version: 37.0a2 (2.2) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0 This issue did NOT reproduce on Flame 2.1 KK as the performance did not drop as much when zooming or doing other browser activites. Environmental Variables: Device: Flame 2.1 BuildID: 20150115134102 Gaia: 89ed797ff6a93db3d5cf0d451069f44e99dd8288 Gecko: bacd744d5ac2 Version: 34.0 (2.1) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Botond, do you think this is APZ related?
Flags: needinfo?(botond)
Does the homescreen stay zoomed in or does it reset after a few sec? Hard to tell from the video.
Flags: needinfo?(jmercado)
The homescreen does not reset until the phone is restarted.
Flags: needinfo?(jmercado)
The end user should not have to restart their phone to recover the homescreen. Nominating 2.2?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
blocking-b2g: --- → 2.2?
FWIW I was unable to reproduce using the STR in comment 0. Specifically I never saw the zooming responsiveness go as low on my local device as it appeared to in the video, and hitting the home button always brought me back to the homescreen which looked as expected. It does look like an APZ bug but we might need to request logs from a custom build or something to debug this. Will wait to see to see if the regression window turns up anything first.
Component: Gaia::Homescreen → Panning and Zooming
Flags: needinfo?(botond)
Product: Firefox OS → Core
QA Contact: ychung
blocking-b2g: 2.2? → 2.2+
Depends on: 1122794
I recently spotted a mistake in my fix for bug 1076241, where APZ uses the wrong API to perform zooming in one place. The symptoms seen in this bug are consistent with that, and the offending code only is only called in certain cases ("before-first-paint gets called before RecvUpdateDimensions"), which may be consistent with it only happening in low-performance situations. I filed bug 1122794 to track the fix for this mistake.
I posted a patch in bug 1122794. If someone who's able to reproduce this issue could test with that patch applied to see if it fixes this problem, that would be superb!
Flags: needinfo?(jmercado)
b2g-inbound Regression Window: Last Working Environmental Variables: Device: Flame 2.2 BuildID: 20150106010241 Gaia: f2c5dcef558f747e525220f1dfb2da6b07325235 Gecko: 080bf51ff425 Version: 37.0a1 (2.2) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0 First Broken Environmental Variables: Device: Flame 2.2 BuildID: 20150106023745 Gaia: 9f400639489276a01eda2f7c1536b2429e98a247 Gecko: c6251e0f5230 Version: 37.0a1 (2.2) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0 Last Working Gaia First Broken Gecko: Issue NOT reproduce Gaia: f2c5dcef558f747e525220f1dfb2da6b07325235 Gecko: c6251e0f5230 First Broken Gaia Last Working Gecko: Issue DOES reproduce Gaia: 9f400639489276a01eda2f7c1536b2429e98a247 Gecko: 080bf51ff425 https://github.com/mozilla-b2g/gaia/compare/f2c5dcef558f747e525220f1dfb2da6b07325235...9f400639489276a01eda2f7c1536b2429e98a247 Possibly caused by bug 1114800
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
QA Contact: ychung
Bug 1114800 touches the app window which sounds like it might be a plausible cause of this bug. Moving back to Gaia.
Blocks: 1114800
Component: Panning and Zooming → Gaia::System::Window Mgmt
Product: Core → Firefox OS
Since this issue is not caused by bug 1076241 is the requested testing still worth doing? Also we aren't setup to do patching for patches that aren't on github.
Flags: needinfo?(jmercado) → needinfo?(botond)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
(In reply to Jayme Mercado [:JMercado] from comment #10) > Since this issue is not caused by bug 1076241 is the requested testing still > worth doing? Also we aren't setup to do patching for patches that aren't on > github. Since bug 1076241 isn't in the regression range, my hypothesis that it's the cause of this bug is probably wrong. As this bug doesn't seem trivial to reproduce, it's probably not worth retesting with the fix in bug 1122794.
Flags: needinfo?(botond)
Can we re-test this as in comment 11
Flags: needinfo?(jmercado)
Keywords: qawanted
Comment 11 says that the testing is NOT worth doing as that bug is not in the regression range.
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(jmercado) → needinfo?(ktucker)
Keywords: qawanted
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Etienne, Can you check this out? We think your patch may have affected this. Thanks!
Flags: needinfo?(etienne)
Assignee: nobody → etienne
I'm pretty sure the patch from bug 1120704 fixes this.
Flags: needinfo?(etienne)
Can we verify that bug 1120704 fixed the issue?
Keywords: qawanted
I could not reproduce this issue on either Flame 3.0 or Flame 2.2 after 20 attempts each. Results: The browser did not slow as much during zooms and the home screen was not zoomed in after pressing the home button during the very brief slow downs. Environmental Variables: Device: Flame 3.0 BuildID: 20150205054817 Gaia: 6afe4606da768aed62d8a200fd24e6a7fa52dc4b Gecko: 58ce6051edf5 Version: 38.0a1 (3.0) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0 Environmental Variables: Device: Flame 2.2 BuildID: 20150205130826 Gaia: a52999ce7f783177deb17e267bf003a53e6fde06 Gecko: 01446d5231ef Version: 37.0a2 (2.2) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Keywords: qawanted
Status: NEW → RESOLVED
Closed: 10 years ago
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: