Closed Bug 640971 Opened 14 years ago Closed 14 years ago

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

Categories

(Firefox for Android Graveyard :: General, defect)

ARM
Android
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED WORKSFORME

People

(Reporter: xti, Assigned: vingtetun)

References

Details

Attachments

(2 files)

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
OS: Other → Android
Hardware: Other → ARM
Attached patch PatchSplinter Review
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...)
Assignee: nobody → 21
Status: UNCONFIRMED → NEW
Ever confirmed: true
Attachment #518721 - Flags: review?(wjohnston)
Attachment #518721 - Flags: review?(mark.finkle)
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.
(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
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 [taras@moz-400224C4.hsd1.wa.comcast.net] 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 [Mibbit@601F3B17.33662590.A5830293.IP] has quit [Quit: http://www.mibbit.com ajax IRC Client] 17:53 -!- ted [luser@moz-79C07B92.c3-0.tlg-ubr5.atw-tlg.pa.cable.rcn.com] has quit [Ping timeout] 17:54 -!- ted [luser@moz-79C07B92.c3-0.tlg-ubr5.atw-tlg.pa.cable.rcn.com] 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 [Woodzy@moz-22053D84.chyn.qwest.net] 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?
Blocks: 639711
This IRC log is a bit hard to follow. What is the end result? Could you summarize it Vivien?
Attached image 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 on attachment 518721 [details] [diff] [review] Patch ...which mean that this patch does not make sense.
Attachment #518721 - Flags: review?(wjohnston)
Attachment #518721 - Flags: review?(mark.finkle)
This has been fixed by Bug 653146
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
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
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: