640971 - When canceling Sync Popup the app should remain in the Awesomescreen, not to return to webpage

Status: VERIFIED WORKSFORME

(Firefox for Android Graveyard :: General, defect)

Description

[Cristian Nicolae (:xti)]

User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0) Gecko/20100101 Firefox/4.0
Build Identifier: 

When Cancel button is tapped from Sync Popup, the app should return to webpage view instead of remaining on Awesomescreen.

Reproducible: Always

Steps to Reproduce:
1. Open Fennec App
2. Tap on URL Bar
3. From Awesomescreen tap on Desktop tab
4. Tap on Cancel button

Actual Results:  
The app returns to webpage view. 

Expected Results:  
The app returns to the last tab tapped or the default tab from Awesomescreen (All Pages).

Build id : Mozilla/5.0 (Maemo;Linux armv7l;rv:2.0b13pre)Gecko/201100311
Firefox/4.0b13pre Fennec /4.0b6pre
Device: Sony Ericsson Xperia X10
OS: Android 2.1 update 1

Comment 1

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Attachment: Patch

Requesting review to both since I want your opinion on the behavior provided by this.

This one line removal means we will show the setup popup and keep the active panel if it is disabled but also if it is filled. I wonder if we want that or not?
One of the right behavior in my opinion has been to show the preference panel with the sync status (connecting...)

Comment 2

[Wesley Johnston (:wesj)]

You will also need to ensure that the correct panel button is highlighted when the dialog is closed.

Still thinking myself about what the correct behavior is, and if it should vary if the user cancels vs. finished setting up sync.

Comment 3

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to comment #2)
> You will also need to ensure that the correct panel button is highlighted when
> the dialog is closed.

Good catch.
 
> Still thinking myself about what the correct behavior is, and if it should vary
> if the user cancels vs. finished setting up sync.

What about:
 - "cancel" do nothing (excepting ensuring the correct button is selected :) )

 - Completing the steps brings you to the preferences panel? This is what happen if you click on the "Remote tabs" button before Weave has finished to starts

Comment 4

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Just copying what madhava says on IRC

17:49 < madhava> I think desktop tabs are the first thing to be synced
17:49 < vingtetun> philikon: ^
17:49 -!- taras [[e-mail]] has joined #mobile
17:50 < madhava> there seems to be stuff there as soon as I switch to it
17:50 -!- dougt|away is now known as dougt
17:50 < madhava> though that takes some time
17:50 < madhava> it's ok if things are filling in while the user watches
17:50 < tchung> yeah we do 
17:50 < tchung> you dont need to be 100% done to see tabs
17:50 < madhava> but yeah - a completely blank screen wouldn't be great
17:50 < vingtetun> if you click on the "remote tabs" before sync has finished logging you will be redirected to the preferences panel
17:51 < madhava> ugh
17:51 < madhava> wait - what does logging mean in the context
17:51 < vingtetun> hmm, by logging i mean connecting to the sync server
17:52 < vingtetun> validating the username/password/sync key
17:52 < vingtetun> i think we do that in case something went wrong
17:52 < madhava> isn't that what happens when the jpake dialog is still on the screen, on mobile?
17:52 < madhava> if something goes wrong, then yeah - we could go over to prefs and open the details section
17:53 < madhava> let me try this again
17:53 < vingtetun> yep
17:53 -!- AndreeaPod [[e-mail]] has quit [Quit: http://www.mibbit.com ajax IRC Client]
17:53 -!- ted [[e-mail]] has quit [Ping timeout]
17:54 -!- ted [[e-mail]] has joined #mobile
17:54 < madhava> I just did it again, switching to "Desktop" as fast as I could
17:55 < madhava> and there was content there
17:55 < madhava> if you cancel on the device during the setup process, we shouldn't take you to prefs -- we should put you back where you were
17:55 < tchung> vingtetun: hi, should the form helper buttons arrows detect a submit button to jump to?
17:55 < vingtetun> madhava: agree on that
17:55 -!- retrodos [[e-mail]] has joined #mobile
17:55 < vingtetun> tchung: normally
17:56 < madhava> well - it sounds like we don't know if there'd be content in the Desktop tab fast enough, and what it looks like
17:56 < madhava> can you try doing it that way and see what happens?

Comment 5

[Mark Finkle (:mfinkle) (use needinfo?)]

This IRC log is a bit hard to follow. What is the end result? Could you summarize it Vivien?

Comment 6

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Attachment: plan screenshot

(In reply to comment #5)
> This IRC log is a bit hard to follow. What is the end result? Could you
> summarize it Vivien?

I have a screenshot of a plan that I think could resume this in a better way.

Comment 7

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Comment on attachment 518721 [details] [diff] [review]
Patch

...which mean that this patch does not make sense.

Comment 8

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

This has been fixed by Bug 653146

Comment 9

[Cristian Nicolae (:xti)]

Verified as it works for me.
Build id : Mozilla/5.0 (Android;Linux armv7l;rv:6.0a1)Gecko/20110523
Firefox/6.0a1 Fennec/6.0a1
Device: HTC Desire
OS: Android 2.2