[Homescreen] After taking screenshot on landscape mode in an app, homescreen displays in cramped area

RESOLVED WORKSFORME

Status

Firefox OS
Gaia::System::Window Mgmt
RESOLVED WORKSFORME
4 years ago
4 years ago

People

(Reporter: njpark, Assigned: gerard)

Tracking

({regression})

unspecified
2.1 S4 (12sep)
ARM
Gonk (Firefox OS)
regression
Dependency tree / graph

Firefox Tracking Flags

(blocking-b2g:2.1+, b2g-v1.4 unaffected, b2g-v2.0 unaffected, b2g-v2.1 unaffected, b2g-v2.2 unaffected)

Details

(Whiteboard: [systemsfe])

Attachments

(3 attachments)

(Reporter)

Description

4 years ago
Created attachment 8460431 [details]
2014-07-22-15-39-20.png

STR:
Note, this has low repro rate (2/10)
- Take video with the phone
- go to the video app, and during the playback, do a lot of orientation switch, while also doing pause, replay, and REW/FF.
- Press home button to go to main menu
Expected:
Homescreen displays normally
Actual:
Homescreen is displayed in reduced resolution

Version Info:
Gaia      e423c3be8d19c9a8a5ae2571f499c36dc6b0df89
Gecko     https://hg.mozilla.org/mozilla-central/rev/6f702709fab6
BuildID   20140722040212
Version   34.0a1
ro.build.version.incremental=eng.tclxa.20131223.163538
ro.build.date=Mon Dec 23 16:36:04 CST 2013

Updated

4 years ago
Keywords: steps-wanted
(Reporter)

Comment 1

4 years ago
Sotaro suggested it is viewport related bug, cc'ing milan and kats for possible clues.
It may very well be on the APZ side, but let's get a regression range if possible to narrow it down.
This looks like bug 1041888. The reporter marked it as WORKSFORME but the contractors found a regression window. No-Jun, do you confirm that it's the same issue?
Flags: needinfo?(npark)
None of the changes in that regression window should have any impact on B2G. More likely the issue is intermittent and they ended up with the wrong window.
(Reporter)

Comment 5

4 years ago
(In reply to Johan Lorenzo [:jlorenzo] from comment #3)
> This looks like bug 1041888. The reporter marked it as WORKSFORME but the
> contractors found a regression window. No-Jun, do you confirm that it's the
> same issue?
that is same thing i see, but except that i was on landscape mode on browser for a few minutes before going back to the homescreen.  Will investigate more.
Flags: needinfo?(npark)
(Reporter)

Comment 6

4 years ago
(In reply to No-Jun Park [:njpark] from comment #5)
> (In reply to Johan Lorenzo [:jlorenzo] from comment #3)
> > This looks like bug 1041888. The reporter marked it as WORKSFORME but the
> > contractors found a regression window. No-Jun, do you confirm that it's the
> > same issue?
> that is same thing i see, but except that i was on landscape mode on browser
> for a few minutes before going back to the homescreen.  Will investigate
> more.

What i meant was, i also see the bug when I run browser in landscape mode and exit after a while.  But yes, Bug 1041888 is what i originally saw as well.  sorry for the confusion.
(Reporter)

Comment 7

4 years ago
So I think I found the reliable way to repro this:
- Open a browser, go to a site (http:/mozilla.org/firefoxos), wait until the site loads completely.
- Change to landscape mode, scroll up/down a bit, and take screenshot using power + volDown key combo
- (important) leave it for minimum 5 minutes.  The display blackout is turned off.
- While in landscape mode, press home button to go to homescreen.

Expected:
Normal homescreen view.
Actual:
cramped homescreen view.

Will see whether this happens in 2.0
Summary: [Homescreen] After a lot of video orientation change, displays in cramped area → [Homescreen] After taking screenshot on landscape mode in an app, homescreen displays in cramped area
(Reporter)

Comment 8

4 years ago
I cannot reproduce this in 2.0.  2.0 seems more responsive when returning to homescreen as well.
Okay - sounds like we've proven it's a regression. Do you think this is worth blocking on for 2.1?
Flags: needinfo?(npark)
Keywords: steps-wanted → regression
(In reply to Jason Smith [:jsmith] from comment #9)
> Okay - sounds like we've proven it's a regression. Do you think this is
> worth blocking on for 2.1?

Also - removing steps-wanted due to comment 7.
(Reporter)

Comment 11

4 years ago
(In reply to Jason Smith [:jsmith] from comment #9)
> Okay - sounds like we've proven it's a regression. Do you think this is
> worth blocking on for 2.1?

I think it's worth blocking, since this bug may manifest in several different scenarios, what I have done could be one of many ways to summon this bug.
Flags: needinfo?(npark)
(Reporter)

Comment 12

4 years ago
[Blocking Requested - why for this release]:
blocking-b2g: --- → 2.1?

Updated

4 years ago
Keywords: regressionwindow-wanted
I'm unable to reproduce the issue in those exact steps at comment 7 in today's 2.1 master on Flame.

What I did:

Prerequisite: Display timeout is set to Never in Settings, and connected to WiFi

1) Go to http://mozilla.org/firefoxos in Browser app
2) Change to landscape orientation, scroll down and up
3) Take a screenshot using power + vol down buttons
4) Leave the phone sitting on the firefox website in Landscape for 6 minutes
5) Press Home button

I observed: Homescreen remains intact for all 3 attempts.

Tested on:
Device: Flame (512MB mem)
Build ID: 20140723070705
Gaia: 01d86c8cc615658694b114ca5711763efc4ef205
Gecko: 717cd9d89a80
Version: 34.0a1 (Master)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Removing window-wanted tag until we figure out reproducible STR.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: regressionwindow-wanted
No-Jun - can you review comment 13; have you seen this issue on the latest?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell) → needinfo?(npark)
(Reporter)

Comment 15

4 years ago
y(In reply to Joshua Mitchell [:Joshua_M] from comment #14)
> No-Jun - can you review comment 13; have you seen this issue on the latest?

I just retried, and it still happens to me, on build 20140723160203 on pvt nightly.  
Pi Wei- could you try one more thing?  could you leave the device for 30 minutes instead of 6?  I noticed longer i leave it, it is more likely to come back.
Flags: needinfo?(npark) → needinfo?(pcheng)
(Reporter)

Comment 16

4 years ago
Just tried a few more times, and this happens much less frequently on the latest build.  I was able to reproduce only 1 instance.  Will add details if I find more information.
Flags: needinfo?(pcheng)
(Reporter)

Comment 17

4 years ago
This sounds crazy, but I was able to reproduce the bug when
- Follow the steps in Comment 7 while:
  the phone is connected to USB and adb debug is enabled (as a default in eng build)
  leave the phone connected to USB for 10+ minutes
  Matter of fact, this is NOT reproducible at all if the phone is not connected to adb.

Pi Wei, could you please try this one more time with the usb connected?
Flags: needinfo?(pcheng)
Blocks: 1017954
QA Whiteboard: [QAnalyst-Triage+] → [VH-FL-blocking-][VH-FC-blocking-][QAnalyst-Triage+]
Whiteboard: [systemsfe]
(Reporter)

Comment 18

4 years ago
Created attachment 8461635 [details]
logcat

Not sure whether this will help, but this is the logcat between the time after the phone was in landscape in browser, and home button is pressed approx. 10 min after and shows cramped screen.
(In reply to No-Jun Park [:njpark] from comment #17)
> This sounds crazy, but I was able to reproduce the bug when
> - Follow the steps in Comment 7 while:
>   the phone is connected to USB and adb debug is enabled (as a default in
> eng build)
>   leave the phone connected to USB for 10+ minutes
>   Matter of fact, this is NOT reproducible at all if the phone is not
> connected to adb.
> 
> Pi Wei, could you please try this one more time with the usb connected?

I have adb debugging enabled (ADB only), device connected to USB the whole time, redid the steps at comment 13, and this time I left the phone sitting there for 15 minutes, but still no repro. Homescreen shows as expected.

Tested on:
Device: Flame (512MB mem)
Build ID: 20140724040112
Gaia: c72257b2d27135bfcd68e89dd584182797784016
Gecko: 06ac51c2b8a8
Version: 34.0a1 (Master)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
Flags: needinfo?(pcheng)

Updated

4 years ago
Duplicate of this bug: 1043380
No-Jun - Can you work on nailing down STR here? We appear to be having trouble reproducing this issue.
Flags: needinfo?(npark)
(Reporter)

Comment 22

4 years ago
I investigated a bit more, and simplified the STR.  It looks to me that some kind of race condition is causing this.

1. Connect device via USB
2. Open a browser, go to a site (http:/mozilla.org/firefoxos), wait until the site loads completely.
3. Scroll down a bit
4. Change to landscape mode, scroll up/down a bit
5. press home button to go back to the homescreen
6. Press browser icon to go back to the browser
7. scroll down a bit
8. then quickly double or triple tap home button 
9. once in the homescreen, quickly double or triple tap the browser icon
10. repeat 8 and 9 for about 10+ times.  do the app switching really fast

One of three things happen with about 50% repro rate:
- Once in the browser, the browser content is displayed in shrunken real estate (zoomed out) and remains there (most common)
- The homescreen displays in cramped area (less common, still happens)
- The touch activate wrong region in the screen. (i.e. when browser icon is tapped, the game icon is activated) (1/10 times this happens)
Flags: needinfo?(npark)
(Reporter)

Comment 23

4 years ago
Created attachment 8462730 [details]
screenerror.log

This logcat records the session where above scenario was attempted.  initially the web browser display starts to shrink, then finally the homescreen size was reduced as well.
(Reporter)

Comment 24

4 years ago
note: adb cable is no longer need to be connected.
for step 10, as soon as the browser icon is tapped, double tap home button immediately.  as soon as the browser icon is visible, tap it immediately.  In my case, the first two symptoms i listed in comment 22 happens almost 100% within 2-3 minutes of repeating.  If I'm lucky, it happens immediately.

Updated

4 years ago
QA Whiteboard: [VH-FL-blocking-][VH-FC-blocking-][QAnalyst-Triage+] → [VH-FL-blocking-][VH-FC-blocking-]
Keywords: regressionwindow-wanted

Updated

4 years ago
QA Contact: ddixon
I was able to get this after using the Jewels app.

1. install the Jewels app from the marketplace
2. launch Jewels app
3. hit the home button
4. launch another app
5. use edge gesture to swipe to the Jewels app.
6. tap home button to see homescreen.

Gaia      3a06aa58245eaf848242d6d1497c1af536fffabd
Gecko     https://hg.mozilla.org/mozilla-central/rev/6c0971104909
BuildID   20140725040205
Version   34.0a1
ro.build.version.incremental=110
ro.build.date=Fri Jun 27 15:57:58 CST 2014
B1TC00011230
Flame
status-b2g-v2.1: --- → affected
status-b2g-v2.0: --- → unaffected
I wasn't able to reproduce this on 2.0 with the Open C.
B2G Inbound Regression Window

Last Working

Environmental Variables:
Device: Flame Master
Build ID: 20140711071412
Gaia: 76d9c1c1d1e56fcecd0b01ba604587cf73cb66aa
Gecko: f87018e3d067
Version: 33.0a1 (Master)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

First Broken 

Environmental Variables:
Device: Flame Master
Build ID: 20140711071921
Gaia: 5b33a1e4c82d57369ec6812177e477e308d538ce
Gecko: 07618025b80d
Version: 33.0a1 (Master)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

Last Working Gaia and First Broken Gecko
Issue DOES NOT occur here. 
Gaia: 76d9c1c1d1e56fcecd0b01ba604587cf73cb66aa
Gecko: 07618025b80d

Last Working Gecko and First Borken Gaia
Issue DOES occur here. 
Gaia: 5b33a1e4c82d57369ec6812177e477e308d538ce
Gecko: f87018e3d067

Gaia Pushlog: 
https://github.com/mozilla-b2g/gaia/compare/76d9c1c1d1e56fcecd0b01ba604587cf73cb66aa...5b33a1e4c82d57369ec6812177e477e308d538ce

Possible Causes:

Bug 1033364 - Support mozbrowsermetachange event in app_window.js. r=… 

Bug 1033364 - Change window layout to accomodate custom app color for… 

Bug 1035073 - Can not scroll the notifications area.
QA Whiteboard: [VH-FL-blocking-][VH-FC-blocking-] → [VH-FL-blocking-][VH-FC-blocking-][QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: regressionwindow-wanted
Vivien - this pushlog has a few probable causes, that are your work - can you take a look?
QA Whiteboard: [VH-FL-blocking-][VH-FC-blocking-][QAnalyst-Triage?] → [VH-FL-blocking-][VH-FC-blocking-][QAnalyst-Triage+]
Flags: needinfo?(jmitchell) → needinfo?(21)
blocking-b2g: 2.1? → 2.1+
Component: Gaia::Homescreen → Gaia::System::Window Mgmt

Updated

4 years ago
Duplicate of this bug: 1046504

Updated

4 years ago
QA Whiteboard: [VH-FL-blocking-][VH-FC-blocking-][QAnalyst-Triage+] → [VH-FL-blocking-][VH-FC-blocking-][QAnalyst-Triage+][lead-review+]
Does it still happens ?
Flags: needinfo?(21)
Keywords: qawanted
It still happens on my build from yesterday.
Flags: needinfo?(21)
Keywords: qawanted
I just saw this once on recent master while following the STR in bug 1042959 comment 0 and comment 7. Wasn't able to reproduce after multiple attempts though.
hmm. OK I have been able to reproduce it but not easily. I'm pretty sure this is a kind of weird state in the window manager.

Looking at logcat I see:

I/Gecko   ( 7977): Gecko bug: Async animation of pseudoelements not supported.  See bug 771367 (AnimationsOfAfterProperty) [div]
E/GeckoConsole( 7684): [JavaScript Warning: "Error in parsing value for 'width'.  Declaration dropped." {file: "app://system.gaiamobile.org/index.html" line: 0 column: 0 source: "undefinedpx"}]
E/GeckoConsole( 7684): [JavaScript Warning: "Error in parsing value for 'height'.  Declaration dropped." {file: "app://system.gaiamobile.org/index.html" line: 0 column: 0 source: "undefinedpx"}]

And then an infinite loop of 
I/Gecko   ( 7977): Gecko bug: Async animation of pseudoelements not supported.  See bug 771367 (AnimationsOfAfterProperty) [div]


So it seems like we fail to set up the correct sizing information in the window manager and we ends up with undefined. Since iframe does not like to not be sized they end up with this weird size.
Flags: needinfo?(21)
(In reply to Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please) from comment #33)
> hmm. OK I have been able to reproduce it but not easily. I'm pretty sure
> this is a kind of weird state in the window manager.
> 
> Looking at logcat I see:
> 
> I/Gecko   ( 7977): Gecko bug: Async animation of pseudoelements not
> supported.  See bug 771367 (AnimationsOfAfterProperty) [div]
> E/GeckoConsole( 7684): [JavaScript Warning: "Error in parsing value for
> 'width'.  Declaration dropped." {file:
> "app://system.gaiamobile.org/index.html" line: 0 column: 0 source:
> "undefinedpx"}]
> E/GeckoConsole( 7684): [JavaScript Warning: "Error in parsing value for
> 'height'.  Declaration dropped." {file:
> "app://system.gaiamobile.org/index.html" line: 0 column: 0 source:
> "undefinedpx"}]
> 
> And then an infinite loop of 
> I/Gecko   ( 7977): Gecko bug: Async animation of pseudoelements not
> supported.  See bug 771367 (AnimationsOfAfterProperty) [div]
> 
> 
> So it seems like we fail to set up the correct sizing information in the
> window manager and we ends up with undefined. Since iframe does not like to
> not be sized they end up with this weird size.

I'm not seeing constantly the Async animation messages but appears all the time when the issue is visible:
E/GeckoConsole(14530): [JavaScript Warning: "Error in parsing value for 'width'.  Declaration dropped." {file: "app://system.gaiamobile.org/index.html" line: 0 column: 0 source: "undefinedpx"}]
E/GeckoConsole(14530): [JavaScript Warning: "Error in parsing value for 'height'.  Declaration dropped." {file: "app://system.gaiamobile.org/index.html" line: 0 column: 0 source: "undefinedpx"}]
Seems like this is not related to the system app. We have this sizing message but if I had a outline: 5px solid red; outline-offset: -5px| rule on the iframe directly, it is drawn with the right dimensions.

Looking at the homescreen dimensions...
Homescreen dimensions:
 - Normal
  * width: 320
  * height: 569

 - Buggy
  * width: 569
  * height: 1013

So it seems like the homescreen still think it is in landscape mode...
It reminds me an old bug that has been workaround when the APZ has been introduced back in january.
Do you have reliable STR? If you do, and you think it's a platform issue (which is quite possible) then I can look into this.

Also you might want to try the patch on bug 1042959 to see if it helps.
QAWANTED - can we find out if this occurs on 1.4?
Keywords: qawanted

Comment 39

4 years ago
(In reply to Wayne Chang [:wchang] from comment #38)
> QAWANTED - can we find out if this occurs on 1.4?

Yes,but I could reproduce it in video easily but not homescreen.The step is:
  
  1.open video app and begin to scan videos.
  2.rotate screen counterclockwise or clockwise every two seconds.
I was unable to reproduce this issue on Flame 1.4 build.

The STR I used: 
1. Open Video App and play a video that's at least 30 second long, in landscape. 
2. Tap Home button while video is playing. 

Repro Attempts: 0/30

Environmental Variables: 
Device: Flame 1.4
Build ID: 20140818062816
Gaia: 21bec64497dc06a7f12071d573570ba8fea598ae
Gecko: 07d78d0f9bef
Version: 30.0 (1.4)
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0
QA Whiteboard: [VH-FL-blocking-][VH-FC-blocking-][QAnalyst-Triage+][lead-review+] → [VH-FL-blocking-][VH-FC-blocking-][QAnalyst-Triage?][lead-review+]
status-b2g-v1.4: --- → unaffected
Flags: needinfo?(jmitchell)
Keywords: qawanted
QA Whiteboard: [VH-FL-blocking-][VH-FC-blocking-][QAnalyst-Triage?][lead-review+] → [VH-FL-blocking-][VH-FC-blocking-][QAnalyst-Triage+][lead-review+]
Flags: needinfo?(jmitchell)
(In reply to Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please) from comment #35)
> Seems like this is not related to the system app. We have this sizing
> message but if I had a outline: 5px solid red; outline-offset: -5px| rule on
> the iframe directly, it is drawn with the right dimensions.
> 
> Looking at the homescreen dimensions...

I'd seen this in different bugs(dupe) but had no reliable STR.

And what we saw in the log for width/height is nothing bad, which makes me think this is a gecko rendering issue...
Alex, can you take a look here?
Flags: needinfo?(lissyx+mozillians)
(Assignee)

Comment 43

4 years ago
Sure.
Assignee: nobody → lissyx+mozillians
Flags: needinfo?(lissyx+mozillians)
(Assignee)

Comment 44

4 years ago
There is a range provided in bug 1041888 comment 4, but it does not makes a lot of sense: according to QA, it would be a Gecko bug, but the pushlog [http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5b64c42742cd&tochange=8113cde4e947] does not show anything obviously related :(
(Assignee)

Comment 45

4 years ago
I have not been able to reproduce it on fresh build from today, following your STRs.
QA Wanted for a retest.
Keywords: qawanted
Target Milestone: --- → 2.1 S4 (12sep)
Unable to reproduce issue on the latest Flame Master build (512 MB).

Actual Results: Homescreen does not malfunction when it switches orientation. 

Repro attempts: 0/50

Environmental Variables:

Device: Flame Master (2.2)
Build ID: 20140905090738
Gaia: 0de5fcdc11a15abdf8d64f28bed2abb30041ea4d
Gecko: 0d962e459db5
Version: 35.0a1 (Master)
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0
QA Whiteboard: [VH-FL-blocking-][VH-FC-blocking-][QAnalyst-Triage+][lead-review+] → [VH-FL-blocking-][VH-FC-blocking-][QAnalyst-Triage?][lead-review+]
Flags: needinfo?(jmitchell)
Keywords: qawanted
QA Whiteboard: [VH-FL-blocking-][VH-FC-blocking-][QAnalyst-Triage?][lead-review+] → [VH-FL-blocking-][VH-FC-blocking-][QAnalyst-Triage+][lead-review+]
Flags: needinfo?(jmitchell)
QA Wanted - This needs to be retested on 2.1 as well.
QA Whiteboard: [VH-FL-blocking-][VH-FC-blocking-][QAnalyst-Triage+][lead-review+] → [VH-FL-blocking-][VH-FC-blocking-]
Keywords: qawanted
QA ping
Issue DOES NOT occur in latest Flame 2.1 build (v123 base image)

Repro Attempts: 0/30

Device: Flame 2.1
BuildID: 20140912123307
Gaia: d4de4123c678b198692af256254a26507e9c9a08
Gecko: 0807d8ab3e5a
Version: 34.0a2 (Master) 
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
-------------------------------------------------------------------
Issue DOES NOT occur in latest Flame 2.1 build (v165 base image)

Repro Attempts: 0/30

Device: Flame 2.1
BuildID: 20140912081053
Gaia: 59e5c2467b7b8219ed194a0d0a94c6ed59af95be
Gecko: b09d2857b74e
Version: 34.0a2 (Master) 
Firmware Version: v165
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
QA Whiteboard: [VH-FL-blocking-][VH-FC-blocking-] → [VH-FL-blocking-][VH-FC-blocking-][QAnalyst-Triage?]
status-b2g-v2.1: affected → unaffected
status-b2g-v2.2: --- → unaffected
Flags: needinfo?(jmitchell)
Keywords: qawanted
No-Jun - QA-Wanted and some others (comment 45) have not been able to repro in the latest. I would close this as WFM but this bug has been particularly problematic with intermittent repros - I'd feel safer passing this back to you to make sure you can not repro it anymore either.
QA Whiteboard: [VH-FL-blocking-][VH-FC-blocking-][QAnalyst-Triage?] → [VH-FL-blocking-][VH-FC-blocking-][QAnalyst-Triage+]
Flags: needinfo?(jmitchell) → needinfo?(npark)
(Reporter)

Comment 52

4 years ago
(In reply to Joshua Mitchell [:Joshua_M] from comment #51)
> No-Jun - QA-Wanted and some others (comment 45) have not been able to repro
> in the latest. I would close this as WFM but this bug has been particularly
> problematic with intermittent repros - I'd feel safer passing this back to
> you to make sure you can not repro it anymore either.

I was keeping an eye on this bug too since I saw the reports of non-repro.  After trying for a while, it looks that this bug is no longer reproducible for me as well, so I'll mark it resolved.  Thanks for the feedback.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Flags: needinfo?(npark)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.