1137718 - [Settings][RTL] Settings sometimes ends up in a wrong slide position

Status: RESOLVED WONTFIX

(Core :: Layout, defect, P2)

Description

[Julien Wajsberg [:julienw]]

Attachment: 2015-02-27-16-20-22.png

1. Set the phone to mirrored english language.
2. do some actions. I'm sorry I don't have a good STR.
3. enter the settings app again

=> The settings app looks like the panel is half slid (see attachment).

QAWanted to find a good STR.

Comment 1

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

I spent some time attempting to reproduce this issue without luck.  I did not have Mirrored English as an available language, but I used both Arabic and Mirrored Runtime instead.  This might have been my cause for no reproductions.  Leaving the qawanted tag so others can attempt to reproduce.

Environmental Variables:
Device: Flame 3.0
BuildID: 20150226184845
Gaia: 7512026a377271a0cade12d70846557f0bc7781c
Gecko: c7968255c1ea
Version: 39.0a1 (3.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0

Comment 2

[Brogan Zumwalt [Inactive]]

Found STR for issue in Flame 3.0

1) Change language to any RTL language in settings (Arabic works, as does Runtime Mirrored)
2) Do not back out of Language page in settings, just press home button
3) Open Gallery and select picture
4) Rotate device to landscape mode (this also works if user goes to browser and views page in landscape mode)
5) Press home button and launch settings from homescreen

Result: The languages page opens in settings where most of it is placed off screen


Device: Flame 3.0
Build ID: 20150227010229
Gaia: 7512026a377271a0cade12d70846557f0bc7781c
Gecko: c7968255c1ea
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 39.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0

Comment 3

[KTucker [:KTucker][Inactive 3/4/2016]]

Adding qawanted for branch checks.

Comment 4

[Brogan Zumwalt [Inactive]]

Issue DOES reproduce on Flame 2.2

Returning to Settings sub-page from a app viewed in landscape mode while using an RTL language causes page to be severely horizontally offset.

Device: Flame 2.2
Build ID: 20150227002521
Gaia: eb6a5ac9081d3962198e0f4520b0743d716d7a27
Gecko: c8a38dcfbebc
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 37.0 (2.2)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Comment 5

[Dylan Oliver [:doliver]]

triage: P3 for this particular set of STR. If there is a more direct way of triggering this we can reconsider. At least the back button is still visible and the app corrects itself when pressed.

Comment 6

[Lancy(Leave from Mozilla)]

Test case has been added in moztrap:
https://moztrap.mozilla.org/manage/case/15991/

Comment 8

[Pi Wei Cheng [:piwei] (inactive)]

Attachment: similar bug on 3.0 with blank settings page

I ran into this issue using similar STR as bug 1139076. The breakage now looks worse as it now displays a blank settings page:

1) Set system language to Arabic
2) Go to Settings > Keyboards > Built-in Keyboard (first option)
3) Hold the phone in landscape, and tap the back arrow button

Settings app becomes a blank app. See attached screenshot. This is on today's 3.0.

NI Delphine to re-triage since I think this issue is not as difficult to hit and it breaks Settings app.

Comment 9

[Delphine Lebédel [:delphine - Use needinfo]]

[Blocking Requested - why for this release]:

:piwei: I don't think that's the correct screenshot attached, is it? 
Since this is affecting 3.0 and breaks Settings, nominating for 3.0

Comment 10

[Pi Wei Cheng [:piwei] (inactive)]

Attachment: similar bug on 3.0 with blank settings page

Apologies on attaching the wrong screenshot. Fixing it now.

Comment 11

[Sue]

Attachment: video of Flame 3.0_verify.mp4

Hi William,
This issue can be reproduced on latest build of Flame 2.2, Nexus 5 2.2&3.0 by STRs in comment 2. And it can not be reproduced on Flame 3.0 by STR2 in comment 2. It will go to Settings view not Language view after step 5.
 
But this issue can be reproduced on Flame 2.2&3.0, Nexus 5 2.2&3.0 by STRs in comment 8. 
Result: The Keyboards view in Settings shifts towards right of screen, with only a small part can be seen.

I have uploaded the video of Flame 3.0, could you please have someone to help with this bug? Thanks :)
See attachment:video of Flame 3.0_verify.mp4

Device information:
Flame 2.2 Build ID: 20150527002504
Flame 3.0 Build ID: 20150527160204
Nexus5 2.2 Build ID: 20150527002504
Nexus5 3.0 Build ID: 20150527160204

Comment 12

[William Hsu [:whsu]]

Hi, Pi-Wei,

I would like to use another bug to trace issue of comment 8, and use present bug to trace issue of comment 0. ( Note: We can create a new bug or reopen Bug 1139076.)

What do you think?
Many thanks.

Comment 13

[Pi Wei Cheng [:piwei] (inactive)]

After further testing I discovered that the blank settings issue doesn't occur every time. It seems to only start to occur after the 2nd attempt. First attempt shows what comment 0 shows. I think it's the same bug because it can be reproduced using exact same steps. I can also reproduce comment 2 on Flame 3.0.

Comment 0 doesn't have an STR. Comment 2 and comment 8 provided STRs that will run into this issue. If you think one STR = one bug, regardless of results, then I'm fine writing a new one. Otherwise I think they're of the same cause.

Comment 14

[William Hsu [:whsu]]

(In reply to Pi Wei Cheng [:piwei] from comment #13)
> After further testing I discovered that the blank settings issue doesn't
> occur every time. It seems to only start to occur after the 2nd attempt.
> First attempt shows what comment 0 shows. I think it's the same bug because
> it can be reproduced using exact same steps. I can also reproduce comment 2
> on Flame 3.0.
> 
> Comment 0 doesn't have an STR. Comment 2 and comment 8 provided STRs that
> will run into this issue. If you think one STR = one bug, regardless of
> results, then I'm fine writing a new one. Otherwise I think they're of the
> same cause.


Sorry for the late reply.

Oh~! I see.
After I used device to compare the test steps and results by myself, I understand what you meant.
Yep. Comment 2 and comment 8 provided STRs that run into the same issue.

Comment 15

[Mahendra Potharaju [:mahe]]

Based on clear STR, blocking this.

Comment 16

[Ken Chang[:kenkai]]

Tim, Can anyone in your team take this bug?

Comment 17

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Taking since Fred is fully loaded....

Comment 18

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Mahendra Potharaju [:mahe] from comment #15)
> Based on clear STR, blocking this.

:mahe, could you tell me which STR is this bug really blocking? I cannot reproduce comment 8 nor comment 2.

The built-in keyboard option actually launches the settings page of the keyboard app; changing the sliding direction of that has nothing to do with Settings app. Please produce an STR from other panels.

Comment 19

[Mahendra Potharaju [:mahe]]

Tim, I tried to reproduce with steps in Comment 8. As mentioned in Comment 13, we do not get a blank screen. But I encountered a frozen settings app. 

After you select the first option in Keyboard, turn the phone to Landscape mode before the next options are presented. The settings app is frozen till you turn it to portrait mode. It could be a little hard to reproduce if you do not turn the phone at the right time i.e. after the options are presented.

Comment 20

[Pi Wei Cheng [:piwei] (inactive)]

> The built-in keyboard option actually launches the settings page of the keyboard app;
> changing the sliding direction of that has nothing to do with Settings app.

I don't understand this comment. No one is asking to change the sliding direction of Settings app.

-----

I tried the STRs again on today's Aries build. Comment 2 doesn't seem to repro the bug anymore. Comment 8 seems to behave a little differently now. For reference on original bug behavior please check the video at comment 11. In the video after 1 minute is the demonstration of comment 8.

Now there are other bugs existing that seem to prevent us from encountering the original bug. Turning phone to landscape in built-in keyboard page causes the page to display everything enlarged and touch events are not recognized in this state. This behavior was not there before. The touch event not recognizing bug seems similar to bug 1194547. The text enlarged bug I'm unsure of.

In short, please look at the video at comment 11 starting from 1 minute of the video shows the bug. On current master we might be blocked by other bugs when doing the STR, but the bug is still there if you try more times as comment 19 states.

Comment 21

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Thanks :mahe and :piwei, I assume this bug is blocked on STR going back from Keyboard Settings app that could produce screenshot on comment 0. Going to try that right now.

Comment 22

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Attachment: misplaced-body-before-utility-tray.png

I can now reproduce this issue, but it is very tricky.

0. On latest Flame-KK eng build (see below)
1. Go to Settings > Languages, select Arabic
2. Go to Settings > Keyboards
3. Rotate the phone horizontally and tap "Built-in Keyboard" to go to the keyboard app settings. 
(4. You might encounter bug 1194547 comment 12 at this point, if so, rotate the phone back, tap back, and try again from 3)
5. Keeping the phone horizontal, and tap back.

Expected:

1. Settings app rotates the phone back vertically and it is being layout correctly.

Actual:

1. Elements are misplaced (therefore, not responsive to tap) but the screen is not updated, the header contain a white space. See the first screenshoot ("misplaced-body-before-utility-tray.png")

Note:

1. Attempt to refrash the rendering by pulling down the utility tray and up will reach what this bug reproduces ("misplaced-body-after-utility-tray.png").
2. Inspecting with WebIDE I can verify the after-utility-tray screenshot is reflecting the actual (misplaced) positions of DOM; the body element is misplaced about 4/5 of the screen width while no instruction in styling asking it to.


My educated guess is that this is some races between screen rotation and layout and processes. This is not what Gaia could or should fix.

===

Reproducible build:

Build ID               20150818150207
Gaia Revision          507ba38fb64b27f87d11f4104dfcc58448e12b1a
Gaia Date              2015-08-18 10:50:12
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/2c272af993c23e803f6ea7798a812b0c8abfad4d
Gecko Version          43.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  39
Firmware Date          Thu Oct 16 18:19:14 CST 2014
Bootloader             L1TC00011880

Comment 23

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Attachment: misplaced-body-after-utility-tray.png

Comment 24

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Attachment: misplaced-body-after-sleep-menu.png

Another proof of the invalidation/rendering issue by trying to long press the power button to invoke the sleep menu and dismiss it.

Comment 25

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Tim Guan-tin Chien [:timdream] (slow response; please ni? to queue) from comment #22)
> My educated guess is that this is some races between screen rotation and
> layout and processes. This is not what Gaia could or should fix.

I am moving this to Core::Layout. I am also moving this back from 2.5+ to 2.5?, given the STR in comment 22 is pretty hard to accidentally invoke.

Comment 26

[Tim Guan-tin Chien [:timdream] (please needinfo)]

... and I am not capable of fixing a layout bug. Happy to learn with a mentor if this is not hard to fix though.

Comment 27

[Mahendra Potharaju [:mahe]]

Blocking for 2.5, as Arabic language is a big user base

Comment 28

[No-Jun Park [:njpark]]

I can't seem to repro the STR from Comment 22 (on 512MB Flame) - it seems the bug is now resolved.  Adding qawanted for check.

Comment 29

[Pi Wei Cheng [:piwei] (inactive)]

Following steps at comment 8, this issue is reproducible on Flame 2.5 and Flame 2.2. Aries doesn't seem to exhibit this issue though. This appears to be somehow memory related because I can't repro the bug on Flame 2.5 with 512MB memory.

Issue reproducible on:
Device: Flame 2.5 (319MB)
BuildID: 20151016030225
Gaia: 8ea9029190af2ffeb04dcd97b323738125e31a0e
Gecko: d374d16cbb251c9dac5af69f8e186e821ce82fe2
Gonk: c4779d6da0f85894b1f78f0351b43f2949e8decd
Version: 44.0a1 (2.5) 
Firmware Version: v18Dv4
User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0

Device: Flame 2.2 (319MB)
BuildID: 20151016032501
Gaia: 885647d92208fb67574ced44004ab2f29d23cb45
Gecko: 9b9aad4197d9
Gonk: bd9cb3af2a0354577a6903917bc826489050b40d
Version: 37.0 (2.2) 
Firmware Version: v18Dv4
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Issue not reproducible on:
Device: Flame 2.5 (512MB)
BuildID: 20151016030225
Gaia: 8ea9029190af2ffeb04dcd97b323738125e31a0e
Gecko: d374d16cbb251c9dac5af69f8e186e821ce82fe2
Gonk: c4779d6da0f85894b1f78f0351b43f2949e8decd
Version: 44.0a1 (2.5) 
Firmware Version: v18Dv4
User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0

Device: Aries 2.5
BuildID: 20151016122951
Gaia: 8999f0ba6326d815c8366e3c1155b7e4e9763b40
Gecko: ccf288f658211b6cfab33c458aaf033baed2375b
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 44.0a1 (2.5) 
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0

Comment 30

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

No-Jun this issue still occurs but is 319MB only.  I believe the decision was to make 319MB only issues no longer blockers.

Comment 31

[No-Jun Park [:njpark]]

Yeah, I agree.  I'll un-nom it, and ping :mahe for confirmation.  This issue is memory related, and it should not be a blocker since it doesn't occur in 512.

Comment 32

[Julien Wajsberg [:julienw]]

I'd say comment 8's STR happens because the Settings app is killed (the Keyboard settings is in the Keyboard app), so this makes sense.
It also means it's a totally different bug than the one I filed originally. I was not talking about a blank page, but having the setting panel in a halfway position (not really "half", but you got me). As seen in attachment 8570507 [details].

Can we check if this still happens? Also check comment 2 for a STR.

Comment 33

[Mahendra Potharaju [:mahe]]

Would like to wait for the result from QAnalysts and then comment on unblocking for 2.5 release. 

Thanks

Comment 34

[Pi Wei Cheng [:piwei] (inactive)]

Doing the exact same set of STR (comment 8) results in comment 0 screenshot on Flame 2.2. On Flame 2.5, attachment 8606469 [details] occurs on first attempt, and second attempt shows the weird slide position (attachment 8570507 [details]). It is the same bug.

Comment 2 STR does NOT repro the bug on Flame 2.5 because the Settings app is killed in the background as soon as user goes to Home (see bug 1172167 and all the related bugs in there). However comment 2 STR still repro's the bug on Flame 2.2, as does comment 8 STR.

In short: Comment 8 reproduces this bug on both Flame 2.5 and 2.2. Comment 2 can only be fully executed on Flame 2.2 and it also reproduces the bug.

Comment 35

[Pi Wei Cheng [:piwei] (inactive)]

I realized I was on an older 2.5 build when doing comment 34. With today's build I can no longer repro the bug exactly as it is (attachment 8570507 [details]) using comment 8 steps nor comment 2 steps. Comment 8 steps now always leads to a blank page like shown in attachment 8606469 [details] when bug happens. Comment 2 simply cannot be done in 319MB.

Comment 36

[Julien Wajsberg [:julienw]]

>  Comment 2 simply cannot be done in 319MB.

But in that case maybe we can do it in 512MB ?

The bug here is not something related to the available memory but rather some transition that does not work properly.

Comment 37

[Pi Wei Cheng [:piwei] (inactive)]

(In reply to Julien Wajsberg [:julienw] from comment #36)
> >  Comment 2 simply cannot be done in 319MB.
> 
> But in that case maybe we can do it in 512MB ?
> 
> The bug here is not something related to the available memory but rather
> some transition that does not work properly.

I didn't think it's related to memory either, but tests show it's somehow memory related. Unless you can come up with another set of steps that repros in current master.

I tested comment 2 in 512MB and could not reproduce the bug. Repro rate is 0 out of 3.

Device: Flame 2.5 (512MB mem)
BuildID: 20151021064220
Gaia: 32d827a70af90a05918f234e5b16b35d5d2a07e8
Gecko: 473aefe5bd85842eeb142e0cde8e2cd21edbf40b
Gonk: c4779d6da0f85894b1f78f0351b43f2949e8decd
Version: 44.0a1 (2.5) 
Firmware Version: v18Dv4
User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0

Comment 38

[Julien Wajsberg [:julienw]]

Then it means the original bug has somehow been fixed. Good !

The STR you have in comment 8 is _definitely_ related to memory, but it's a totally different issue (the issue is that Built-in Keyboard settings are actually loading a different app -- and as a result the Settings app can be killed, as I said in comment 32).

I'd suggest to file a separate bug for STR from comment 8, and close this bug as WFM.

Comment 39

[Pi Wei Cheng [:piwei] (inactive)]

This bug is still open in Flame 2.2 though. Comment 2 and comment 8 both reproduce on Flame 2.2 319.

Comment 40

[Julien Wajsberg [:julienw]]

Right, but we don't do any work on 2.2 now :/