Closed Bug 371860 Opened 18 years ago Closed 17 years ago

Citibank Online: after logging in the menu choices are not rendered properly making it impossible to continue

Categories

(Camino Graveyard :: Page Layout, defect)

Product:
Camino Graveyard
Component:
Page Layout
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: DrSFG, Assigned: mark)

References

(
URL
)

Details

(Keywords: fixed1.8.1.12, Whiteboard: [camino-1.5.3])

Attachments

(4 files, 1 obsolete file)

reporter's Firefox
37.02 KB, image/jpeg
Details
user's Camino
30.38 KB, image/jpeg
Details
Stack showing where NS_ERROR_FAILURE comes from
10.83 KB, text/plain
Details
1_5 branch project patch (dom + content) [checked in]
6.36 KB, patch
mark
: superreview+
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.4 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.4 see summary Reproducible: Always Steps to Reproduce: 1.https://web.da-us.citibank.com/cgi-bin/citifi/scripts/login2/login.jsp?M=S 2.Enter user id and password 3.Click on Sign on button. 4.https://web.da-us.citibank.com/cgi-bin/citifi/scripts/infrastructure/portal.jsp?BV_UseBVCookie=yes&BS_Id=Portal&BS_Branding=Frameset&rand=1172544919509 5. Page in 4. just preceeding is not rendered properly or useable.
Does this render correctly in Firefox? If so, can you please attach a screenshot of the rendering (blacking out your name/account number/etc. first) in Camino and in Firefox?
Thanks for filing this, Stewart. We'll get to the bottom of this one way or another. cl
Attached image reporter's Firefox —
You can use the "Add attachment" link to add attachments :)
Attached image user's Camino —
This looks exactly like the screenshot from bug 370587; Stewart, can you try a fresh profile (or a fresh profile + User Agent to get around the silly "we don't know what a Camino is" Citi-bug, as described in bug 370587) and see if using a fresh profile makes this page work for you?
Tried a fresh profile: sorry, no success. Tried to remove all InputManagers files as someone suggested: sorry, no success.
When you tried a fresh profile, did you also add in the User Agent pref pane to allow spoofing as Firefox 1.5? I agree with Smokey that this is probably a dupe of bug 370587, and that the solutions discussed there will also solve the problem reported here.
No, I didn't attempt the Firefox 1.5 spoofing. That only eliminates the warning window that says the full power of the website will not be available (which, of course, is untrue). I didn't see any solutions posted for #370587, but I may have missed it?
For #370587 it mentions eliminating CamiTools. I do not use CamiTools so that's not the problem. I did go back into my user.js file and prefs.js file and removed the spoofing code (as the Mozilla people instruct) and downloaded and installed UserAgent 1.0.1 and tried Camino 1.1b that way. No combination that I tried will get that Citibank page to render properly. And looking at the remarks on macupdate.com, other people are having the same problem. Some other file, utility or application my be causing the problem, but I'll be danged if I know what it is!
I can verify/second this bug. I have tried accessing this site with all versions of Camino (including many, many nightly builds), naked, spoofing Firefox 1.5, spoofing Firefox 2.0, with and without Camitools... virtually every possible combination or modification, and all with the same results. That said, the citibank website is 100% accessible with Firefox 1.5 (Mac, Intel or PPC) and Firefox 2.0 (either build as well), Safari, and Flock (built on Gecko as well I think).
If you do an HTML-complete save of the page in Camino and open it in Firefox does it render correctly? If you do an HTML-complete save of the page in Firefox and open it in Camino does it render correctly?
It does - Camino is being handed the correct HTML/CSS, but something is failing to render correctly. I think it has to do with cookies and security measures, since the rest of the site is fully navigable, and the issue only arises when you log in to the secure account area. Even though Camino renders the page incorrectly, you can still click on links, however every link tosses you out to the login page with an error message claiming the the session has timed out. So it's either two issues, or just one that's causing two symptoms: 1) Cookie/security measure is somehow preventing proper css/layout from loading 2) Layout is one issue, improper use of Citi.com's security coding is another. Can this bug be upgraded to confirmed? I've tried this from several different machines (MacBook, MacBook Pro, iMac G5, Mac Pro) with several different Camino builds, and _always_ with the same result.
(In reply to comment #11) > It does It does what? If Camino can open the Firefox-saved HTML complete without any issues, then that points strongly to this being a server-side issue. > Camino is being handed the correct HTML/CSS, but something is failing > to render correctly. Could you attach a zip of the HTML complete (with any personal/account information removed) so that we can try to make a reduced test-case? > I think it has to do with cookies and security measures Have you verified that you are not blocking cookies, scripts, etc. from any citibank domain? > Can this bug be upgraded to confirmed? I'm going to leave this unconfirmed until we have a test case, or similar concrete information that this is a Camino bug. There is really no such thing as Camino-specific CSS handling or page layout code, so it's far more likely that this is a subtle configuration or server-side issue.
> It does what? If Camino can open the Firefox-saved HTML complete without any > issues, then that points strongly to this being a server-side issue. Opening the HTML in Firefox does NOT reproduce the error, ergo it does render correctly in Firefox (sorry for the lack of clarity). > Could you attach a zip of the HTML complete (with any personal/account > information removed) so that we can try to make a reduced test-case? Forthcoming. > Have you verified that you are not blocking cookies, scripts, etc. from any > citibank domain? My machine has no such blockers set up, but remember, this error occurs reliably from multiple machines and multiple ISPs/Networks (see list of machines in my last comment), so in addition to verifying that nothing is being blocked, these data also lend themselves to the notion of this being a software issue with Camino. I'll upload the HTML when I have a chance to clean it thoroughly, but it might be easiest if the bug gets assigned to someone with access to a Citibank online account (a coder who banks with them, has a spouse who does, etc). Otherwise testing could be extremely tedious.
(In reply to comment #13) > I'll upload the HTML when I have a chance to clean it thoroughly, but it might > be easiest if the bug gets assigned to someone with access to a Citibank online > account (a coder who banks with them, has a spouse who does, etc). It would be, but none of us do, which is why we really need the test case.
So this is strange. I've been doing some testing to try and pin down the problem, and starting with dumped cookies and cache, the problem disappears (page loads correctly and is fully navigable). THEN, log out, log in, problem reappears. After the problem occurs, if you dump cache and leave the cookies, problem goes away, and the site loads correctly. And then, most bafflingly, if the problem occurs, if I log out and log back in WITHOUT dumping the cache, the problem goes away. The Citi site cooks up a number of the many pages/modules that comprise the account area with each new login, so I'm starting to suspect this is more of a server-side issue, since the site appears to be relying on some page that is being cached by Camino to be a freshly generated in some cases but not others. At any rate, clearing your cache appears to be a workaround in the meanwhile. Why this only causes issues in Camino and not Firefox is still a mystery to me.
I tried clearing my cache (several times) without success. Even reentering the site did nothing. I did not remove my cookies because some of mine are necessary (I believe) in order to get into some business sites that I must use on a daily basis. My workaround is to quit Camino, open Firefox, do what I have to do at Citibank, close Firefox and reopen Camino. It's not elegant but it always works!
Curiouser and curiouser - I've tried a few more attempts, here's what triggers it on my end: 1) Clear cache, delete cookies from .citi.com 2) Log in, get improperly rendered page 3) Click on an account link, get kicked out with a "We haven't heard from you in a while" error (which is an inactivity timeout error) 4) Log back in 5) Everything works! 6) Log out 7) Log back in 8) Site is broken again 9) Goto 3, repeat So it's loading correctly ever other time.... no idea what that means. The timeout error may be indicative of some cookie or server-generated flag that Camino isn't setting properly, and the layout simply looks like the CSS file for the page isn't getting loaded. But why every other time.... blerg?
Thank you for your help but I'm still having problems: 1) I have no cookies with .citi.com designation 2) I have many cookies from various Citibank web sites: CitiMortgage, CitiBusiness, and Citibank. Some of the cookies look like the hold information regarding my merchants that I deal with and I don't want to touch them. 3) I deleted three Citibank cookies but that didn't help, even following your directions. I'm sure that if I delete all my cookies, I'll get on the site. But doing these manipulations may destroy my productivity. It's just not as easy as simply opening up an alternative browser for this one web site. But hopefully experts like you will find a way either to fix Camino, or get Citibank to alter their web site.
I actually had to dump the cookies from web.da-us.citibank. to get the darn thing to work. There is a cookie with the name "browsersupported" which seems particularly suspect in all of this - perhaps try deleting that one and see what it does next time around? Or delete the whole batch of web.da-us.* cookies and see if you can at least get to the every-other-time behavior I'm getting. Alternatively, can you launch Camino in another user account on your machine? That would allow you to start a "naked" instance of the app, with no cookies or cache.
You are correct: deleting the three web.da-us.citibank cookies caused the behavior you have cited. I don't see a "browsersupported" cookie in my list. What happens to me after the "timed out" page is I get an error message page but the headings are rendered correctly, and all I need to do is click on "my home" or "payments" etc at the top and the subsequent pages will render correctly. Eliminating those cookies eliminates the remembrance of your login account name, so you must reenter it when you go back to the site. But then all is okay. Very strange behavior!!
Based on the fact that it at least works some of the time, and the fact that it doesn't happen the same way for everyone, I think we can safely close this as INVALID due to bugs in the way Citibank is serving content to Camino. There is probably an existing TE bug that covers this issue (my pick would be bug 319869), but if you think that doesn't quite cover it, Stewart, please file a new TE bug and complain vociferously to Citibank (be sure to mention the contract issue brought up in bug 319869 when you do). /me shakes his fist at Citibank
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago
Resolution: --- → INVALID
Thanks for your help in determining how to work with the site using Camino. Citibank is not, unfortunately, the only company I deal with that contradicts or doesn't fulfill their contracts. Maybe I'm just having a run of bad luck, but the business climate of today seems to allow these things to go unchecked. Again, thanks!
This is a Camino regression. The Citibank TE bug (bug 319869) is a separate issue in which they advise you to use a "supported" browser based on user-agent sniffing, but once you click through that warning, you're allowed unrestricted use of the site. This bug does not involve user-agent sniffing. It regressed for Camino 1.1/1.5 on MOZILLA_1_8_BRANCH between 2006-07-06-07 and 2006-07-07-05: http://ftp.mozilla.org/pub/mozilla.org/camino/nightly/2006/07/2006-07-06-07-1.1-M1.8/Camino.dmg http://ftp.mozilla.org/pub/mozilla.org/camino/nightly/2006/07/2006-07-07-05-1.1-M1.8/Camino.dmg Regression window: http://bonsai.mozilla.org/cvsquery.cgi?branch=MOZILLA_1_8_BRANCH&date=explicit&mindate=2006-07-06+07%3A00&maxdate=2006-07-07+06%3A00 The JS 1.7 landing looks suspicious. I did a build at 2006-07-06 19:00 PDT and 20:00 PDT and confirmed that this regressed as part of the JS 1.7 landing. This was over a year ago, but Brendan and Blake were involved in JS 1.7, so I'm inviting them to this bug in case they have any ideas before digging some more.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Status: UNCONFIRMED → NEW
Ever confirmed: true
When I take a build with MOZ_CO_DATE="2006-07-06 20:00 PDT" and modify it by reverting all of the files beneath js/src/xpconnect to 19:00 PDT (pre-JS 1.7 landing), the Citibank site works properly. That suggests that the regression was caused in: http://bonsai.mozilla.org/cvsquery.cgi?branch=MOZILLA_1_8_BRANCH&dir=mozilla/js/src/xpconnect&date=explicit&mindate=2006-07-06+19%3A00&maxdate=2006-07-06+20%3A00
More specifically, the portion of the checkin that triggered this bug is the early return if PostCreate fails: http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp&rev=1.96.4.15&mark=465-466,475#458 rv is NS_ERROR_UNEXPECTED here as returned by nsDOMClassInfo::PostCreate: http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/dom/src/base/nsDOMClassInfo.cpp&rev=1.292.2.65&mark=3272-3274#3259 Interestingly, I noticed that if PostCreate fails with NS_ERROR_UNEXPECTED and I call it again with the same arguments, it succeeds the second time. The nsDOMClassInfo object's mData->mName identifies "ImageDocument".
If you break at the |return NS_ERROR_UNEXPECTED| in nsDOMClassInfo, what's the value of cx->exception? It'll be a jsval, which you can print from the debugger by calling printVal, defined in jsobj.c.
Breakpoint 1, nsDOMClassInfo::PostCreate (this=0x354289c0, wrapper=0x339a8e00, cx=0x3394c350, obj=0x28cd6d8) at /lizard/camino-15x/mozilla/dom/src/base/nsDOMClassInfo.cpp:3273 3273 return NS_ERROR_UNEXPECTED; (gdb) print/x cx->exception $2 = 0x28cd668 (gdb) call printVal(cx, cx->exception) val 42784360 (0x0x28cd668) = object 0x0x28cd668 class 0x0x2ec19b80 XPCWrappedNative_NoHelper slot 0 object 0x0x28cd690 slot 1 object 0x0x2aaf0a8 slot 2 val 784440193 (0x0x2ec19b81) = (int) 392220096 slot 3 val 846156721 (0x0x326f53b1) = (int) 423078360 slot 4 val -2147483647 (0x0x80000001) = undefined
Mark and I met up on IRC. Unfortunately, the exception here is an NS_ERROR_FAILURE. I'm going to try to fix this by avoiding the JS_LookupProperty in favor of the XXX at http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/dom/src/base/nsDOMClassInfo.cpp&rev=1.483&root=/cvsroot&mark=3665,3666,3669#3656 and hope that it magically makes this bug go away. If not, a reduced testcase might help.
Blake, we might also be able to attack this from the "who's throwing the exception" angle. Since we're Camino and don't have all of our UI in JS, we can break on JS_SetPendingException and actually have the breakpoint be triggered a manageable number of times. In this case, there's only a single call to JS_SetPendingException prior to hitting the failing PostCreate. In this case, the throw is coming from XPC_WN_Helper_NewResolve while looking up "ImageDocument": http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp&rev=1.55.2.8&mark=1079#1058 This is where the NS_ERROR_FAILURE is coming from.
Hmm, perhaps the easiest way to do this would be to break in nsWindowSH::NewResolve when the incoming id is ImageDocument and step through to see why it's failing.
That stack makes it look like nobody registered ImageDocument's IID with xptcall (although it apparently gets added later, based on your comments that this all seems to work the second time around). I don't quite understand the mechanism behind this stuff. Does Camino do anything exciting with ImageDocuments?
We need to package content_htmldoc.xpt. We're not currently packaging it. DOH. We're also not currently packaging lots of other XPTs that we probably should. We seriously need to do an audit of this stuff.
Smokey's rolling this into a project patch for the Camino 1.5 branch. I want this for 1.5.3 since it causes a functional regression from 1.0.x, in which the Citibank site worked. I filed bug 400887 for us to do a typelib audit on more progressive branches.
Assignee: nobody → mark
Attached patch 15_branch project patch (obsolete) — — Splinter Review
Here's the 1_5 branch project patch adding the missing content_*.xpt files to the project. It looks a little ugly since I didn't fight Xcode 1.5 to make the files show up in pretty orders, etc.
Attachment #285925 - Flags: superreview?(mark)
As above, plus two missing dom_*.xpt for bug 400302.
Attachment #285925 - Attachment is obsolete: true
Attachment #285928 - Flags: superreview?(mark)
Attachment #285925 - Flags: superreview?(mark)
Comment on attachment 285928 [details] [diff] [review] 1_5 branch project patch (dom + content) [checked in] Excellent. You have my sr/a, plus the rs/a of those other guys who were watching. Thanks for the project magic, this saved me from having to do the annoying manual work.
Attachment #285928 - Flags: superreview?(mark) → superreview+
Comment on attachment 285928 [details] [diff] [review] 1_5 branch project patch (dom + content) [checked in] Checked in on the CAMINO_1_5_BRANCH; leaving open for 1_8 branch and trunk fixes (via bug 400887, most likely).
Attachment #285928 - Attachment description: 1_5 branch project patch (dom + content) → 1_5 branch project patch (dom + content) [checked in]
Attachment #285928 - Attachment is patch: true
Attachment #285928 - Attachment mime type: application/octet-stream → text/plain
This will be fixed in Camino 1.5.3 via the project patch on bug 371860; trunk/18branch fixes will happen in the XPT audit (bug 400887).
Whiteboard: [camino-1.5.3]
FIXED on the MOZILLA_1_8_BRANCH and trunk by the checkin for bug 400887. mento or anyone else with a Citibank account, please do verify this is working in tomorrow's nightlies.
Status: NEW → RESOLVED
Closed: 18 years ago → 17 years ago
Keywords: fixed1.8.1.12
Resolution: --- → FIXED
I tried it multiple times with the nightly after clearing all my citi*.com cookies, and attempted all of offending behaviors that used to cause the error... ...it works 100% of the time now. Looks like the bug has been squished. Thank you so much everybody!
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: