Closed
Bug 1173621
Opened 10 years ago
Closed 7 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)
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)
315.88 KB,
text/plain
|
Details |
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
Reporter | ||
Updated•10 years ago
|
QA Whiteboard: [QAnalyst-Triage?]
status-b2g-master:
--- → affected
Flags: needinfo?(pbylenga)
Whiteboard: [3.0-Daily-Testing][Spark]
Comment 1•10 years ago
|
||
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)
Comment 2•10 years ago
|
||
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?
Comment 3•10 years ago
|
||
(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.
Comment 4•10 years ago
|
||
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.
Comment 5•10 years ago
|
||
(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.
Comment 6•10 years ago
|
||
(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
Comment 7•10 years ago
|
||
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)
Comment 8•10 years ago
|
||
(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.
Updated•9 years ago
|
Blocks: Foxfood-papercuts
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(pbylenga)
Comment 9•7 years ago
|
||
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•