Unagi device, using: gaia revision=fcfa1857bed6596e992263206451c6814e4b2f6d gecko revision=f58edfde05cb708f8a2c440d338f2e429aaf372b Using a hotel wifi network when this happened that requires a login and password STR: 1. Launch the browser and add a bookmark to your home screen. In my case I added cnn.com 2. The bookmark is added and during smoketesting at some point I restarted the phone during testing. 3. I load cnn.com and I am taken to the hotel wifi login screen again. 4. I go the browser but I can load all other sites fine as well as the other bookmarks that I added after the system restart. 5. Reloading the browser does nothing and I still see either the wifi screen or "The app is having problems error message." This seems bad to me, since adding sites to your home screen seems like a common use case.

I'm a bit confused about your STR. When you say you "load cnn.com", do you mean by selecting the bookmark on the homescreen (which opens it in the homescreen app in a thin wrapper UI), or by navigating to it in the browser app? Note that these are two separate apps which have separate data jars, so being logged into something in one does not mean you are logged in in the other.

Sorry for the confusion. When I say I load cnn in Step 3, I am loading it by selecting the bookmark that I added to the homescreen previously. I just tried reproducing it with another site (nytimes.com), and it did not repro with that site using the 2012-10-25 build - the nytimes homescreen app loaded fine. When I tried it again with CNN homescreen app using the 2012-10-25 build, I get an error page from CNN saying "CNN mobile site requires cookies," which is different behavior from what I got yesterday. Note that with the above two scenarios I am running a fresh 2012-10-25 build which has been newly flashed today.

Justin/Vivien, do you have any idea why CNN.com would complain that cookies are disabled when viewed inside the homescreen wrapper? Are cookies disabled in this context?! (at least that would solve the problem of how to clear them...)

(In reply to Ben Francis [:benfrancis] from comment #3) > Justin/Vivien, do you have any idea why CNN.com would complain that cookies > are disabled when viewed inside the homescreen wrapper? What's the iframe structure of the homescreen wrapper thingamabob?

It's a mozbrowser iframe, but not a remote one. IIRC the iframe object is created by the platform when window.open is called from homescreen so lives in the system app but runs in the homescreen app's process! (I find it all rather confusing).

(In reply to Ben Francis [:benfrancis] from comment #5) > It's a mozbrowser iframe, but not a remote one. IIRC the iframe object is > created by the platform when window.open is called from homescreen so lives > in the system app but runs in the homescreen app's process! (I find it all > rather confusing). If the homescreen is remote (wrt the system app), a mozbrowser iframe created by the homescreen's window.open should also be remote (wrt the system app), because it lives in the same process as the homescreen. This doesn't necessarily have to do with cookies; cnn.com could hit some unexpected case and choose to complain about cookies. But I wonder what's going on. Can you reproduce this, Ben, or does it require a captive portal?

(In reply to Justin Lebar [:jlebar] from comment #6) > If the homescreen is remote (wrt the system app), a mozbrowser iframe > created by the homescreen's window.open should also be remote (wrt the > system app), because it lives in the same process as the homescreen. Yes sorry, I meant it doesn't have the remote attribute set, but it's certainly remote WRT to the main B2G process due to way it's spawned! > Can you reproduce this, Ben, or does it require a captive portal? I can reproduce this. * Add CNN.com bookmark to homescreen from browser * Launch from homescreen icon * CNN complains about cookies not being turned on

Ah, this sounds like bug 806127!

(In reply to Justin Lebar [:jlebar] from comment #8) > Ah, this sounds like bug 806127! Actually, that was premature. Bug 806127 might be relevant if we were opening this page inside the homescreen app's document (so the homescreen app had an in-process mozbrowser), but that's not what we're doing here. Ben, could you try to figure out whether cookies work here at all? Here's a random page which tries to figure out whether cookies are enabled, for instance. https://courses.worldcampus.psu.edu/public/diagnostics/cookies.html

(In reply to Justin Lebar [:jlebar] from comment #9) > (In reply to Justin Lebar [:jlebar] from comment #8) > > Ah, this sounds like bug 806127! > > Actually, that was premature. Bug 806127 might be relevant if we were > opening this page inside the homescreen app's document (so the homescreen > app had an in-process mozbrowser), but that's not what we're doing here. > > Ben, could you try to figure out whether cookies work here at all? Here's a > random page which tries to figure out whether cookies are enabled, for > instance. > > https://courses.worldcampus.psu.edu/public/diagnostics/cookies.html If this page is opened as a bookmark on the homescreen I see an alert saying 'Cookies are enabled.'.

Dang. Someone needs to figure out what is causing CNN to display that message, then, perhaps by looking at their code. :-/

(In reply to Justin Lebar [:jlebar] from comment #11) > Dang. > > Someone needs to figure out what is causing CNN to display that message, > then, perhaps by looking at their code. :-/ I did a quick investigation and in the url of cnn.com that is bookmarked is: http://m.cnn.com/primary/Home?cookieFlag=COOKIE_SET. If I remove the cookieFlag=COOKIE_SET part of the url then it works so I guess this is because the bookmarked url declare there is a cookie but since it is opened on the different jar there is obviously no cookie there. This is very easy to validate, just open http://m.cnn.com/primary/Home?cookieFlag=COOKIE_SET in a web browser you don't really use and the error page will be there! I'm tempted to close this bug or to bugmorph it as an evangelism bug. But it does not sound a blocking-basecamp anymore...

Agreed, this sounds like a CNN bug. Re-nominating because I think this should be blocking-basecamp-