Closed
Bug 810227
Opened 13 years ago
Closed 13 years ago
[FTU] Card view should not be able to launch
Categories
(Firefox OS Graveyard :: Gaia, defect, P3)
Tracking
(blocking-basecamp:+)
VERIFIED
FIXED
| blocking-basecamp | + |
People
(Reporter: johnshih.bugs, Assigned: borjasalguero)
References
Details
Attachments
(1 file)
|
193 bytes,
text/html
|
Details |
## Environment :
Otoro phone, build 2012-11-09
Build info:
* gaia master: revision= a9e28710cb2f1f68576986c5e348d990a2514ee0
* gecko aurora revision= 6735d6d13751
## Repro :
1. Flash the phone
2. Unlock the phone, FTU app will be launched
3. In the FTU app, long press on home button
## Expected:
* Nothing happen
## Actual:
* Card view will be launch, I even can scroll up to kill the FTU app
Comment 1•13 years ago
|
||
I recalls that android FTU prevents the user from pressing home or holding home button.
Window Manager has a workaround about preventing home button event to occur when ftu is running, maybe we need the same logic in the cards view.
Comment 3•13 years ago
|
||
Good catch, John. You are correct. We need to disable the Task Manager and Home buttons when the user is in the FTE (both the Setup, and the subsequent Tutorial app).
Flags: needinfo?(jcarpenter)
Comment 4•13 years ago
|
||
Does it affect the device configuration in any way ?
blocking-basecamp: ? → -
Flags: needinfo?(fbsc)
Comment 5•13 years ago
|
||
(In reply to dscravaglieri from comment #2)
> Does ftu is mandatory to be run ?
It is. I would say this is blocking just because this is the first interaction the user has with the device so it should not have buggy behavior. Renoming.
blocking-basecamp: - → ?
Comment 6•13 years ago
|
||
(In reply to dscravaglieri from comment #4)
> Does it affect the device configuration in any way ?
If we don't fix this,
the user could kill/close FTU in card view when the FTU is still running, and cannot find FTU anywhere until he 'factory resets' the phone.
| Assignee | ||
Comment 7•13 years ago
|
||
Some comments. It's true that 'card-view' during 'FTU' should not be launch, so we should 'prevent' the 'holdhome' event. On the other hand, killing 'FTU' doesnt mean that you are not going to see it again, due to FTU is over ONLY if the whole process is over (if at the end you click on 'Let's go').
IMHO I think that this bug should be bb+ in order to fix it asap.
[:vivien] 'holdhome' event is currently being used in some parts of the code, any suggestion for fixing it? Because I think that it's not enough with 'preventing the default' behaviour...
Flags: needinfo?(fbsc)
Comment 8•13 years ago
|
||
(In reply to Borja Salguero [:borjasalguero] from comment #7)
> Some comments. It's true that 'card-view' during 'FTU' should not be launch,
> so we should 'prevent' the 'holdhome' event. On the other hand, killing
> 'FTU' doesnt mean that you are not going to see it again, due to FTU is over
> ONLY if the whole process is over (if at the end you click on 'Let's go').
> IMHO I think that this bug should be bb+ in order to fix it asap.
> [:vivien] 'holdhome' event is currently being used in some parts of the
> code, any suggestion for fixing it? Because I think that it's not enough
> with 'preventing the default' behaviour...
event.preventDefault() should be enough. Other codes needs to check for event.defaultPrevented and do nothing if that the case.
Gaia Triage : -
Discussion points:
Even though FTU appears only after flashing or reseting the device, all the options should be available to the end user to manually do so, rather than being forced to go through the FTU each time. Also to note, for a first time user, they most likely wouldn't know to hold the home key down. This seems like an edge case.
blocking-basecamp: ? → -
Comment 10•13 years ago
|
||
> On the other hand, killing 'FTU' doesnt mean that you are not going to see
> it again, due to FTU is over ONLY if the whole process is over (if at the
> end you click on 'Let's go').
Good to know, but that is also problematic. So I skip the FTE (intentionally or accidentally) and then am presented with it the next time I use the device? That is very unexpected behavior.
> This seems like an edge case.
Respectfully disagree. Remember that we're also disabling the Home button during the FTE. What is a common reaction to a button not working? Pressing it longer. And poof, suddenly you're in the Task Manager. Baffling for novice users, with non-trivial chance of killing the FTE entirely via swipe to dismiss. We should close this loophole. Vivien already outlined the method. Re-nom'ing.
blocking-basecamp: - → ?
| Assignee | ||
Updated•13 years ago
|
Assignee: nobody → fbsc
| Assignee | ||
Comment 11•13 years ago
|
||
NOTE: If blocking-basecamp+ is set, just land it for now.
[Approval Request Comment]
Bug caused by (feature/regressing bug #):
User impact if declined:
Testing completed:
Risk to taking this patch (and alternatives if risky):
Attachment #682923 -
Flags: review?(francisco.jordano)
Attachment #682923 -
Flags: approval-gaia-master?(francisco.jordano)
Updated•13 years ago
|
blocking-basecamp: ? → +
Priority: -- → P3
| Assignee | ||
Updated•13 years ago
|
Attachment #682923 -
Flags: review?(francisco.jordano)
Attachment #682923 -
Flags: approval-gaia-master?(francisco.jordano)
| Assignee | ||
Comment 12•13 years ago
|
||
Solved implicitly with the workaround fixed in #810229 ! Closing!
| Assignee | ||
Updated•13 years ago
|
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
| Reporter | ||
Comment 13•13 years ago
|
||
verified on 2012-11-20 unagi
gaia master : 53d1e5cf7b805a6e83a070de5b01fb28b8558380
mozilla-aurora : b3950b0ad29a
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•