Closed Bug 817181 Opened 7 years ago Closed 7 years ago

[Settings] Panes are scrollable horizontally but they shouldn't be

Categories

(Firefox OS Graveyard :: Gaia::Settings, defect, P2)

defect

Tracking

(blocking-basecamp:+)

VERIFIED FIXED
blocking-basecamp +

People

(Reporter: ttaubert, Assigned: ttaubert)

References

Details

(Keywords: regression)

Attachments

(1 file)

STR:

1) Open the settings app.
2) Slide to the left (so that content to the right becomes visible)

Actual: The wifi section becomes visible.

Expected: The user shouldn't be able to scroll horizontally.

This needs to block, IMO.
This must be a recent regression. *sigh*
Tim, I can’t reproduce with Gecko 18 and the latest Gaia on my Otoro. Which version of Gecko are you using?
I am able to reproduce it in Unagi.
Please try the daily release build from:
https://releases.mozilla.com/b2g/
2012-12-02(recent few builds should be the same result, too)
(beta v18 gecko with master gaia)

Reproduction Steps:
1. Open the settings app
2. Click anything lead you to the new screen. For example, internet sharing or wifi should be two good ones to be tested.
3. Click "<" to go back to settings
4. hold any option and slide to the left

Youtube video is attached for reference:
http://www.youtube.com/watch?v=UEdHSR_pHaA&feature=g-upl

Hopefully this helps
OS: All → Gonk (Firefox OS)
Hardware: All → ARM
Oops, now that I think about it entering a sub section is crucial to reproduce this. Sorry for my incomplete STR, kaze. Thank you, Walter!
Tim, no problem.

The mechanism of settings is to load the setting sub section after you choose it. And, how it go back to the main setting app is to make the loaded sub section hide is by moving it to -100%. In this case, if you didn't get into a subsection before, there won't be anything for you to horizontally scroll.
(In reply to Walter Chen from comment #5)
> The mechanism of settings is to load the setting sub section after you
> choose it. And, how it go back to the main setting app is to make the loaded
> sub section hide is by moving it to -100%. In this case, if you didn't get
> into a subsection before, there won't be anything for you to horizontally
> scroll.

Sure thing, but I still can’t reproduce it. What Gecko version are you using?

FTR, this looks like bug 797411 which has been marked as bb-. To work around this bug we’re using an |overflow: scroll-y| rule in the Settings CSS, which has a high performance cost (~150ms IIRC) and which, apparently, isn’t enough in the case you’re both experiencing.
Depends on: 797411
(In reply to Fabien Cazenave [:kaze] from comment #2)
> Tim, I can’t reproduce with Gecko 18 and the latest Gaia on my Otoro. Which
> version of Gecko are you using?

Can still reproduce with latest Gaia and latest Gecko 18.
OS: Gonk (Firefox OS) → All
Hardware: ARM → All
(In reply to Walter Chen from comment #3)
> (beta v18 gecko with master gaia)

Oh, I missed that. My Gecko doesn’t have this bug…

> $ adb shell cat /system/b2g/platform.ini
> [Build]
> BuildID=20121129094217
> Milestone=18.0
> SourceStamp=6e6c2d28ffdf
> SourceRepository=http://hg.mozilla.org/releases/mozilla-beta

So this looks like a Gecko regression that appeared in the last 3 days. :-(
(In reply to Fabien Cazenave [:kaze] from comment #8)
> So this looks like a Gecko regression that appeared in the last 3 days. :-(

What's your tip revision? I can go back and try if I can still reproduce it.
(In reply to Tim Taubert [:ttaubert] from comment #9)
> (In reply to Fabien Cazenave [:kaze] from comment #8)
> > So this looks like a Gecko regression that appeared in the last 3 days. :-(
> 
> What's your tip revision? I can go back and try if I can still reproduce it.

GOSH, next time I'll read your whole comment :)
(In reply to Tim Taubert [:ttaubert] from comment #9)
> (In reply to Fabien Cazenave [:kaze] from comment #8)
> > So this looks like a Gecko regression that appeared in the last 3 days. :-(
> 
> What's your tip revision? I can go back and try if I can still reproduce it.

Can't reproduce anymore, that's a regression :|
Caused by bug 805638.
Adding :schien who worked on bug 805638.
+1 for nominating this bug as basecamp-blocker.
Attachment #687751 - Flags: review?(kaze)
Comment on attachment 687751 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/6784

works perfectly. Thanks!
Attachment #687751 - Flags: review?(kaze)
Attachment #687751 - Flags: review+
Attachment #687751 - Flags: approval-gaia-master?
Comment on attachment 687751 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/6784

NOTE: If blocking-basecamp+ is set, just land it for now.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 805638
User impact if declined: broken panel navigation
Testing completed: manual
Risk to taking this patch (and alternatives if risky): none
Attachment #687751 - Flags: approval-gaia-master? → approval-gaia-master?(21)
blocking-basecamp: ? → +
Priority: -- → P2
Duplicate of this bug: 817992
https://github.com/mozilla-b2g/gaia/commit/df7feaf15884019990d676a6e2ffacf40fc3d056
Assignee: nobody → ttaubert
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Attachment #687751 - Flags: approval-gaia-master?(21)
Duplicate of this bug: 817997
Duplicate of this bug: 818691
Looks good. Thanks for the fix Tim!
Status: RESOLVED → VERIFIED
Duplicate of this bug: 820190
The fix unexpectedly cause the problem bug 818056, leave the blocks tag here to know the dependency.
You need to log in before you can comment on or make changes to this bug.