Closed Bug 619795 Opened 9 years ago Closed 9 years ago

Cannot hit android "Back" button after connecting to Sync

Categories

(Firefox for Android Graveyard :: General, defect)

ARM
Android
defect
Not set

Tracking

(fennec2.0b4+)

VERIFIED FIXED
Tracking Status
fennec 2.0b4+ ---

People

(Reporter: tchung, Assigned: mbrubeck)

Details

Attachments

(2 files)

on my nexus one, using Fennec 4beta 3.  I just connected my sync account via jpake setup.  Now i want to hit "Back" on my android content button to get back to my awesomescreen.   Nothing happens, and i'm stuck on the prefpane

* Dupe me if its known.

Repro:
1) install fennec 4 beta 3, Nexus One
2) open prefs, and connect to sync via jpake method
3) After connected, it goes back to prefpane.  Click "Back" on android content screen to get back to webpage
4) Verify nothing happens.  stuck on Prefpane

Expected:
- take me back to awesome screen or web content page

Actual:
- nothing, stuck.
tracking-fennec: --- → ?
Alternately, i can navigate throughout the prefs, like switch to downloads, addons, error console etc..  the touchscreen space is still active.
Do we have STR yet?
is my str in comment 0 not enough?  also, nothing shows up in error console.
(In reply to comment #3)
> is my str in comment 0 not enough?  also, nothing shows up in error console.

No, actually it's not. I can't reproduce and neither could you when you tried to show me. So, if we can show this is still a bug, then we need to block b4 for it.
Marking blocking b4, but I need people to tell me this is still a bug or I'm closing the bug as WORKSFORME.
tracking-fennec: ? → 2.0b4+
i'll be looking again at this hard over the weekend, cause i seen it again on the nightlies yesterday.  give me till next week before you WFM the bug
I saw it with beta 3 build 2 on Samsung epic, but for the life of me I can not determine how I got into the state. It stays persistent once it occurs. On build 3 now and it is not happening for now. I will update the bug if I see it or can repro it.
Anyone who sees this happen, can you check whether other keys still work?  (For example, can you type in the add-on search box?)  If not, it could be related somehow to bug 591307.
I haven't seen any reports of this, so I am un-blocking this bug. If all continues to go well, we can close it soon.
tracking-fennec: 2.0b4+ → ---
tracking-fennec: --- → ?
I just saw this again on my N1 (creating a new exception every time I hit the Android back button):

uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIScrollBoxObject.scrollTo]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: chrome://browser/content/sync.js :: close :: line 161"  data: no]

STR: I clicked on Settings -> Connect and tried to add my device by adding the sync code to my desktop FF (Minefield) which failed. So I hit cancel. Et voila.

Mozilla/5.0 (Android; Linux armv7l; rv:2.0b10pre) Gecko/20110111 Firefox/4.0b10pre Fennec/4.0b4pre ID:20110111042438

Installed add-ons: Full Screen 1.1, Grassy Land, Nightly Tester Tools for Mobile 3.1.1, Personas 0.5, Phony 1.0, Quit Fennec 1.2.1, Reading List 1.2.6 

Details and settings: http://pastebin.com/dnb8AywU
Oh, and after killing the app and restarting, I saw sync enabled but the connect button missing (see attached screenshot). The button re-appears after you switch sync off and then on again.
(In reply to comment 11)
> Oh, and after killing the app and restarting, I saw sync enabled but the
> connect button missing (see attached screenshot). The button re-appears after
> you switch sync off and then on again.

From inspecting the code, this might happen if browser.sync.enabled is changed
from false to true by something other than the user pressing the toggle switch.  I filed bug 625224 to fix the loophole that can leave the UI in this state, but I'm still not sure what the root cause is.

The scrollTo exception is probably a better clue...
Additional info: I canceled sync on my desktop before all this happened. This may have somehow switched the sync state on connected devices. Even though I don't how why that would mess with the system buttons.
Attached patch patchSplinter Review
Okay, I can reproduce this problem if I edit the code to simulate an onAbort from Weave.JPAKEClient, with an error other than JPAKE_ERROR_CHANNEL.  This causes WeaveClient.open() to be called a second time.  If the dialog is already open, and open() is called again, then it gets pushed onto the pushDialog stack twice.

Then handleEscape tries to close it twice, and the second WeaveGlue.close() throws an exception at scrollTo because the scrollbox is hidden, so it never reaches the popDialog but remains on the stack forever.

This patch prevents pushDialog from being called while the dialog is already open.
Assignee: nobody → mbrubeck
Status: NEW → ASSIGNED
Attachment #503358 - Flags: review?(mark.finkle)
Comment on attachment 503358 [details] [diff] [review]
patch

Nice working tracking this down
Attachment #503358 - Flags: review?(mark.finkle) → review+
tracking-fennec: ? → 2.0b4+
http://hg.mozilla.org/mobile-browser/rev/ad25745bf0e9
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
verified fixed on : Mozilla /5.0 (Android;Linux armv7l;rv:2.0b13pre) Gecko/20110306 Firefox/4.0b13pre Fennec /4.0b6pre
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.