Closed Bug 815875 Opened 12 years ago Closed 12 years ago

Headers scroll along with content in settings app

Categories

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

defect

Tracking

(blocking-basecamp:-)

RESOLVED FIXED
blocking-basecamp -

People

(Reporter: cjones, Assigned: kaze)

References

Details

(Keywords: polish)

Attachments

(3 files, 1 obsolete file)

I thought for sure this had been filed, but I guess not. STR (1) Open settings app (2) tap "Device Information" (3) Scroll down to bottom of panel Note that the "< Device Information" header scrolls with the content. To tap "<" to return to the previous screen, I have to scroll all the way back up. Instead, we could fix the header and not have to scroll.
blocking-basecamp: ? → -
Keywords: polish
Priority: -- → P4
I don't understand the comment there. This works great! :) What issue(s) were you seeing before?
Attachment #687346 - Flags: review?(kaze)
Attachment #687346 - Attachment is obsolete: true
Attachment #687346 - Flags: review?(kaze)
Comment on attachment 687347 [details] [diff] [review] Re-enable the code to prevent scroll headers in sub-panels, v1.1 Sigh, sorry for bugspam.
Attachment #687347 - Flags: review?(kaze)
Comment on attachment 687347 [details] [diff] [review] Re-enable the code to prevent scroll headers in sub-panels, v1.1 This has to land. If there is a platform bug we will fix it.
Attachment #687347 - Flags: review?(kaze) → review+
Using "position: fixed" creates an annoying bug on recent desktop Firefox (18+), that’s why I disabled this part of the code. Keeping this compatibility with Firefox would be more efficient to work on CSS fixes. Bug 815608 should provide a suitable workaround by embedding all panel content in a container below the header, thus preserving the compatibility with gecko 18 and later. Please let me know if that’s a suitable solution for you. Besides, there are some cross-dependencies with other bugs related to Settings slide-in transitions, and I would like to take a day to see that as a whole. Please leave me three days to finish my C2 bugs first, and I’ll happily look at these CSS improvements.
It's great that you're focusing on C2 bugs, but every day that goes by means getting patches like this approved is that much harder. If you're overloaded, can you suggest someone else for review, or what kind of testing you wanted done?
It's already r+'ed. Again I'd prefer to fix the other related bugs first (bug 817181 and bug 815608) but you just need a gaia-approval or BB+ to land it.
This rendering bug makes it very difficult to work on the Settings CSS with Firefox. As we don’t have any devtools in b2g-desktop at the moment, I’d prefer to keep headers fixed with another patch — see bug 815608.
Agreed with cjones, I thought I had filed this one already too. It's important for the header to be fixed for navigation purposes. It drives me nuts right now :)
Oh, I certainly agree with this too! Again, this patch has already been r+’ed by Andreas and there’s another one in progress (bug 815608). Larissa, what’s the expected behavior of the vertical scrollbar here? Do we want the scrollbar to be displayed over the main heading, or just in the container below? I think I read a bug report about that recently but I can’t remember…
Depends on: 815608
Just wanted you guys to know that I'm still paying some attention to UX love :) Ideally, the vertical scrollbar should just be visible in the container below since we don't want the header to scroll.
(In reply to Larissa Co from comment #12) > Just wanted you guys to know that I'm still paying some attention to UX love > :) > I never doubted it, and it’s nice to benefit from your responsiveness. :) > Ideally, the vertical scrollbar should just be visible in the container > below since we don't want the header to scroll. OK, then Pavel’s ongoing patch is definitely the way to go (better than using « position: fixed »). I know he’s very busy at the moment but I’m confident his patch will be ready in the next few days.
Assignee: nobody → kaze
kaze, I bet that this bug no longer reproduces in latest desktop builds. Does it?
Flags: needinfo?(kaze)
Comment on attachment 687347 [details] [diff] [review] Re-enable the code to prevent scroll headers in sub-panels, v1.1 Chris, you’re right, the problem doesn’t show up any more in my Nightly build. I’ve put you in a? so you can merge it. Thanks! NOTE: If blocking-basecamp+ is set, just land it for now. [Approval Request Comment] Bug caused by (feature/regressing bug #): ? User impact if declined: painful panel navigation in the Settings app Testing completed: manual Risk to taking this patch (and alternatives if risky): none
Attachment #687347 - Flags: approval-gaia-master?(jones.chris.g)
Flags: needinfo?(kaze)
Comment on attachment 687347 [details] [diff] [review] Re-enable the code to prevent scroll headers in sub-panels, v1.1 Very safe patch that fixes a major usability issue. I extensively tested the functionality and performance of settings with and without this and was unable to observe changes. (In fact, I was somewhat surprised perf wasn't affected ...)
Attachment #687347 - Flags: approval-gaia-master?(jones.chris.g) → approval-gaia-master+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: