Closed Bug 1088461 Opened 5 years ago Closed 4 years ago

[B2G][FTU][Browser]User is able to bypass the FTU when opening multiple browser tabs, accessing card view and closing the tabs

Categories

(Firefox OS Graveyard :: Gaia::First Time Experience, defect, P3)

ARM
Gonk (Firefox OS)
defect

Tracking

(blocking-b2g:2.5+, tracking-b2g:backlog, b2g-v2.1 affected, b2g-v2.2 affected)

RESOLVED FIXED
blocking-b2g 2.5+
tracking-b2g backlog
Tracking Status
b2g-v2.1 --- affected
b2g-v2.2 --- affected

People

(Reporter: jmitchell, Assigned: sfoster)

References

()

Details

(Whiteboard: [2.1-bug-bash] [systemsfe], ux-most-wanted-nov2014)

Attachments

(1 file)

Description:
User is able to bypass the FTU to arrive at the Homescreen in a partially broken state. This is accomplished by opening a browser window, opening multiple tabs, accessing card view and closing all the tabs. They are then taken to the homescreen but the homescreen button is still disabled as if in the FTU still. This will prevent the user from returning to the homescreen once they open an app from there.

Repro Steps:
1) Update a Flame to 20141023001201
2) Connect to Data or Wifi
3) On the Geolocation screen select the 'More about your privacy' link (other links in the FTU can be used)
4) Select EverythingMe
5) Long press 'About' and select 'open link in new tab'
6) Select ... and select 'New Window'
7) Select the two squares to the right of the Address Bar to access card view
8) Slide the tabs off the screen to close them all

Actual:
User arrives at the homescreen bypassing the FTU, The user then gets stuck in any app because the homescreen button does not work

Expected:
User will not be able to bypass the FTU

Environmental Variables:
Device: Flame 2.1
Build ID: 20141023001201
Gaia: 1e48e3e40e0780c0cd07a3457e5fe2efeeb542d1
Gecko: 09fb60a37850
Version: 34.0 (2.1)
Firmware Version: v188
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Repro frequency: 100%


QA-Wanted for branch checks and Video
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Issue also occurs in Flame 2.2

Device: Flame 2.2 (Full Flashed Nightly Build)
Build ID: 20141024040202
Gaia: d893a9b971a0f3ee48e5a57dca516837d92cf52b
Gecko: a5ee2769eb27
Version: 36.0a1 (2.2)
Firmware Version: v188
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

------------------------------------------------------------------------------------------

Issue is not valid in 2.0 - The design is different - browser does not open multiple tabs in card view, but instead a single browser with multiple tabs, user cannot get to card view.
Keywords: qawanted
[Blocking Requested - why for this release]:

If an user encounters this issue they will be stuck inside an app. They will have to pull their battery to recover so nominating this 2.1?
blocking-b2g: --- → 2.1?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage+]
Keywords: qawanted
Agree we should block on this, but the user should be able to restart as normal with the power button without resorting to pulling the battery. 

> If an user encounters this issue they will be stuck inside an app. They will
> have to pull their battery to recover so nominating this 2.1?
We prevent the user from getting to the task manager/cards view via the usual long-tap on home. But it looks like they can still get there via the 'show windows' button in the browser chrome. This is another of those FTU "leaks" in which we struggle to make the FTU process fully modal. In this case its not unreasonable to want to navigate to other browser tabs, so I'm not sure disabling or removing the button is the right fix. Francis, Jacqueline - what do you think?
Flags: needinfo?(jsavory)
Flags: needinfo?(fdjabri)
(In reply to Sam Foster [:sfoster] from comment #3)
> Agree we should block on this, but the user should be able to restart as
> normal with the power button without resorting to pulling the battery. 
> 
> > If an user encounters this issue they will be stuck inside an app. They will
> > have to pull their battery to recover so nominating this 2.1?

That is correct: User can long-press the power button and Restart the phone.

Video added to URL section: http://youtu.be/q4-7hTJubeA
Keywords: qawanted
QA Contact: jmitchell
Whiteboard: [2.1-FC-bug-bash] → [2.1-bug-bash]
Whiteboard: [2.1-bug-bash] → [2.1-bug-bash] [systemsfe]
Thats not a regression and an edge case. Lets fix on master.
blocking-b2g: 2.1? → backlog
Priority: -- → P1
It seems as if there's a bigger problem here, in that the user could easily get stuck if the create a new browser window while still in the FTU flow. From a UI perspective, I think the most intuitive thing to do would be to treat the FTU flow as "home" until the FTU is completed - therefore, taps on Home should return the user to the point in the FTU flow where they left off.
Flags: needinfo?(fdjabri)
Duplicate of this bug: 1094777
Blocks: 1098041
I agree with Francis, I think that the tap home to return to FTU will be intuitive to the user and easily discoverable. We should try to use this solution in other areas where the user can escape FTU, if we can.
Flags: needinfo?(jsavory)
Blocks: 994991
Whiteboard: [2.1-bug-bash] [systemsfe] → [2.1-bug-bash] [systemsfe], ux-most-wanted-nov2014
Duplicate of this bug: 1102646
Found another method of escaping the FTU - if the user long presses on and then shares a link (via messenger for example)he can then click that link to open an instance of browser that dead-ends (can't return to FTU). Just adding that here for the similarity and that it would be fixed by the same fix to this bug (having home button return to FTU during FTU process)

Device: Flame Master (nightly - full flash - kk)
Build ID: 20150112010228
Gaia: f5e481d4caf9ffa561720a6fc9cf521a28bd8439
Gecko: bb8d6034f5f2
Gonk: a814b2e2dfdda7140cb3a357617dc4fbb1435e76
Version: 37.0a1 (Master)
Firmware Version: V18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
blocking-b2g: backlog → ---
Duplicate of this bug: 1039044
Duplicate of this bug: 1130121
Duplicate of this bug: 972128
Duplicate of this bug: 1149462
[Blocking Requested - why for this release]:  I think we should block at least 3.0 for this.
Once you go to the privacy, there's no back.  We fixed it so that you can't hit home to go to the homescreen.  Thus you're in a locked position to FTU browser.  Terrible first time experience.
blocking-b2g: --- → 3.0?
(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #16)
> [Blocking Requested - why for this release]:  I think we should block at
> least 3.0 for this.
> Once you go to the privacy, there's no back.  We fixed it so that you can't
> hit home to go to the homescreen.  Thus you're in a locked position to FTU
> browser.  Terrible first time experience.

Wait that sounds like something different? If you visit the privacy pages you should get a popup window with no chrome and only a 'x' close button. If you continue to browse in that window, closing that window still brings you back to the FTU. There are (quite a few) ways to 'escape' the FTU, but each is arguably an edge case which is why we've punted on the necessary work to fix this for the last couple of releases. 

Agreed that we should get this fixed for the next major release, I just want to be sure we're not conflating a major issue with a relatively minor one.
See comment #17
Flags: needinfo?(nhirata.bugzilla)
ya I think you're right.  filed bug 1159906 as that was a regression.  removing blocking nom.
blocking-b2g: 3.0? → ---
Flags: needinfo?(nhirata.bugzilla)
Priority: P1 → P3
You also can install and launch marketplace apps in the FTU which leaves the user stuck in the app. They will have to restart their device to recover.
(In reply to KTucker [:KTucker] from comment #20)
> You also can install and launch marketplace apps in the FTU which leaves the
> user stuck in the app. They will have to restart their device to recover.

Could you file that as a separate issue? I know they are all related but as each needs a potentially different solution I'd like to track them individually.
Duplicate of this bug: 1178706
Comment on attachment 8674518 [details] [review]
[gaia] sfoster:ftu-browser-contextmenu-bug-1088461 > mozilla-b2g:master

Here's one way to accomplish this. There's basically nothing in the browser contextmenu that makes sense to do during FTU (pending :jsavory's input on dupe bug 1178706)
Attachment #8674518 - Flags: review?(kevingrandon)
Comment on attachment 8674518 [details] [review]
[gaia] sfoster:ftu-browser-contextmenu-bug-1088461 > mozilla-b2g:master

Seems fine to me. Appears that gaia-try is down, but the test is passing for me locally so I'm comfortable landing this. Thanks!
Attachment #8674518 - Flags: review?(kevingrandon) → review+
Master: https://github.com/mozilla-b2g/gaia/commit/7a3d8d85a26a338f9656c355e1cca473ce9b2ad5
Assignee: nobody → sfoster
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
dupe was a blocker (bug 1178706)
blocking-b2g: --- → 2.5+
You need to log in before you can comment on or make changes to this bug.