Closed Bug 1173621 Opened 4 years ago Closed 2 years ago

[Aries][Customizer] If user reaches the end of scrollable area in the customize area it will begin to scroll the main app area

Categories

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

ARM
Gonk (Firefox OS)
defect

Tracking

(b2g-master affected)

RESOLVED WONTFIX
Tracking Status
b2g-master --- affected

People

(Reporter: AdamA, Unassigned)

References

()

Details

(Whiteboard: [3.0-Daily-Testing][Spark])

Attachments

(1 file)

Attached file logcat
Summary (title) Field:
[Aries][Customizer] If user reaches the end of scrollable area in the customize area it will begin to scroll the main app area

Description:
When the user is scrolling up and down in the customaize area and they run out of room they will begin scrolling the main area of the app.

Repro Steps:
1) Update a Aries to 20150610170534
2) Enter the customize app
3) Choose to customize the email app
4) Scroll until you reach the end of the custimize area
5) Observe main app area scroll

Actual:
The main app area will scroll when the customize end is reached

Expected:
It is expected that the scroll area does not transfer.

Environmental Variables:
Device: Aries 3.0 (Full Flash)
Build ID: 20150610170534
Gaia: e3eaf72ccd1bfe6d60d37efde6d3b92c1dbc5ff9
Gecko: 95afddf894e3
Gonk: 75c7e6ca80d0c7a53f346ecfcde2343be95808c9
Version: 41.0a1 (3.0)
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0

Repro frequency: 10/10
See attached: video(https://www.youtube.com/watch?v=sJFpDAMvlMM), logcat
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Whiteboard: [3.0-Daily-Testing][Spark]
I'm pretty sure that there's nothing we can do about this without very serious changes to APZ. :kats, any thoughts?
Flags: needinfo?(bugmail.mozilla)
Scroll handoff between scrollable elements is definitely a "by design" feature.

That said - if you don't want the main app area to scroll when the customize area is shown, can you simply make the main app area overflow:hidden for that time?
(In reply to Botond Ballo [:botond] from comment #2)
> Scroll handoff between scrollable elements is definitely a "by design"
> feature.
> 
> That said - if you don't want the main app area to scroll when the customize
> area is shown, can you simply make the main app area overflow:hidden for
> that time?

The Customizer runs inside arbitrary content, so that could break the app. If it comes down to that, I'd rather just live with this bug.
It may be possible to toggle an overflow:hidden property on the body on touchstart/touchend within the Customizer. I'll try this and see if it will work.
(In reply to Justin D'Arcangelo [:justindarc] from comment #4)
> It may be possible to toggle an overflow:hidden property on the body on
> touchstart/touchend within the Customizer. I'll try this and see if it will
> work.

Actually, if this does work, it may help resolve the other bug (don't have the number offhand) where the overscroll effect is not consistently applied to the Customizer scroll area.
(In reply to Justin D'Arcangelo [:justindarc] from comment #4)
> It may be possible to toggle an overflow:hidden property on the body on
> touchstart/touchend within the Customizer. I'll try this and see if it will
> work.

This could really regress perf in certain situations, though Gecko handle this well enough that it doesn't. I would recommend enabling paint flashing and compare before and after. Regardless of what we do, I don't think that this should be a priority right now.
Priority: -- → P2
I don't have much to add beyond what Botond said. Having seen it in action on a device now, I feel like it probably shouldn't live *inside* the scrollable area of the app but rather be a sibling of it somehow. That would prevent the handoff from happening. I haven't looked into it further or looked at the code for it.
Flags: needinfo?(bugmail.mozilla)
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #7)
> I don't have much to add beyond what Botond said. Having seen it in action
> on a device now, I feel like it probably shouldn't live *inside* the
> scrollable area of the app but rather be a sibling of it somehow. That would
> prevent the handoff from happening. I haven't looked into it further or
> looked at the code for it.

Unfortunately, because of the way add-ons work, the code for the Customizer is "injected" into every running app and lives within a sandbox of the app's window. Therefore, I don't think it would be possible to make it a sibling of the app window.

However, it may be possible at some point to just host the UI for Customizer in the System app and only inject a stub into the apps themselves for communicating back and forth between the System app and the app window. I'd have to really give this some more thought though because I'm not even sure that's possible.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(pbylenga)
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.