Stock Android 2.3 browser cannot find relay frame on dev.myfavoritebeer.org

[shane-tomlinson]

No description provided.

[jbonacci]

ah, so somebody else is seeing this besides me?

(not sure where to put my comments, so will put them in 590 and in 596 for now)
Yes, I can duplicate this easily with the phone I am using.
This is a Samsung Galaxy S SGH-T959, running with 2.2 Firmware.
Stock Browser.
And, no Relay Frame issue using Opera Mobile.

[jbonacci]

Verified again on htc glacier (myTouch 4g), running 2.2 firmware (thanks, juanb), for Dev and Beta.
Verified again on my Samsung Galaxy S for both Dev and Beta.

[jbonacci]

Could not duplicate this specific issue with a 2.3 device: Samsung Nexus S (Android 2.3.6)
Did see a separate (known?) issue with the 2.3 device and the 3.1 Tablet.
If you dismiss/close the Sign In window/tab, the beer site does not automatically refresh = no obvious way to Sign In, since the button appears to be "grayed" out. Have to refresh the beer site first.
If this is not already a bug, I will file this.

[jbonacci]

Here is issue #2: #492 Android/Browser: Cancelling sign-in on beer site does not refresh Sign In

[jbonacci]

Here is our third device running 2.2 firmware: htc tmobile g2 (hardware is the same as the htc desire z)
The error was duplicated in Dev and Beta, but not in Prod.

[jbonacci]

Just one more bit. Verified that Sign In works as expected on Firefox 7, Opera Mobile, and the latest version of Dolphin.

[benadida]

from my testing, it appears that things work fine on android 2.2 and 2.3 stock browser on dev server as long as the stock browser is set to be the default. If you have to pick another browser, on android 2.2 at least the popup replaces the main rp window, and you're out of luck. I'm wondering if I can recreate this problem in 2.3 by not having a default browser... let me try.

[benadida]

it appears that this is due to not having a default browser set, which then leads the popup to replace the relying party window.

resolution: set a default browser.

[shane-tomlinson]

@benadida - ahhh, interesting. Because earlier today, I did not have a default browser set on Android, and then when I set the default browser is when I went "hey, this is working now."

[lloyd]

@jbonacci - why were you able to reproduce this issue on 3 / 3 of your test devices?

Is it the case that this is 100% common in our QA environments but doesn't happen with actual users? Pardon my ignorance of typical android user behaviors.

It sounds like we're saying this is a regression, but not one we care to fix?

[jbonacci]

I am not sure @lloyd, but I would expect that normal users would have set their default browser to their favorite choice. I can't imagine users having to pick the browser over and over again.
I had just not set mine because I switch between browsers frequently for testing so do not want a "default".

[jbonacci]

Yea, so this is "fixed" in that stock browser users will most definitely have that set as their default.
Users of Firefox, Opera, or Dolphin would do the same for their favorite (although these browsers do not exhibit the problem).

[benadida]

I have a theory as to why this might be happening, but I need to test it out. I think that I'm adding the iframe after document.body is ready but before onload has fired, which may mean that the browser considers the page not loaded, so when it exits out to the "choose browser" dialog, and the same browser is selected to load the iframe content, the browser may assume "i have no loaded page, I'm going to just load this in window.top".

Crazy theory, but that's really the only difference between production and beta: when the iframe is loaded.

I'm going to try and see if I can fully wait until onload event, which we should do anyways.